Design the Moment an AI Agent Needs Human Input

An AI agent asking a question is not a conversational flourish. It is a handoff of responsibility.

The system has reached a boundary it cannot—or should not—cross alone. The interface must explain the decision, preserve the work already completed, make the consequence of each answer visible, and resume without creating a second task.

Many products design this moment as another chat bubble. That works only when the person is already watching. Long-running tasks need an interruption contract that survives closed tabs, mobile notifications, time zones, and expired context.

Model the handoff as a flow

agent working

     |

     v

decision boundary detected

     |

     +--> preserve checkpoint and evidence

     |

     v

needs human input ----> notify through allowed channel

     |                           |

     |                           v

     |                    user opens exact task

     |                           |

     +<--------------------------+

     |

     v

answer reviewed + authorization rechecked

     |

     +--> expired / unauthorized --> explain and recover

     |

     v

resume same task from checkpoint

This separates a question from a chat message. A question changes task state, may pause resource consumption, and needs an explicit resume rule.

Every interruption needs six fields

Compare two versions:

Weak: Which branch should I use?



Stronger: Choose the target branch for the authentication patch.

main is protected and will open a pull request; release/2.4 will create

a patch against the active release. No files have been changed yet.

This question expires if the repository revision changes.

The stronger version helps someone decide without reconstructing the whole task from memory.

Distinguish questions, approvals, and confirmations

These interactions have different risk:

Calling every case “needs input” is acceptable as a backend state, but the interface should not style a low-risk clarification like a production approval.

Design the notification as a pointer, not the decision surface

A notification should contain enough information to prioritize, but sensitive evidence and irreversible actions belong behind authenticated access.

Recommended notification structure:

Task needs input: Refactor authentication

Decision: choose the target branch

Waiting since: 14:32

Open task

Avoid putting repository contents, patches, credentials, or an “approve” action directly on a lock screen. When the user follows the link, recheck account, role, task version, and whether the decision is still active.

Make waiting and expiry visible

The agent's state should answer:

• Is compute still running while it waits?


• Are partial changes saved?


• Can another authorized teammate answer?


• Will the task time out?


• What event would make the question stale?

Useful copy:

Waiting for a branch choice. The workspace is paused and partial analysis

is saved. Anyone with Maintainer access can answer. This decision expires

when the repository revision changes or after 24 hours.

The exact timeout is a product policy. The design requirement is to expose it before expiry, not reveal it after the task disappears.

Resume without erasing the handoff

After an answer, preserve an event such as:

14:32 Agent requested target branch

14:47 Mina selected release/2.4

14:47 Authorization checked: Maintainer

14:48 Task resumed from checkpoint 7

The history establishes who made the decision and which task version consumed it. It also supports recovery when the agent fails later: the user should not have to answer the same unchanged question again.

If the repository or policy changed while the task waited, reject the stale answer gracefully:

This choice is no longer current because the repository changed at 14:45.

The task preserved its analysis and needs a new target-branch decision.

A lightweight evaluation script

Test the flow with five scenario prompts, not a generic “does this feel clear?” interview:

1. The user sees the question immediately while working on desktop.


2. The user opens it three hours later from a mobile notification.


3. A teammate without permission follows the task link.


4. The repository changes before the answer is submitted.


5. The task fails two steps after resuming.

For each scenario, ask the participant to explain:

• what the agent has completed;


• why it stopped;


• what each available action will do;


• whether anything is currently consuming resources;


• how to decline or safely leave;


• how they would find the decision later.

Measure decision accuracy, time to the correct evidence, accidental approval attempts, and whether the participant can predict the resume behavior. Do not invent sample results; report participant count, recruitment, task fixture, and raw failure categories when the study is actually run.

Applying the pattern to a documented task workspace

The public MonkeyCode repository describes AI task management, project requirements, cloud development environments, and PC/mobile synchronization. Those documented workflows make asynchronous human input a relevant design question. The flow above is a design proposal, not a claim that MonkeyCode currently uses these exact states, notifications, or expiry rules.

Disclosure: I contribute to the MonkeyCode project. Product context is based on the linked public documentation; no user study results are claimed here.

Designers and developers can join the MonkeyCode Discord to discuss how task handoffs should work. People interested in evaluating the hosted service can also ask the team about current free model-credit availability, eligibility, and limits.

The moment an agent stops is not empty time. It is a transfer of authority. Design that transfer with the same care as the action it may authorize.