Designing the Moment an AI Agent Needs Human Input
When an AI agent asks a question, it's a handoff of responsibility, not chat. A practical framework for designing notifications, approvals, and safe resumption.
When a long-running AI agent hits a decision boundary and needs human input, that moment should not be treated as just another chat bubble—it is a genuine handoff of responsibility. Users may be away from the screen, notified on mobile, or returning hours later, so the interface must fully convey what was done, why it stopped, what evidence informed the situation, and what each choice will cause. The piece proposes that every interruption carry six fields—decision, reason, evidence, consequence, expiry, and recovery—and contrasts a weak question ("which branch?") with a stronger one that spells out impact, risk, and staleness conditions.
It also argues that clarifying questions, approvals, confirmations, and credential requests carry different risk levels and shouldn't share one generic UI pattern, and that notifications should act as pointers rather than exposing sensitive data or irreversible actions on a lock screen. While waiting, the system should make clear whether resources are still consumed, whether partial work is saved, and when the decision expires; once answered, an audit trail should record who decided what and when, letting the task resume from its checkpoint without re-asking the same question.
The author suggests testing this pattern against five scenarios—immediate desktop viewing, a delayed mobile check three hours later, an unauthorized user opening the link, environment changes during the wait, and failure after resumption. The proposal draws on the documented task-management design of the MonkeyCode project but is explicitly framed as a design suggestion rather than a claim about current implementation, offering a practical checklist for anyone building asynchronous human-agent collaboration.