A polished agent demo can hide the most important production question: what happens when the agent should not act?

Teams prove the happy path, connect a system, then add a human escalation queue near the end. By then, authority has already been embedded in prompts, tools, permissions, interface states, and operating assumptions. The “handoff” is treated as support plumbing even though it changes the product's behavior.

Authority boundaries and human handoffs belong in the product specification, evaluation set, and operating model. A production agent is defined as much by the actions it must decline or escalate as by the actions it can complete.

The evidence points beyond output quality

Several AI Engineer sessions point in the same direction without describing one universal vendor model. Decagon's session separates agent-behavior and handoff configuration from product-like engineering around integrations. Anthropic Applied AI speakers describe production harness concerns that include bounded execution, credentials, durable sessions, observability, and outcome criteria. Accenture speakers describe graduated autonomy moving from shadow mode to advice and then bounded action, with evidence between the stages.

NIST's voluntary AI Risk Management Framework provides a current governance reference. Its core includes outcomes for defined roles in human-AI configurations, documented oversight, evaluation under deployment-like conditions, and production monitoring. The framework is under revision. It is neither law nor certification, and it does not prescribe the model below.

The operating model that follows is my synthesis of those sources.

Start with an authority map

For every material action in the workflow, assign four verbs:

  • Propose: May the agent recommend an action or prepare a draft?
  • Approve: Who decides whether that action is acceptable?
  • Execute: Which identity performs it, in which system, and within what limit?
  • Recover: Who can stop, reverse, correct, or escalate a bad result?

Apply the verbs to actions, not to the agent as a whole. In an illustrative service workflow, an agent might draft a response without approval, require a person to approve sending it, and remain prohibited from changing the customer's account. “Human in the loop” cannot represent those differences.

The map also exposes false ownership. If operations supposedly approves a high-impact action but has no review interface, response expectation, or authority to reject it, there is no handoff. There is only an assumption.

Separate four kinds of handoff

Not every escalation means the same thing.

Uncertainty means the system lacks enough confidence or context to continue. The handoff should carry the input, relevant sources, proposed action, uncertainty signal, and deadline.

Workflow exception means the case is legitimate but outside the modeled path. The receiving person needs the state of work and a route for changing the workflow, not a recurring invitation to solve the same exception manually.

Policy boundary means a decision remains human-owned. The interface should make the decision explicit and auditable without pushing the reviewer toward a rubber stamp.

System failure means a tool, credential, dependency, or integration failed. That event belongs with operational monitoring and incident ownership, not in a general business-review queue.

The categories lead to different queues, evidence, response expectations, and product decisions. Combining them produces an inbox that no one can manage and a product team cannot learn from.

Evaluate the transition, not only the answer

Many evaluation sets ask whether a model produced an acceptable output. Agentic systems also need transition tests.

Can the system recognize missing context? Does it refuse an action outside its permission? Does the reviewer receive enough information to decide? Can work resume safely after approval? What happens when the reviewer does nothing? Does a prohibited action remain prohibited even when the model requests it?

These are product acceptance scenarios. Run them against representative, authorized examples in a controlled environment. The result is not proof that the agent is universally safe. It is working evidence about a particular workflow and authority boundary.

An autonomy ladder makes the next decision concrete:

  1. Shadow: The agent observes or proposes while the existing workflow remains authoritative.
  2. Advisory: A person sees the recommendation and makes the decision.
  3. Bounded action: The agent may execute named actions within explicit limits, monitoring, and recovery.

Moving up the ladder is a product change. It should have an owner, evidence from the current mode, known failure behavior, and a rollback or disable path. Model capability alone is not the gate.

Design for the failed handoff

A workflow can fail even when the model behaves as specified. A reviewer may be unavailable, a queue can grow silently, a permission can expire, or a downstream system can accept a request without completing it.

Name the owner of each queue and the signal that shows it is healthy. Define when delay becomes a business exception or incident. Put action revocation, prompt and tool changes, evidence retention, and fallback under change control. These are operating requirements, but they also affect product states, telemetry, and acceptance.

They make transfer possible too. A client team cannot own the system if the authority model exists only in the original builder's head.

Run the workshop before integration

Take one consequential workflow and list its material actions. For each action, record propose, approve, execute, and recover ownership. Add the handoff trigger, context package, receiving role, response expectation, evidence, and fallback. Then select the current autonomy mode and the evidence required for any expansion.

The workshop does not prove compliance, safety, or business value. It reveals whether the intended system has an accountable path through uncertainty and failure.

Before integration, the team should be able to answer three questions for every material action: who takes over, what context arrives with the handoff, and what happens if nobody acts. If those answers are absent, a core part of the product is still unspecified.

Sources and evidence notes

The authority map, handoff taxonomy, and workshop are Scott's proposed operating analysis, not claims that the cited organizations use this exact method.