Designing a human handoff that preserves context and authority

A safe handoff transfers the decision, evidence, current state and bounded authority—not a transcript dump or a vague request for someone to take over.

Categories: Architecture & engineering, Governance & privacy Series: Agent systems

“A human is in the loop” says almost nothing about whether the human can make a meaningful decision. If an agent escalates with a 40-message transcript, no clear question and a button labelled Approve, the person is present but the handoff is weak. If the same person receives a concise decision packet but the agent retains a broad credential and keeps acting, the authority boundary is weak too.

A handoff is a controlled transfer of work. It should preserve enough context for judgement, identify the exact decision, and move authority into a state the system can enforce.

Trigger the handoff from conditions, not discomfort

Do not make escalation depend only on the model’s self-reported confidence. Define observable triggers tied to the workflow’s consequences:

  • required evidence is missing or materially conflicting;
  • the requested action exceeds amount, scope or risk limits;
  • a policy exception is needed;
  • the action is irreversible or difficult to compensate;
  • a verification step fails;
  • the agent reaches a retry, time or cost limit;
  • the user disputes a material interpretation;
  • a security or privacy boundary may have been crossed; or
  • the workflow has no valid automated transition.

Each trigger should map to a queue, role and response expectation. “Send to a human” is not routing. A billing exception, suspected security incident and ambiguous customer request need different expertise and authority.

Hand over a decision packet, not a summary

The receiving person needs a structured record with links to underlying evidence:

Field Purpose
Decision requested States the exact question the person must resolve
Current workflow state Distinguishes proposed, pending, partly executed, failed and verified work
Requested outcome Preserves the initiating person’s goal and any later change
Material evidence Shows source, version, relevance and unresolved conflicts
Actions already taken Names tool, arguments, actor, time and confirmed effect
Proposed next action Specifies target, parameters, consequences and reversibility
Authority required Identifies the permission or exception the recipient can exercise
Open uncertainty Separates missing information from model interpretation
Safe options Presents proceed, modify, request evidence, reject or stop as applicable
Trace link Connects the packet to the full execution record

This is not a model-generated narrative accepted without checking. Populate deterministic fields from workflow and authorisation records. Allow the model to draft a concise explanation, but make the origin of each field visible.

The NIST AI RMF Core calls for policies that define and differentiate roles and responsibilities in human-AI configurations. A handoff packet makes that abstract requirement operational at the moment responsibility matters.

Preserve evidence without overwhelming the recipient

The person should be able to inspect the source behind a claim without reading the entire trace first. Use layered disclosure:

  1. the decision and current state;
  2. the few facts that materially affect it;
  3. links to original records with provenance;
  4. the proposed action and its limits; and
  5. the complete trace for investigation.

Show conflicts rather than synthesizing them away. If the agent found two effective dates, display both and explain which rule would change the action. If a tool result is stale, mark its timestamp. If a source was unavailable, say which conclusion that absence prevents.

W3C’s Trace Context specification standardizes how an interaction can be correlated across distributed services. A workflow handoff can use the same principle: carry a stable trace or workflow identifier so the decision, evidence and later effect remain connected across the agent, queue and business system.

Transfer authority explicitly

Context and authority are different payloads. Giving a reviewer the evidence does not grant the agent permission to act, and an approval should not become a reusable credential.

Bind approval to:

  • a named approver and accountable role;
  • one workflow instance;
  • the exact action type, target and material parameters;
  • maximum amount or scope;
  • a short validity period;
  • the state and evidence version reviewed; and
  • whether modification requires reapproval.

If the proposal changes after approval, invalidate the approval. A customer approving shipment to one address has not approved whatever address the agent later infers.

The IETF’s OAuth 2.0 Token Exchange standard distinguishes delegation—where the actor remains visible while acting for another principal—from impersonation, where the actor may be indistinguishable in the rights context. Agent systems should preserve actor and subject where infrastructure permits, and use narrow scope and lifetime. The broader lesson holds even without OAuth: do not turn a human decision into invisible, standing authority.

Freeze, continue or branch deliberately

When a handoff begins, define what the agent may still do.

  • Freeze: no further actions until the person decides. Use for high-consequence or conflicting states.
  • Continue read-only: the agent may gather evidence but cannot change external state.
  • Continue bounded work: independent low-risk steps may proceed under an existing mandate.
  • Branch: create an investigation path while preserving the original workflow state.

Record the choice as a state transition. Otherwise, a human may review a proposal while the agent changes the conditions underneath it.

A workable state model is active → handoff-requested → acknowledged → decided → executing → verified, with explicit exits to cancelled, expired or needs-evidence. Queue delivery is not acknowledgement. Approval is not execution. Execution is not verification.

Design for the recipient’s real ability to intervene

Meaningful oversight requires more than information. The person needs time, competence, access and authority to change the outcome. Research on meaningful human control argues that system design must consider appropriate authority and ability in the surrounding organisational practice, not only the interface.

Test these practical questions:

  • Does the queue reach someone who owns this decision?
  • Can that person inspect the evidence in the available time?
  • Can they reject, modify, pause and revoke—not only approve?
  • Does the interface reveal prior effects and remaining reversibility?
  • Will the workflow honor their decision if another message arrives first?
  • Is workload low enough that review is not ceremonial?

The NIST AI Use Taxonomy provides language for examining how people use AI across different roles. Apply that lens to each handoff role rather than treating “human” as a generic control.

Verify the return path

After the person decides, the runtime should verify that the approved action—and only that action—occurred. Return a receipt that includes the decision identifier, executing identity, tool result and authoritative end state. If execution is ambiguous, do not ask for approval again until the system reconciles whether the first action took effect.

Also close the communication loop with the initiating user. Tell them whether the case is awaiting review, needs information, was changed, was declined or completed. Do not describe a queued handoff as resolution.

Test the seams where handoffs fail

Run end-to-end scenarios that include:

  1. a human never acknowledges;
  2. approval arrives after expiry;
  3. two reviewers send conflicting decisions;
  4. the proposal changes while pending;
  5. the agent acts before approval;
  6. execution times out after an external effect;
  7. the wrong queue receives sensitive context; and
  8. a reviewer asks for more evidence and the workflow resumes correctly.

Measure time to acknowledgement, time to decision, rework, unauthorised effects, duplicate actions and whether the recipient could identify the decision without reading the full transcript. Interview reviewers as well: telemetry cannot show whether the evidence was intelligible or the options were realistic.

A good human handoff does not make people absorb the agent’s uncertainty. It converts that uncertainty into a bounded decision with traceable evidence and enforceable authority. That is what keeps “human oversight” from becoming a label pasted over an uncontrolled workflow.

Get the agent release checklist

Working through this decision?

Tell us about the agent workflow and the question behind it, and we will suggest the smallest useful next step.

A little more clarity

Questions worth asking.

Start with the questions that shape a better decision.

Should the full conversation be included in a human handoff?

Keep the trace available, but lead with a structured handoff packet. The person needs the decision, state, evidence, actions, authority and next safe options without reconstructing them from a long transcript.

When should an agent hand work to a human?

Use explicit triggers such as missing authority, conflicting evidence, irreversible impact, failed verification, policy exceptions or exhausted recovery. Do not rely only on the model saying it is uncertain.

Does human approval transfer responsibility to the agent?

No. Approval should identify the accountable human decision and bind it to a specific proposed action. The runtime remains responsible for enforcing scope and recording what was executed.