When an Agent Should Stop and Ask a Person

An agent should stop when it cannot establish that it has the authority, information, and safe operating conditions needed for its next action. That sounds simple, but “ask a person” is not a complete design. The agent must recognize the boundary before acting, explain what needs attention, preserve useful context, and wait for a decision that applies to the action actually proposed.

The distinction matters because an agent can be fluent and still be wrong about what it is permitted to do. It may interpret a vague request as authorization, mistake a missing detail for a harmless default, or treat a model-generated confidence score as proof. A handoff is a control in the workflow—not a polite message attached after the agent has already done something consequential.

This numbered list focuses on the decision to stop: when to trigger human involvement, what information to carry forward, and how to avoid turning review into a rubber stamp. For context on monitoring these systems after launch, see AI Agents in Production: Agent Observability. The goal here is narrower: define boundaries that a team can translate into behavior, tests, and an operating procedure.

1. Stop when the requested action exceeds the agent’s authority

An agent needs a defined scope of authority for each kind of action. “Help with customer requests” is a goal, not an authorization boundary. The operational definition should identify which actions the agent may complete, which it may prepare but not execute, and which it must not perform. Those distinctions should be visible in the workflow design and enforced outside the model’s free-form reasoning.

A useful policy describes actions in concrete terms. For example, an agent might be allowed to summarize a case and draft a response, but not issue a refund, change a contractual term, or close a disputed account. The boundary should also specify relevant limits: the account or record involved, the action type, the value or extent if applicable, and any conditions that require a person. A prompt saying “be careful” cannot reliably substitute for those rules.

When a request falls outside the defined scope, the agent should stop before the external effect. It can still gather non-sensitive information that is safe and necessary for a reviewer, but it should not move the action into an executable state. The handoff should say which requested action crossed the boundary, what the agent did instead, and what decision is needed. Avoid vague escalation reasons such as “low confidence” when the real issue is “this action is not authorized for the agent.”

This is also a decision about product experience. If the agent cannot perform a task, it should distinguish between a temporary need for review and a permanent restriction. That prevents a person from approving an action that policy does not allow the agent to take at all. For design questions about the surrounding runtime and control layer, see When Should You Build Your Own Agent Harness?; this article stays focused on the conditions that should trigger a handoff.

flowchart TD
  accTitle: Route an agent stop to the right person
  accDescr: Stopping should preserve enough state for a person to make the next decision. Resumption rechecks the new authority and current business state instead of blindly replaying the previous action.
  N0["Detect missing authority or evidence"] --> N1["Preserve last confirmed state"]
  N1["Preserve last confirmed state"] --> N2["Record possible external effects"]
  N2["Record possible external effects"] --> N3["Identify accountable reviewer"]
  N3["Identify accountable reviewer"] --> N4["Present bounded decision"]
  N4["Present bounded decision"] --> N5["Resume only after validation"]

Stopping should preserve enough state for a person to make the next decision. Resumption rechecks the new authority and current business state instead of blindly replaying the previous action.

2. Stop when the request leaves a material ambiguity unresolved

Ambiguity is not automatically a reason to escalate. Some missing details can be resolved with a low-risk clarification: “Which invoice do you mean?” Other uncertainty changes the action’s meaning, target, or consequence. That kind of ambiguity should block execution until a person or the requester resolves it.

Teams should define “material” in relation to the action. If the agent is preparing an internal draft, an uncertain tone preference may be tolerable. If it is sending a notice, changing a payment destination, or closing an account, uncertainty about the recipient or underlying record is material. A practical test is whether choosing the wrong interpretation could create an external effect that is difficult to reverse, expose information, or commit the business to a position it did not intend.

The handoff should present the competing interpretations rather than conceal them behind a single confident summary. For instance: “The request could refer to account A or account B; the selected record is not established.” If the agent has a safe way to ask the requester for clarification, it may do that instead of routing immediately to an operator. If the requester cannot resolve the ambiguity, or the clarification itself requires judgment, the workflow should stop and assign the decision to an appropriate person.

Do not let the system silently fill a consequential blank with the most common value. “Usually,” “probably,” and “the nearest matching record” may be useful search hints, but they are not authority to act. Record the unresolved field explicitly so that a reviewer can address it without reconstructing the entire interaction. The Token Budget Management Across Agent Hops article is relevant when designing how to preserve necessary context as work passes between stages; the important boundary here is that missing context must remain visible, not be silently invented.

3. Stop before an irreversible or hard-to-reverse action

An action deserves a higher bar for autonomy when reversal is difficult, costly, incomplete, or dependent on another party. Sending a message can be irreversible in the practical sense even if a correction can be sent later. Deleting a record, disbursing funds, publishing a statement, changing access, and submitting a binding request can have effects that are not erased by restoring an earlier database value.

Classify actions by their real-world consequences, not just by whether an API offers an undo operation. A reversible database update may still trigger a notification, downstream workflow, or user decision. A cancellation might be technically reversible but leave a customer without service in the meantime. The design review should map the action’s side effects and identify which ones persist after a rollback.

For higher-consequence actions, separate preparation from execution. The agent may collect facts, draft a proposed change, and assemble the exact payload. It then stops and presents that proposal to a person before any external call occurs. Approval must apply to the exact payload: the target, action, relevant values, and any consequential message should be clear enough to review. If any of those fields change after approval, the old approval should not authorize the altered action.

This is a useful place to distinguish “human in the loop” from “human nearby.” A person who sees a vague status indicator after the action is already underway is not exercising meaningful control. A review step must precede the consequential effect, and the workflow must have a defined path for rejection, expiry, or a changed proposal. A general overview of coordination costs is available in Single Agent or Multiple Agents? Start with the Coordination Cost; adding more agents does not remove the need to put this boundary in the execution path.

4. Stop when the evidence does not support the proposed decision

A fluent explanation is not evidence that the underlying facts are complete or correct. The agent should stop when required information is missing, contradictory, stale, or drawn from a source that is not adequate for the decision. This applies even if the model expresses strong confidence. Confidence can be one signal to inspect; it is not a substitute for checking whether the required evidence exists.

Define evidence requirements around the decision. A workflow might require a particular source record, a current status, and a match between the request and the intended account. If one element is absent, the agent should identify the gap instead of writing a plausible bridge across it. Teams should distinguish between a fact the system retrieved, a fact the requester stated, and an inference the model produced. A reviewer can then judge the inference without mistaking it for verified information.

Contradictions deserve their own trigger. If two records disagree about a material field, the agent should not choose whichever value appears more often or more recently unless a documented rule establishes that precedence. The handoff can include both values, their sources, and the decision needed. If information may have gone stale during a multi-step workflow, check it again before the consequential action or return for human review.

The practical rule is to use action-specific evidence criteria. A brief answer to a low-impact question may not need the same support as a change to a customer record. Applying one universal “confidence threshold” across different actions hides that distinction. A team can measure how often evidence-triggered stops occur, how often reviewers resolve them, and whether recurring gaps point to a data or workflow problem. Those measurements help improve the boundary without treating every escalation as a model failure.

A product-specific example is What Dayrun Does: Calls, Bookings, Follow-Ups and Human Approvals, which separates advertised features from the handoff behavior a buyer should verify.

When conversations span several sites, One Inbox, Many Locations: Keeping Customer Conversations Consistent explains assignment, continuity and escalation across location boundaries.

For the customer-contact path after a handoff, Automating Customer Follow-Ups Without Losing Context covers trigger conditions, context and stopping rules.

5. Stop when authority is unclear—even if the requester sounds decisive

A request can be clear in wording and still come from someone whose authority is unknown. The agent should not infer permission from confidence, urgency, senior-sounding language, or familiarity with the account. Authority depends on the relevant action and context, so the design should identify what the workflow can establish and what requires a human decision.

This does not mean turning every interaction into an identity-verification exercise. It means recognizing when the agent lacks a reliable basis to determine that the requester may authorize a particular change. For routine informational help, the available identity context may be sufficient. For a consequential change, a missing or conflicting authority signal should block execution rather than be filled in by conversational inference.

A useful handoff names the unresolved authority question without implying a judgment about the requester. For example: “The request is clear, but this workflow cannot establish whether the requester may approve this change.” The reviewer can then follow the business’s existing process. The agent should not use a person’s response to one question as blanket permission for unrelated actions.

There is a related distinction between approval and execution. A reviewer can decide that a proposed action is acceptable, while the system still needs to confirm that the approved target and payload have not changed. The reviewer’s decision should be attached to the specific proposal and its current state. If a material field changes before execution, request a fresh decision. This avoids treating an old approval as transferable authority for a new action.

6. Stop when the person asks for a person—or the agent cannot explain the next step

An explicit request for human assistance is a meaningful workflow signal. It should not be buried beneath another attempt to persuade the person to continue with automation. The system should acknowledge the request, preserve the relevant context, and route it according to the service’s actual operating path. If the workflow cannot provide an immediate handoff, it should say what happens next rather than imply that a person is already engaged.

The agent should also stop when it cannot state a useful next step. Repeated tool failures, circular reasoning, conflicting actions, and attempts to answer outside the task’s scope can turn a small issue into a longer, less legible failure. Set operational limits for retries and elapsed time based on the task. A retry should address a diagnosed transient problem; it should not be an automatic way to keep going when the agent does not understand why progress has stopped.

When a tool fails, distinguish between a safe retry and an uncertain outcome. If a request may have reached an external system but the response was lost, the agent should not blindly submit it again. It should check the result using an available, appropriate method or stop for a person to resolve the uncertain state. A duplicated external effect is not made safe merely because the agent intended to retry once.

Build the handoff so the person receives the last known state, the operation attempted, the observed response or lack of one, and any action that must not be repeated without checking. For related work on changes to connected tools and the tests that can catch contract drift, see Tool Changes Can Break Agents: Add Contract Tests to CI. The scope here is not a general integration-testing guide; it is the stop condition when the agent cannot establish what happened.

7. Stop when the proposed action has changed since approval

Review is only meaningful if the person sees the action that will actually occur. If a later step changes the recipient, amount, record, wording, timing, or another material field, the prior decision no longer covers the revised proposal. The system should invalidate the approval, show the change, and request a new decision before execution.

This boundary is especially important in workflows where the agent can revise a draft after receiving feedback or where data may change between review and execution. A reviewer might approve one message, then the agent adds a new commitment. Or an account match might be updated after the initial review. In either case, a “previously approved” flag is not enough. Keep a stable representation of the proposed action and compare the executable action against it before proceeding.

An approval should also expire. The expiry should reflect how quickly the action’s context can become stale, rather than defaulting to an indefinite authorization. Once it expires, the agent can refresh the relevant information and request review again. If a system pause or outage delays execution, the workflow must not assume that an old decision remains valid simply because it was once recorded.

Workflows can be paused and resumed, but the application must enforce the approval’s scope and expiry. LangGraph’s interrupt guidance describes pause-and-resume mechanics. The approval-scope and expiry checks here are requirements of our proposed application design. In practical terms, saving a workflow state is not the same as making the approval safe: the system must still check that the approved action is unchanged, in scope, and unexpired before resuming execution.

8. Stop when a person cannot make a well-informed decision from the handoff

A human handoff can fail even when it triggers at the right time. If the reviewer receives a long transcript, a vague summary, and no clear decision request, the workflow has transferred the burden without making the decision easier. The agent should present a concise, structured account of what happened and distinguish facts, inferences, missing information, and proposed action.

A useful handoff usually answers five practical questions: What outcome was requested? What has the agent already done? What is uncertain or blocked? What action is proposed next? What decision does the person need to make? Include only the context relevant to those questions, but do not omit a fact that could change the decision. The summary should also identify whether any external action has already occurred or might have occurred with an uncertain result.

Make the reviewer’s options explicit. Depending on the workflow, they might approve the exact proposal, reject it, request clarification, or take over the task. Do not design an interface where the only prominent path is “approve.” A reviewer needs enough time and information to disagree with the agent, and the workflow needs a defined outcome for that disagreement.

If the information needed to decide is not available, stop the handoff from becoming a false resolution. Route the case to someone who can obtain that information or return to the requester with a specific clarification. A handoff record should make uncertainty easier to resolve, not make uncertainty disappear from view. After deployment, inspect whether reviewers frequently reopen cases because the summary omitted a key detail; that is evidence that the handoff contract needs adjustment.

9. Test the stop path with a failure timeline, not only a happy path

A successful demo often proves only that an agent can complete a straightforward task. Operational readiness depends on what happens when the workflow encounters an expired approval, ambiguous input, partial tool response, or repeated interruption. Write the failure timeline before launch: identify when the system must stop, what state it should preserve, what the person will see, and what prevents an unsafe continuation.

Use an illustrative scenario such as a hypothetical service agent asked to change a business customer’s billing destination. The request identifies an account, but the available workflow cannot establish that the requester may authorize the change. The agent must not submit the update. It can prepare a handoff that states the requested change, identifies the missing authority decision, and records that no update has been sent. If a reviewer requests more information, the request returns for clarification. If the workflow is interrupted and later resumes, it must still recheck the decision’s scope and expiry before any execution step.

Turn that timeline into tests with observable pass and fail conditions. The details below are an operational test, not a claim that a particular system has been run:

Test the boundary at more than one layer. A model-level instruction can tell the agent to stop, but an execution control should also prevent the action from proceeding without the required decision. The handoff interface should show the same action and status that the execution path will use. Finally, test interruption and resumption: a safe state transition should not become unsafe just because the workflow restarted after a delay.

Track failures that expose a weak boundary separately from ordinary task errors. Examples include an action occurring before approval, a reviewer approving a different payload than the one executed, an expired decision being reused, or an uncertain external result being retried as though it were known. These are useful release-blocking conditions because they reveal whether the stop rule is enforced in practice, rather than merely described in a prompt.

A printable stop-and-handoff worksheet

Use this worksheet to turn one consequential agent action into a reviewable boundary. Complete it with the people who own the workflow, the operator experience, and the system that performs the action. Keep answers specific enough that an engineer can translate them into a decision and a test.

• Requested action: What exactly is the agent being asked to do? Name the object, target, and consequential fields.
• Permitted scope: Is the agent allowed to execute this action, prepare it for review, or neither? State any applicable limits.
• Evidence needed: Which records or facts must be present, current, and consistent before proceeding?
• Ambiguity trigger: Which missing or competing interpretations block action? What safe clarification can the agent request?
• Authority signal: What establishes that this request may be approved? What should happen when that signal is missing or conflicts with other information?
• Consequence and reversal: What external effects could occur, and which ones cannot reliably be undone?
• Approval binding: Which exact fields are shown to the reviewer? What changes invalidate approval?
• Expiry: When does approval stop being valid, and what must be refreshed before asking again?
• Handoff payload: What facts, inferences, actions taken, failed steps, and unresolved decisions does the reviewer need?
• Failure outcome: What happens after rejection, timeout, tool uncertainty, or a workflow interruption?
• Acceptance test: What observable result proves that execution is blocked until every required condition is met?

Printable summary: The agent may proceed only when its authority is defined, the material facts support the action, the intended target and payload are clear, and any required approval applies to the unchanged action and remains valid. Otherwise, it stops before the external effect, preserves the relevant state, and asks for a specific decision. A test passes when the blocked action cannot execute through a retry, changed payload, or resumed workflow without satisfying those conditions again.

Closing prioritization: start with the boundaries that prevent harm

If time is limited, prioritize three controls first. Define which actions the agent is allowed to execute, block irreversible or hard-to-reverse actions until the required review occurs, and bind approval to the exact action that will run. These are the boundaries that prevent a mistaken interpretation from becoming an external effect.

Next, make material uncertainty visible: identify missing evidence, conflicting records, and unclear authority rather than allowing the agent to choose a convenient default. Then improve the handoff itself so the reviewer can see what happened, what remains unresolved, and what decision is needed. Finally, test rejection, expiry, changed payloads, and uncertain tool outcomes as deliberately as the successful path.

A team designing or revising these controls may benefit from production platform engineering when the work spans agent behavior, application-level approval enforcement, workflow state, and operational testing. The right implementation is the one that makes the stop decision enforceable and understandable for the people who must rely on it—not the one that escalates the most or the least.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.