Handoffs Between Agents: Designing Clear Ownership of the Next Move
Agent handoffs work when ownership, state, context, pending actions, and user expectations move together; ambiguous transfer creates duplicated work and accountability gaps.
A handoff changes who owns the next move
OpenAI’s orchestration guidance draws a clear line between handoffs, where a specialist takes over the conversation, and agents-as-tools, where a manager remains responsible. [1] That distinction should be visible in system state. A handoff is not simply calling another model; it changes who owns the next user-facing decision and therefore who must carry the relevant context and policy. For a production team, that means the architecture should expose a concrete contract rather than relying on the model to infer organizational etiquette. The more agents involved, the more valuable explicit boundaries become because small ambiguities multiply across messages, retries, and handoffs.
Ownership must be explicit
A useful role definition names the job, required evidence, allowed tools, authority boundary, and return contract. That turns a social metaphor into an operational interface and gives evaluators something concrete to test.
Transfers need explicit context and acceptance criteria
OpenAI’s multi-agent primitives let agents spawn, message, wait, and interrupt one another, which makes coordination explicit rather than implicit. [2] A transfer packet should include the objective, completed work, unresolved questions, applicable constraints, expected deliverable, and what the receiving agent is authorized to do. Without that packet, the specialist must reconstruct the mission from scraps. This also affects the motivational experience. Users gain confidence when progress has visible ownership and when the system can explain why a specialist was involved. Hidden delegation may be technically elegant but still feel erratic if the interface cannot connect each action back to the user’s chosen goal.
The receiving agent should inherit state, not ambiguity
The A2A specification models collaboration around stateful tasks, messages, status, history, and artifacts. [3] Those concepts are useful even inside one product. A handoff should preserve the task identifier and current status so the next agent knows whether it is continuing, waiting for input, verifying, or producing an artifact rather than starting an unrelated new job. A useful implementation pattern is to record the decision as structured state: what was delegated, why this role was selected, what evidence it returned, and whether the result was accepted. That record supports debugging, evaluation, and later correction without requiring access to private chain-of-thought.
State should travel with the task
Independence is valuable only when the branches can actually contribute different information. If every worker inherits identical context and instructions, the system may multiply tokens without multiplying perspective.
Protocol-level task state makes ownership easier to inspect
Anthropic’s production multi-agent work stresses detailed delegation instructions because vague subagent tasks cause duplication and gaps. [4] The same applies at handoff boundaries. “Take it from here” is not a contract. The next role needs a clear scope and should acknowledge whether it can accept the assignment with the context and tools it has. The important boundary is between helpful specialization and organizational theater. Adding another agent should reduce uncertainty, isolate risk, or increase coverage. If it only adds another voice without a distinct responsibility, the system is paying coordination cost without buying capability.
Production teams need recovery when the next agent cannot accept
NIST recommends clear roles, lines of communication, and oversight responsibilities for AI configurations. [5] Handoffs must therefore preserve accountability. If an action later fails, operators should be able to tell who proposed it, who approved it, who executed it, and which agent currently owns remediation. Ambiguous transfer makes both auditing and recovery harder. Evaluation should therefore include failure cases where agents disagree, return late, repeat work, or provide incomplete evidence. A team architecture is robust when the coordinator handles those cases predictably rather than assuming every worker will always return a perfect answer.
Rejection is a valid response
The product should treat uncertainty as state. A worker can return complete, blocked, partial, disputed, or needs-review rather than forcing every interaction into a success/failure binary that hides coordination problems.
Human oversight depends on clear accountability across transfers
Transfers need failure paths. The receiving agent may lack a credential, capability, policy allowance, or required source. It should be able to reject the handoff with a reason and send control back rather than improvising beyond its authority. The coordinator can then select another specialist, ask the user for missing information, or reduce the scope. For gamified AI, progress indicators should reflect durable task state rather than internal activity. Spawning three workers is not three units of progress. A milestone is earned when a verified dependency is resolved, an artifact is accepted, or the user’s objective measurably advances.
Users should know when a specialist truly takes over
User visibility should match the significance of the transfer. Internal delegation that does not change responsibility may remain invisible. A true specialist takeover should be announced with a short explanation of why it is happening and what changes. This keeps the mental model intact and prevents the user from wondering why tone, capabilities, or approval requirements suddenly changed. Designers should also protect reversibility. When a coordination decision can be changed cheaply, the system can explore. When it changes external state or user commitments, ownership, approval, and rollback need to be explicit before the action occurs.
The user needs continuity
The final system should preserve one accountable path back to the user’s objective. Internal agents can be replaced, rerouted, or upgraded, but the product must still explain what is happening in terms the user can understand and control.
Treat handoffs as transactions with acknowledgement and rollback
The safest model treats a handoff like a transaction: prepare the context, nominate the receiver, obtain acknowledgement, transfer ownership, and keep a rollback path until the new owner has accepted. That level of discipline may sound formal, but it prevents the most common multi-agent coordination failures—duplicate action, abandoned tasks, contradictory responses, and uncertainty about who is responsible for the next move. This keeps the architecture aligned with human agency: the team may be complex internally, but the user should retain a clear view of the objective, meaningful choices, and the consequences of agent actions. Multi-agent sophistication is valuable only when it makes that relationship stronger rather than more opaque.
Works Cited
- 01OpenAI Developers — Orchestration and Handoffs developers.openai.com
- 02OpenAI Developers — Multi-agent developers.openai.com
- 03A2A Protocol Working Group — Agent2Agent Protocol Specification a2a-protocol.org
- 04Anthropic — How We Built Our Multi-Agent Research System anthropic.com
- 05NIST AI RMF Playbook — Govern airc.nist.gov
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.