An agent context handoff should carry the reason for the work.

A support workflow gets three quarters of the way through a refund, meets a condition it cannot resolve, and posts “needs review” into a queue. The reviewer opens it and finds a proposed refund amount and nothing else. Everything that would make the decision quick has been dropped on the way: who asked, what they actually asked for, the policy ceiling the workflow was told to respect, the fact that the order is already marked returned, and the reason the agent stopped instead of proceeding. A context handoff between agents has the same shape, except that the second agent cannot walk over and ask.

Five things that go missing at the boundary

Intent. The request as the requester phrased it, not the agent’s paraphrase of it. A paraphrase has already made choices, and those are the choices a reviewer needs to be able to question.

Constraints. Budget ceilings, date windows, forbidden accounts, tone requirements, regulatory limits. These are usually present at the start of a run and absent by the end, because they were satisfied silently and never recorded as satisfied.

State already changed. This is the field most often missing and the most expensive to miss. A workflow that has already written a draft, reserved inventory, opened a ticket or submitted a partial batch has committed side effects, and the receiver needs to know which ones before choosing anything. The computer-use benchmark literature treats this as a first-class difficulty: OSWorld 2.0 is built around long workflows with hidden state and stateful recovery, on the basis that knowing what already happened is a separate skill from knowing what to do next.

Authority. The scope the run operated under, and who granted it. Delegated authorisation standards already model this shape. RFC 9396 defines rich authorization requests so that a grant can carry fine-grained detail about what may be done to which resource, and RFC 9728 lets a client discover which authorisation server actually governs a protected resource. A handoff that omits the scope forces the receiver to guess whether the blocked action needs a different grant or a different person.

Evidence. Which source supported which claim. Without it, the receiver either trusts everything or re-verifies everything, and both are expensive. It also matters for safety: the prompt-injection literature is consistent that retrieved content can carry instructions as well as information (Greshake et al., 2023; indirect prompt injection field study, 2026), so a handoff should reference where a claim came from rather than paste the source text forward into a new context window.

Three boundaries, three failure shapes

Agent to human. The receiver can ask questions, but asking is slow and the queue is long. The typical failure is a handoff that looks complete and is not: a clean summary with no visible gaps, which the reviewer approves because nothing signalled that anything was uncertain. The fix is to record uncertainty in a field instead of leaving it to the tone of the summary.

Agent to agent. The receiver cannot ask at all, and will act on whatever it is given. Protocols that carry cross-agent work already put the description of the receiver in a fixed place: A2A publishes an agent card at /.well-known/agent-card.json so that a caller can find out what an agent does before handing it anything. The protocol does not decide for you what state and constraints to include in the task itself. The typical failure here is an agent that receives a goal with no history and helpfully redoes work that was already committed.

Agent to sub-agent. A parent fans work out to children and reassembles the results. The context that reaches each child is a design decision, and the usual instinct is to give each one less than it needs so that the parent stays in control. That produces children that solve slightly the wrong problem and a parent that cannot tell, because each child reported success against its own narrowed brief. This is a structural argument, not a measured one: if a sub-agent cannot see the constraint, it cannot report that it violated the constraint.

One rule covers all three: write every handoff so that it would still be enough for the least informed receiver. Over-specifying to a colleague costs a few seconds of reading. Under-specifying to a peer agent costs a side effect nobody intended.

A minimal handoff record

The object below is an illustration written for this guide. It is not a standard, and it resembles no particular product.

{
  "handoff_id": "ho_2026_09_19_0041",
  "from": { "actor": "agent:refunds", "run_id": "run_8fd2" },
  "to": { "actor": "human:billing_reviewer", "reason": "authority" },
  "intent": "Customer asked for a full refund on order 41180 because two items arrived damaged.",
  "constraints": [
    "Refunds above 200 require a billing owner",
    "Do not contact the customer before the amount is settled"
  ],
  "state_changed": [
    { "at": "2026-09-19T09:14:02Z", "action": "created_draft_credit_note", "reversible": true },
    { "at": "2026-09-19T09:14:40Z", "action": "marked_order_returned", "reversible": false }
  ],
  "authority": { "scopes": ["billing:read", "billing:draft"], "missing": "billing:write" },
  "evidence": [
    { "claim": "two items damaged", "source": "ticket:41180#msg7" },
    { "claim": "order value 244.00", "source": "tool:billing.get_order" }
  ],
  "question": "Approve a 244.00 credit, approve a partial amount, or reject and return to the customer?",
  "expires": "2026-09-20T09:14:00Z"
}

Each field answers a question the receiver would otherwise have to ask.

The reversible flag inside state_changed is small but useful: a receiver who can see two reversible actions and one irreversible one knows at once which part of the run is still negotiable.

Where handoffs meet approval and retries

A handoff whose reason is authority is an approval request, and the design of that particular case is covered in Human approval workflows for AI agents. Two details from the standards side are relevant here. RFC 9470 defines step-up authentication for the case where a request needs a stronger authentication level than the current session has, which is the protocol-level version of the same pause. The MCP tools specification supports multi-round-trip flows when a tool needs further input rather than forcing a bare failure, so a mid-task request for information does not have to end the run. The pattern library for approval, handoff and recovery gives named versions of these moves, such as the context packet, returning the reason for the work and handing back a step the agent should not take, each with a public example.

The connection to retries runs the other way. Every retry is a handoff from one attempt to the next, and the attempt record and the handoff record want the same fields. If an attempt cannot say what it changed before it failed, the next attempt cannot know whether it is repeating a side effect or resuming from one. That argument, and what to record per attempt, is in Record agent retries as product history. Recovery paths depend on the same state: see Agent error recovery: design the path back for the error contract that makes resumption possible.

A handoff record is also a working document for the next decision, not the run’s archive. Reference the trace rather than embedding it, and redact at write time. NIST’s AI Risk Management Framework treats accountability and transparency as properties to be balanced against privacy and security in context, so a longer record is not automatically a better one.

A checklist for the boundary

1. The original request appears in the requester’s words somewhere in the record.
2. Every constraint the run was given is listed, including the ones that were satisfied.
3. Every committed state change is listed, with a reversibility flag.
4. The scope the run used, and the scope it lacked, are both named.
5. Each substantive claim points at where it came from.
6. The pause is written as a question with enumerated answers, not as a status.
7. The record has an expiry, and something happens when it lapses.

Run the list against a handoff your own product produces today. The missing field is usually state_changed, and the reason is usually that no part of the system was ever asked to maintain it.

Frequently asked questions

What is an agent context handoff? An agent context handoff is the moment a workflow passes unfinished work across a boundary: from an agent to a person, from one agent to another, or from a parent agent to a sub-agent it has spawned. The handoff succeeds when the receiver can act without reconstructing the task. It fails when only the output crosses and the intent, constraints, changed state, authority and evidence stay behind.

What should a context handoff between agents include? At minimum: the original request in the requester’s own words, the constraints the work is bound by, every state change already committed, the scope the work ran under, the evidence behind each claim, and the specific question that caused the pause. Keeping those fields in a structured record rather than a prose summary means the receiver can check them one by one instead of inferring them.

How is a handoff different from an approval request? An approval request is one kind of handoff, the kind where the blocking question is about authority. Other handoffs pause for missing information, an ambiguous scope, or a condition the workflow was told to stop on. Treating them all as approvals produces confirmation dialogs that ask a person to say yes to something they cannot evaluate.

Should a handoff record include everything the agent saw? No. A handoff is a working document for the next decision, not an archive of the run. NIST’s AI Risk Management Framework describes trustworthy AI as balancing accountability and transparency against security and privacy in context rather than maximising any single property, and a handoff record that carries raw retrieved content also carries whatever instructions were hidden in it. Reference the trace, redact at write time, and keep the record to what the next decision needs.

At a handoff, a workflow either keeps its reasoning or throws it away.