Agent handoffs: passing a conversation to another agent

A support assistant identifies a billing issue, but the billing specialist needs to ask the customer two more questions. Having the first assistant relay every message adds another place for details to get lost.

The agent handoff pattern lets the billing specialist take over the conversation. The first agent transfers control and the context needed to continue. Billing answers the user directly until the task ends or the conversation needs another owner.

TL;DR A handoff changes who handles the conversation. It differs from calling a specialist for a result while keeping control. Make the receiving agent's context explicit, preserve valid message history, and trace ownership changes so a failed transfer can be understood.

Ownership changes at the handoff

Think of a phone transfer. The first person connects you to the specialist, then stops relaying the conversation. The specialist may later transfer you again, but only one person is handling the conversation at that moment.

That is different from agents-as-tools, where a coordinating agent asks a specialist for information and incorporates the result into its own answer. The distinction is who responds to the user's next turn, not whether both designs happen to use a tool call internally.

In the OpenAI Agents SDK, handoffs are represented as tools available to the model. In LangChain's handoff pattern, a state update changes the active configuration or transfers execution to another agent node. These implementations share the idea of changing the active handler, but their state and message mechanics differ.

A handoff also does not prohibit a coordinator from existing elsewhere in the application. The application can record transfers, enforce allowed destinations, or return control to a supervisor. What changes at the handoff is the active responsibility for the conversation.

Follow a billing transfer

Suppose the customer says: "There are two charges for order 1042." Triage has already confirmed the order identifier and established the customer's account through application authentication. Billing needs the order identifier and the complaint. The authenticated application session supplies authorization to billing tools separately from the conversational payload.

A useful transfer record might look like this:

{
  "from": "triage",
  "to": "billing",
  "reason": "Customer reports duplicate charges",
  "order_id": "1042",
  "customer_request": "Explain the two charges",
  "known_facts": ["Order identifier confirmed"],
  "open_questions": ["Are both charges settled?"],
  "actions_taken": []
}

This is an illustrative application record, not a framework API. It separates the customer's request from verified facts and actions already taken. The record does not establish account access; billing tools must check the authenticated session before returning records. The specialist should inspect the payment records before deciding whether the charges are duplicates; triage's suspicion is not proof.

Billing can now ask a relevant follow-up or use its payment tools. It should not ask for an identifier that was successfully transferred, and it should not assume that a request for an explanation authorizes a refund.

Context transfer is part of the implementation

Passing every message is simple, but it can expose irrelevant information and enlarge the receiving agent's context. Passing only a summary is smaller, but it can omit a constraint or turn an uncertain inference into a fact. Choose the payload around the specialist's task and permissions.

Preserve the user's goal, confirmed identifiers, unresolved questions, and completed actions. Keep provenance for important facts: distinguish what the user said from what a tool returned. If the receiving agent is allowed to retrieve further history, give it a reference to that history rather than relying on a summary alone.

Framework message rules matter too. LangChain's context-engineering guidance for handoffs explains that tool calls need matching tool responses. Forwarding a transfer result without its corresponding call can create invalid history. Its subgraph example includes the relevant AIMessage and ToolMessage when updating the parent graph.

The runtime should apply the new active owner and its context consistently. If the transfer fails halfway through, the conversation needs an explicit recovery path. Do not leave the user waiting while one agent believes the other has taken over.

A network of handoffs is still a design choice

Specialists can transfer directly to one another. LangChain's overview illustrates possible routes between agents, with each active agent able to produce a response.

The arrows show allowed transitions, not a sequence every request must follow. A triage-to-technical-to-billing sequence has two transfers. Whether that is reasonable depends on the task: a conversation that genuinely changes topics differs from agents repeatedly rejecting the same request.

There is no general three-hop boundary after which a supervisor becomes mandatory. Repeated bouncing is the more useful signal. It may mean the specialist scopes overlap, the routing policy is unclear, or crucial context failed to move. A coordinator can help resolve ownership, but it also adds another decision and needs a clear policy itself.

Direct transfers can avoid a coordinator round trip. They do not remove the need for tracing, and centralized routing does not create a complete trace automatically. Both designs need explicit records of state changes and results.

Diagnose a transfer before adding another agent

Log the source agent, destination, transfer reason, active owner, and final task status. Include a reference to the transferred payload so you can inspect it under the appropriate access controls. Avoid copying sensitive conversation content into unrestricted logs.

When a transfer goes wrong, ask three concrete questions. Did the destination fit the user's current need? Did the specialist receive enough accurate context? Did the runtime actually make it the active owner? These checks separate a routing mistake from a context problem or execution bug.

Also inspect repeated actions. If triage has already submitted a request, the specialist must know that before submitting it again. For actions with side effects, the tool layer should support safe retries or duplicate detection; conversation memory alone is not enough.

Choose handoff when the specialist should continue

For the billing example, a handoff is useful because the specialist needs to conduct the next part of the conversation. If billing only needs to return two payment records for a general assistant to explain, calling it as a tool may be enough. If several specialists must contribute to one answer, a supervisor can coordinate them.

A router answers the selection question: where should this request go? A handoff answers the ownership question: who handles the conversation next? They can appear in the same system. The agent-pattern overview shows how these choices fit together.

Sources

• OpenAI: Agents SDK handoffs
• LangChain: Handoffs
• LangChain: Multi-agent patterns