Agent handoffs: what happens when one AI passes work to another

A handoff passes control of a task from one AI agent to another. What context to carry, how information gets lost in the transfer and which risks to design for.

info Quick Definition
An agent handoff is the transfer of control of a task or a conversation from one AI agent to another, together with the context the second one needs to continue. It is the point in a flow where the most information gets lost if nobody designs it.

What is a handoff, and how is it different from delegating?

When an agent should not solve part of the work, it passes that part to a more specialized one. The first stops driving; the second takes the task.

The OpenAI Agents SDK formalizes this. A handoff is presented to the model as a tool: passing to the Refund Agent appears as transfer_to_refund_agent. When the model picks it, the specialist becomes the active agent for the rest of the turn. By default, according to its documentation, the new agent takes over the conversation and sees the entire previous history. An input filter (input_filter) lets you change what it sees.

The alternative is not handing over control. In the same SDK, a manager agent keeps the conversation and calls specialists as tools with Agent.as_tool(). That tool can take structured parameters instead of a history. This is the road of the orchestrator-worker pattern: whoever coordinates stays in charge and gathers the results. A handoff, in contrast, moves the owner.

To see where each one fits among the other designs, read multi-agent patterns and agent orchestration. This article stays with what happens in the transfer itself.

What do you pass to the other agent?

What the receiver cannot see does not exist for it. Claude Code makes this clear with subagents: each one starts with a fresh, isolated context window, without the conversation history. That is why its documentation recommends restating the rules that matter in the delegation message, for example “ignore the vendor/ directory”.

A useful transfer includes:

  • Objective: what must be achieved, in one sentence.
  • What is done: concrete results, not the whole process.
  • Pending items: what is missing and what it depends on.
  • Constraints: what must not be touched, deadlines, budget limits, tone.
  • Response format: how to return the result so the sender can use it.

The OpenAI SDK has a place for part of this: input_type defines a schema for the handoff arguments, meant for metadata the model generates, such as a reason or a priority. The documentation clarifies that it does not replace the next agent’s main input. And to help the model understand when to hand over control, it offers a recommended prompt prefix, RECOMMENDED_PROMPT_PREFIX.

How is context lost in the transfer?

There are three common paths:

  1. By omission. The sender does not write what it took for granted, such as “we already ruled out option B because it fails rule X”.
  2. Through compaction. When a long conversation is summarized, the summary can drop nuance. Anthropic warns that overly aggressive compaction can lose subtle but critical context, whose importance only becomes apparent later.
  3. Through decay. As the context grows, the model recalls what is in it less accurately. Anthropic calls this context rot and concludes that context is a finite resource with diminishing marginal returns.

Anthropic proposes two remedies. The first is for the subagent to return only a condensed summary, often 1,000 to 2,000 tokens, instead of everything it read. The second, described in its multi-agent research system, is for agents to store their work in an external system (a file, for example) and pass the coordinator a lightweight reference. That avoids the “game of telephone” of summarizing a summary. Keeping state notes outside the context window, to be pulled back in later, also helps.

What risks does it bring, and how do they show up in design?

The first is clarity. For a person watching the system, the transfer is a risk point. Make visible:

  • who owns the task now,
  • why it changed hands,
  • what was transferred and what was left out,
  • and how to go back if the receiver gets it wrong.

If the change of owner is hidden, an error looks like the last agent’s fault when it started in the previous step.

The second is privacy. The OpenAI SDK documentation asks you to treat the receiving agent and its model provider as recipients of the forwarded history, and warns that nested history (an optional beta feature) does not redact sensitive data. Before passing the whole conversation, decide what has to arrive.

The third is the wrong context: a receiver buried in noise is slower and costs more tokens. When the receiver is a person, the transfer has its own rules; see AI to human handoff.

When should you NOT use a handoff?

  • When the work is continuous and tight. If two agents pass the task back and forth twenty times, a single conversation with good context is usually simpler and cheaper.
  • When the receiver needs to see the full process to decide. A summary does not replace a decision that depends on detail.
  • When nobody can validate the receiver’s result before it reaches the user.

Example

Illustrative example: a support agent handles a customer asking for a refund. It verifies the purchase and the time window, and sees that the policy requires human approval above a certain amount. It transfers to a review queue with this package: the order, the date, the amount, the stated reason, the two applicable policies with their links and the specific question the person must answer. The reviewer does not ask the customer anything again. If the package had only said “customer wants a refund”, the reviewer would have started from zero.

Common mistakes

  • Passing the whole conversation without filtering. The receiver drowns in noise and data it does not need gets sent.
  • Passing only the last message. The constraints already agreed on get lost.
  • Not saying what was done. The receiver repeats steps that cost time or money.
  • Assuming the receiver will “know” what the user wants. What is not written does not get transferred.
  • Not logging the transfer. Without a record, nobody can later reconstruct who decided what.

Sources

Frequently asked questions

What is a handoff between agents?
It is the moment an AI agent transfers control of a task or a conversation to another agent. In the OpenAI Agents SDK, the chosen agent becomes the active one for the rest of the turn and, by default, sees the entire previous history.
What is the difference between a handoff and using an agent as a tool?
In a handoff, control moves to the specialist. When a manager agent calls another as a tool, the manager keeps the conversation and receives the result. The OpenAI Agents SDK documents both paths.
What should a handoff include?
The objective, what has already been done, what is still pending, the constraints and the format the answer should come back in. If the receiver does not share the history, whatever is not written in the message does not reach it.
Is context lost in a handoff?
It can be if you do not design for it. Anthropic warns that overly aggressive compaction can lose subtle but critical context, and suggests storing results outside the conversation and passing only references.
What privacy risk does a handoff have?
The forwarded history reaches the receiving agent and its model provider. The OpenAI Agents SDK documentation asks you to treat them as recipients of that information and warns that nesting the history does not redact sensitive data.