A pause needs an owner, a deadline, and a valid route back.
The model abstains. The workflow displays a request for human review. Everyone involved in the architecture can now point to the safety feature, even though nobody has accepted responsibility for answering it. A pause is an execution primitive. An escalation is a service with demand, capacity, authority, and failure states. Confusing the two moves uncertainty out of the model without giving it anywhere reliable to go.
Consider a hypothetical internal assistant preparing a customer-data export. It may assemble an approved field selection inside a restricted workspace. Sending the result to a destination requires a separate authorization check. An unfamiliar destination or ambiguous field classification sends the proposal to review without transmitting the data. This is a proposed design, not an export service I have deployed or measured. Its useful question is what happens between the guardrail asking for help and an executor receiving a valid decision.
The runtime can preserve the pause without supplying the operation around it. LangGraph’s interrupt documentation describes saving graph state and waiting indefinitely for external input. It also warns that resuming restarts the interrupted node, so preceding side effects need appropriate idempotency or separation. Those are real persistence and replay concerns. They do not assign a reviewer, decide an expiry, or establish that the person returning a value can authorize a data disclosure.
Start with one durable escalation record created by the controller, not a conversational message the agent can rewrite. In this design it contains an operation identifier, reason for escalation, requested effect, resolved dataset and recipient, permitted evidence references, artifact digest, relevant source revision, policy revision, required decision roles, creation time, and expiry. Link it to the original workflow. Keep confidential evidence in its protected store; the queue should not become a second unrestricted copy of the customer data.
The record must survive a failed notification. Persist an undelivered state until the queue accepts the item; do not call it awaiting review because an email was attempted. Use an idempotent enqueue keyed to the operation and review revision. A durable outbox can retry notification delivery without creating another decision or repeating the export. The controller should be able to answer whether a proposal is held locally, accepted by the queue, claimed by a reviewer, or resolved. An unread alert is not an acknowledged handoff.
Give the queue a service owner before assigning individual items. That owner maintains eligible reviewers, coverage, escalation routes, and overload behavior. A reviewer claim should be a bounded lease so an abandoned browser tab cannot hold the item forever. Lease expiry returns the same unresolved item to available review; it does not reset the operation’s approval deadline. Where policy requires two roles, track their decisions separately. A data owner and a security reviewer are not interchangeable simply because both can open the interface.
Priority should express the cost of waiting and the operation’s deadline, not the model’s insistence that its task is important. In the export example, an ordinary internal analysis may wait while a time-sensitive legitimate request receives earlier review under an explicit policy. Age should remain visible so low-priority work does not disappear permanently. Cap admissions when qualified review capacity is exhausted. The allowed response may be to defer new exports or reduce autonomous intake, not silently relax the classification rule to keep the queue short.
The evidence packet should ask a question a reviewer can actually answer. Show the exact destination, proposed fields, intended use, relevant policy boundary, uncertainty, and consequence of approval. Distinguish the assistant’s recommendation from the underlying records. Retrieve current authority from a trusted source rather than accepting a pasted claim that a manager already consented. OWASP’s transaction-authorization guidance requires acknowledgement of significant transaction data and enforcement tied to execution. Applying that principle to an export is a design choice here, not an OWASP certification of this workflow.
The holding state needs its own resource contract. Keep the proposed export private and unsent; avoid retaining unnecessary sensitive copies while it waits. If policy allows a staged encrypted artifact, give it a retention expiry and an owner for cleanup. If not, retain only the reproducible proposal and approved references. A reversible hold is not merely the absence of a network call. It is a state the system can abandon without leaking data, holding credentials indefinitely, or making someone else discover forgotten artifacts later.
No response is a disposition, not a missing branch. At the deadline, this design expires the review and leaves the export unsent, records the reason, and routes the unresolved business need to the service owner. A late approval cannot resurrect that operation. AWS Step Functions documents callback tasks that wait for a task token and timeout controls for avoiding stuck waits. The important application-level distinction is that a liveness signal does not renew consent. A reviewer heartbeat can show activity without extending the policy’s maximum approval validity.
Disagreement needs a route too. Suppose the data owner approves the requested fields while the security reviewer rejects the destination. Do not let the last click win or ask the model to choose the more persuasive explanation. Preserve both scoped decisions and keep the export held. Route the specific conflict to the authorized exception owner, who may narrow the fields, change the destination, or deny the request. A material change creates a new review revision. The original decisions remain evidence of what was considered, not permission automatically inherited by the replacement.
Waiting also changes the world. The recipient’s access may be revoked, the dataset may gain restricted fields, or another worker may complete the same request. Bind a response to the reviewed operation, revision, artifact, decision scope, authenticated reviewer, expiry, and any permitted conditions. Immediately before execution, compare those values with current state and reconcile prior attempts. OWASP’s same guidance calls for protecting significant transaction data from modification and a final authorization control. Here, a changed dataset or revoked recipient invalidates the old approval rather than becoming a detail the executor ignores to clear backlog.
Return a structured decision to the workflow: approve the exact revision, deny with a reason, request specified evidence, or refer a scoped conflict. A free-text comment can explain the decision but should not become executable instructions. Validate the response schema and the reviewer’s current role outside the acting model. A request for evidence sends the item to an owned evidence-gathering state with the original deadline visible; it should not create an unlimited loop in which each question grants a fresh waiting period. An approval still passes the execution boundary rather than handing the assistant an unrestricted credential.
Close the record only when the resulting disposition is durable. Approval is not proof that the export happened. Dispatch with an operation identity, retain uncertain outcomes, and verify the actual destination and artifact through the permitted delivery evidence. Queue metrics should distinguish time to first ownership, age at decision, expiry, disagreement, rework after state changes, and verified completion. These are proposed measurements, not reported results. A short queue can conceal dropped requests; a high approval rate can conceal rubber-stamping. Test an abandoned claim, an expired response, two conflicting reviewers, changed source data, duplicate delivery, and a lost execution response. The escalation path is ready when each of those cases leaves a named owner and a safe next state, not merely a button someone could have pressed.
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.