What Is an Agent Handoff?
An agent handoff is the transfer of an in-progress task from one AI agent to another, after which the receiving agent carries the work forward instead of the sender. Three things have to move with it: the conversation or task history, the current state of the task (what is settled and what remains open), and the authority to act on the user's behalf. A handoff that drops or misstates any of them leaves the receiving agent working from an incomplete or outdated picture.
Updated
What is an agent handoff?
Handoffs appear wherever work is split among specialist agents: a triage agent routes a billing question to a billing agent, which passes a refund to a refund agent. OpenAI's Agents SDK makes the handoff one of its few primitives, and its orchestration guide separates it from calling another agent as a tool. With agents as tools, "A manager agent keeps control of the conversation and calls specialist agents." With a handoff, "A triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn." Control moves, not just a question.
Between systems built by different teams or vendors, the Agent2Agent (A2A) specification frames the same move as delegating a task. A2A is "an open protocol created by Google" that the Linux Foundation launched as a project on June 23, 2025. The specification, now at version 1.0.0, aims to let agents work together "without needing access to each other's internal state, memory, or tools."
How agent handoffs work
Inside one framework. In the OpenAI Agents SDK, "Handoffs are represented as tools to the LLM": a handoff to a Refund Agent appears to the model as a tool named transfer_to_refund_agent. By default, "it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history." Authorization is the developer's job: the docs say to "perform the check at the start of on_handoff, before any application side effects," and note that "Tool input guardrails apply to function tools, not handoffs."
Across agents. In A2A, a client agent sends a message and the remote agent creates a Task: "The fundamental unit of work managed by A2A, identified by a unique ID." A contextId "logically groups multiple related Task and Message objects." Interrupted states, TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED, hold the task until the client supplies input or credentials, and results come back as Artifacts.
| What moves | OpenAI Agents SDK | A2A |
|---|---|---|
| Conversation | Full history by default; an input filter changes it | Messages grouped by contextId; the remote agent may keep its own history under it |
| Task state | A run context, which "is not sent to the LLM" | A Task with a status and Artifacts |
| Authority | Checked in your on_handoff code | Authentication requirements in the Agent Card; an auth-required task state |
Why agent handoffs matter in real-time systems
Much handoff advice is about the conversation. The failure that costs money is about state. When a handoff carries a conclusion the sender reached from what it read, shared state can change between that read and the receiver's action. An illustrative timeline:
t=0.0s Triage agent reads order 7731: paid, no refunds issued
t=2.5s A voice agent on a separate call refunds order 7731 in full
t=4.0s Triage hands off: "order 7731 is eligible for a full refund"
t=9.0s Refund agent acts on the handoff and refunds order 7731 againNeither agent reasoned badly. The handoff passed a stale conclusion as if it were current state. Four practices prevent it:
- Hand off references, not conclusions. Pass the order ID and the version that was read, so the receiver reads the current value itself.
- Check and act together. The refund commits only if the order still has no refund, through a conditional update or a serializable transaction on the state being changed.
- One owner per task. Claim the task when it transfers, so the sender or a second receiver cannot keep working it.
- Record the transfer. Log who handed off, what was passed and under what authority, so an outcome can be traced.
The wider problem of agents acting on shared state is covered in multi-agent coordination.
FAQ
Related terms
Tool calling, or function calling, lets a language model ask its application to run an external function and return the result as input to its next step.
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Shared context means every service and agent in a decision system reads one internally coherent snapshot of state, instead of private copies that diverge.
A decision ledger is an append-only record of automated decisions: what was decided, on what inputs, under which policy and authority, and what changed.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.