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

> What an agent context handoff must carry across a boundary: intent, constraints, changed state, authority, evidence, and how handoffs should be recorded.

Published: 2026-09-17  
Updated: 2026-09-17  
Changelog: 2026-09-17: Expanded from a short note into a full guide with sources, examples and FAQ.  
Canonical: https://agentexperience.tech/insights/preserve-context-through-handoffs/  
Tags: workflows, delegated action, recovery, context, multi-agent

**Summary**

An agent context handoff usually moves the artefact and loses the job. Five things go missing at the boundary: the intent behind the request, the constraints that bound it, the state that has already changed, the authority the work ran under, and the evidence for whatever is being claimed. Carry them in a small structured record, use the same record whether the receiver is a person, a peer agent or a sub-agent, and write the pause as a named question instead of a status change.

1. An agent context handoff that carries only the artefact leaves the receiver to rebuild the task before deciding anything.
2. Keep the intent in the requester's own words rather than the agent's paraphrase, and record each constraint as satisfied rather than letting it vanish silently.
3. Write the pause as a question with enumerated answers and an expiry rather than a status such as needs review.
4. Write the record so that it would be enough for the least informed of its possible receivers.
5. List every committed state change with a reversibility flag, because changed state is the field most often missing and the most expensive to miss.
6. Keep the record a working document for the next decision: reference the trace, redact at write time, and do not paste retrieved content forward.

A context handoff between agents, or from an agent to a person, usually carries the artefact and drops the job. The receiver then has to rebuild the task before they can decide anything.

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](https://github.com/xlang-ai/OSWorld-V2) 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](https://www.rfc-editor.org/info/rfc9396/) defines rich authorization requests so that a grant can carry fine-grained detail about what may be done to which resource, and [RFC 9728](https://www.rfc-editor.org/info/rfc9728/) 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](https://arxiv.org/abs/2302.12173); [indirect prompt injection field study, 2026](https://arxiv.org/abs/2604.27202)), 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](https://github.com/a2aproject/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.

```json
{
  "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.

| Field | Question it answers | What breaks without it |
| --- | --- | --- |
| `intent` | What was actually asked for? | The reviewer evaluates the agent's plan instead of the customer's request |
| `constraints` | What was this bound by? | A decision that quietly breaches a policy nobody restated |
| `state_changed` | What is already true in the world? | Duplicated side effects, or a rollback that misses a step |
| `authority` | Under what scope did this run? | The handoff goes to someone who also cannot act |
| `evidence` | Why should I believe this? | Blanket trust, or a full re-verification |
| `question` | What decision is being asked for? | A queue item that means "look at this" and nothing more |
| `expires` | How long is this still valid? | An approval granted against a world that has moved on |

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.

![A run pauses on a named question and writes one handoff record. The record carries the intent in the requester's words, the constraints including those already met, the state already changed and whether it can be undone (highlighted), the authority with the scope used and the scope missing, the evidence with a source for each claim, the question with answers to pick from, an expiry, and a link to the trace rather than a copy. The same record goes to any receiver: a person, a peer agent or a sub-agent.](https://agentexperience.tech/diagrams/handoff-record.svg)

*Figure: What a handoff record carries across the boundary, whoever receives it.*

## 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](/insights/approval-is-a-workflow/). Two details from the standards side are relevant here. [RFC 9470](https://www.rfc-editor.org/info/rfc9470/) 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](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 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](/insights/approval-handoff-recovery-patterns/) 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](/insights/retries-are-product-history/). Recovery paths depend on the same state: see [Agent error recovery: design the path back](/insights/design-for-recovery/) 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](https://www.nist.gov/itl/ai-risk-management-framework) treats accountability and transparency as properties to be balanced against privacy and security [in context](https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/), 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.