When an agent stops and asks
Design an agent's handover to a person: ask a specific question, save progress, route it to someone who can decide and resume after checking the answer.
An agent should stop when it needs a decision or permission it cannot supply, or when further attempts exceed its limits. It saves the work, asks a specific question and continues only after the workflow has checked a valid answer.
An agent is changing a cancellation rule, but nobody has decided what happens to orders already shipped. It records the unfinished changes and asks the product owner. When the answer arrives, the next worker reads that decision and checks the saved work before continuing.
An agent can stop without discarding the task. It can leave the code and test results where another worker can find them, ask for the missing decision and continue later. The important part is connecting the answer back to the correct saved work.
Explain what stopped the task and what answer it needs#
A task may need a product decision, permission to perform an action or access to a required test environment. Two requirements may conflict. The agent may also reach its time, cost or repair-attempt limit. These cases need different responses; they are not all coding failures.
Before asking, check the appropriate project records. Do not send someone a question that the agreed specification already answers. But do not substitute current code for approval of a new rule. In the illustrative cancellation example, inspecting the implementation cannot decide what should happen to orders already shipped.
Write the specific question: “Should shipped orders keep the old cancellation rule?” Include the conflicting requirements or relevant findings. Explain the known alternatives and their consequences. Where the options are uncertain, say what investigation remains instead of inventing a reassuring choice.
Save the task ID, code revision, unfinished edits, check results and reason for stopping. Mark whether an external action is still in progress or has an unknown result. A useful question should let the recipient answer without reconstructing the whole run, while still providing references for closer inspection.
A repair limit should lead to this saved handover, not a silent abandoned branch. The 12-factor agents guide treats asking a human and pausing or resuming work as parts of the workflow rather than exceptions outside it.
Make the answer restart the right work#
Posting a question does not make the answer useful automatically. Decide how replies are received and matched to the waiting task. The person might answer in the issue tracker or an approval screen; they should not need to restart a container themselves.
In this example design, the worker exits while the task waits. Saved task records preserve the work independently of that process. A supported workflow platform may already provide waiting and resumption; it does not have to be custom software.
When a reply arrives, check its sender and the pending question it refers to. Confirm that the person may make that decision. A bare “yes” is ambiguous when two questions or revisions are pending. Save the accepted answer with its scope before allowing the next step.
Handle repeated deliveries and late answers. The same reply must not start the task twice. An answer to an old version must not automatically authorise a materially changed plan. Cancellation also takes precedence over a late instruction to continue.
The replacement worker checks the current branch and environment against the saved record. Another developer may have changed the code while the task waited. Re-evaluate affected findings rather than replaying an obsolete plan unchanged.
Use maintained ownership information to route questions. Who owns the factory distinguishes the people responsible for product decisions, code and the automation itself. Define a fallback recipient and an expected response window. When the window passes, remind or escalate; do not treat silence as approval unless an explicit policy actually permits that action.
Stopping does not cancel every action already sent to another system. A request might complete after a timeout. AWS’s retry guidance explains why a missing response needs careful handling. Check the external result before repeating a possibly completed write.
Check whether questions are useful and answers are used#
A dashboard showing fewer questions can be misleading. Clearer requirements may reduce unnecessary questions. So can weakening the instructions until agents guess more often. Compare the rate with defects, review corrections and missed decisions before calling it an improvement.
Measure time to a useful answer and time from that answer to resumption. A task that has a valid answer but remains blocked can reveal a broken webhook, a routing problem or a failed worker start. Waiting is an expected state, but an unexplained long wait still needs attention.
Review repeated questions. Perhaps the answer belongs in shared project guidance, or the task preparation repeatedly omits it. Preserve its scope: a decision for one customer or feature should not silently become the rule for every future task.
Also inspect questions that people struggle to answer. “The requirements are unclear” names no decision. Provide the relevant statements and the specific conflict. Do not burden the recipient with raw logs when a short explanation and a reference would do.
Too many unnecessary questions can make the workflow less useful. Set stopping rules around missing authority, meaningful uncertainty and the consequences of being wrong, rather than an unvalidated model confidence score. Allow ordinary investigation within the approved scope.
A confidence signal can be evaluated against checked task outcomes and used to prioritise review. Confidence and calibration explains that comparison. Even a useful signal cannot supply a missing account identifier, an undecided rule or permission to act.
Keep the reason for stopping specific. In an illustrative support router, “the feature is not identified” needs clarification; “none of these queues applies” needs a fallback; “the model service did not respond” needs failure handling. A clear decision contract prevents these different situations from becoming the same vague low-confidence message.
Finally, test the full path: stop a task, save its changes, deliver an authorised answer twice and confirm that only the correct task resumes once. Try a late answer after cancellation as well. The next article applies the same discipline to an agent reviewing a proposed code change.
IF YOU REMEMBER ONE THING
Save the work and ask a question someone can answer. Then verify that the answer applies to the current task before resuming it. Posting the question is only half the job.
Questions people also ask
4 QUESTIONSWhat should an agent include when asking a person?
State why it stopped, the specific question and the relevant code, requirement or failure. Explain realistic options and consequences when known. Do not invent options or certainty merely to fill a form. Include a link to the saved task so the person can inspect more detail.
How does a blocked task resume?
The workflow receives an answer, checks who supplied it and which question and version it answers, then records the decision. It resumes the saved task only if that decision still applies. The worker can be a new process; it first checks whether the code or environment changed while the task waited.
Is a falling escalation rate a good sign?
Not by itself. It may mean that tasks are clearer, or that agents are making more unsupported assumptions. Compare it with defects, missed decisions and human rework. Also check how long answers take and whether the same question keeps returning.
Who should receive the question?
Route a product-rule question to someone authorised to decide that rule, and an infrastructure problem to the responsible team. Use maintained ownership information and a fallback when it is missing. An agent can suggest a recipient, but its guess should not grant that person approval authority.