What is an agent handoff?
A customer repeats their account number for the third time because the agent that transferred them kept the transcript and dropped everything else. That gap is the whole engineering problem.
Agent handoff
handoffs (OpenAI Agents SDK)
An agent handoff is the transfer of an in-progress task from one agent to another, or from an agent to a person. The state has to travel with it: the conversation so far, whatever the agent was allowed to do, and any work it had already finished.
Buyers use "agent handoff" for two different things, and vendor decks rarely say which one they mean.
Agent-to-agent handoff moves a task between specialised AI agents inside one system. A router agent decides a request needs a refund processed. It hands the task to an agent built only for refunds. The OpenAI Agents SDK names this primitive directly. Its handoff makes the receiving agent treat the transfer as a fresh turn, with the prior conversation already attached.
Agent-to-human handoff escalates a task out of the AI system entirely. A person takes over. They can approve an exception, take a threat seriously, or handle a customer who is done talking to a bot. This is the other half of human in the loop. It fires mid-task, instead of waiting for a scheduled checkpoint.
The state has to survive the transfer
A handoff that only carries the transcript is a demo, not a system. Three things have to move with the task, and most implementations only carry the first.
The conversation is the easy part: what was said, in order. Entitlements are harder. They are what the first agent was allowed to see or do. Get this wrong and the second agent silently gains access nobody granted it, or loses access it needs to finish the job. Partial work is the part teams forget entirely: a draft already written, a record already looked up, a step already completed. Redo that work, and the handoff cost the user time instead of saving it.
- 01Conversation: what was said, kept in order and attributed correctly.
- 02Entitlements: what the receiving side can see and do, not assumed from context.
- 03Partial work: anything already produced or verified, so the next step does not repeat it.
- TriggerScope exceeded, or a rule fires.
- PackageConversation, entitlements, partial work.
- RouteNamed destination, not a queue.
- ReceiveNext agent or person confirms context.
- ResumeContinues, does not restart.
Skip the package step and the receiving side starts from zero. That is a transfer, not a handoff.
Related questions
01How is an agent handoff different from human in the loop?
Human in the loop is a scheduled checkpoint: the system always pauses at a known step for approval. A handoff to a human is triggered mid-task, when something the agent meets falls outside what it can handle. Both put a person in the process, at different moments and for different reasons.
02Does a handoff need to be a separate framework feature?
No. Some agent frameworks name it as a primitive. But the underlying requirement is the same either way: move the conversation, entitlements and partial work together. Plain application code that calls a second agent or opens a ticket can do that just as well.
03What should trigger a handoff to a person?
A rule you can state in advance. Confidence drops below a threshold, or the request falls outside the agent's defined scope. Or the situation is urgent and a wrong AI answer would cost too much. Design the trigger before the agent ships, not after the first bad outcome.
04What happens if nobody is available to receive the handoff?
That has to be a designed state, not a gap. A voice agent escalating an emergency call needs a defined fallback: a second number, or a voicemail with a guaranteed callback window. Without one, the caller just hears the line go dead.
