Every handoff loses context and adds latency, so the first design question is whether to split the work at all. When you do, transfer a structured summary of state and intent, never raw conversation history. The receiving agent needs to know what was established, not what was said.
The instinct when an agent struggles is to add another agent. Sometimes that is right. More often it converts one hard problem into two easier problems plus a new failure surface at the boundary between them.
The boundary is where the engineering is.
At a glance
- A single agent with good tools handles more than teams expect
- Handoffs lose context by construction, not through poor implementation
- Transfer structured state, never raw transcript
- The receiving agent must be able to reject a handoff
- Latency compounds along the chain
- Attribute failures to a specific agent, or debugging becomes impossible
When is splitting justified?
| Reason to split | Legitimate? | Note |
|---|---|---|
| Tool sets are large and disjoint | Yes | Reduces selection error by shrinking each agent’s options |
| Different permission scopes required | Yes | A read-only agent and a write agent is a real boundary |
| Genuinely different models suit each task | Yes | Cheap classification then expensive reasoning |
| Independent teams own each capability | Yes | Organisational, and a valid engineering constraint |
| The prompt is getting long | Usually no | Prune and restructure it first |
| It seems more sophisticated | No | Adds failure surface for no measured gain |
| One agent is failing | No | Diagnose why; a second agent inherits the same problem |
The first four are about constraints that genuinely exist outside the agent. The last three are about the agent itself, and splitting rarely addresses them.
What must actually transfer?
Figure 1 — Two ways to hand off
Pass the transcript
The receiving agent inherits the full conversation history and is left to work out what matters.
It consumes context, buries the relevant facts among irrelevant exchanges, and forces the second agent to re-derive conclusions the first had already reached.
Lossy and expensive
Pass structured state
A compact object: what the user wants, what has been established, what was tried, what remains, and any identifiers already resolved.
The receiving agent starts from conclusions rather than from raw material, and the handoff is inspectable.
Compact and auditable
A structured handoff is testable; a transcript handoff is not. You can assert that the state object contains what the next agent needs. You cannot assert anything useful about whether a transcript conveyed it.
The minimum useful payload: the original goal, verified facts with their sources, resolved identifiers, actions already taken, what failed and why, and the specific reason for the handoff.
That last field is the one most often omitted and most useful. An agent receiving work without knowing why it was escalated frequently repeats what the previous agent already tried.
What are the four patterns?
- Supervisor. One coordinator holds the goal and delegates sub-tasks, receiving results back. Easiest to debug because control is centralised.
- Sequential pipeline. Fixed stages, each passing output forward. Predictable, and inflexible when the work does not fit the sequence.
- Peer handoff. An agent transfers ownership entirely and drops out. Simple, and prone to losing the thread if the receiver cannot proceed.
- Escalation. Work moves up a tier on failure or low confidence. The pattern most closely matched to a real constraint, and the one worth reaching for first.
Supervisor is the safest default, because one component always knows the overall state. Peer handoff distributes that knowledge and makes “where did this go wrong” genuinely hard to answer.
Watch for this
A receiving agent must be able to refuse a handoff. Without rejection, work lands with an agent that cannot progress it and either fails opaquely or hands it onward again, producing loops between agents that each believe the other should handle it. Make rejection an explicit return path, and log it.
Where does latency go?
It compounds, and the compounding is worse than the arithmetic suggests.
Each handoff adds at least one model call to decide the transfer and one to orient the receiving agent, on top of whatever work actually happens. A three-agent chain can spend more time on coordination than on the task.
The mitigation is to keep chains short and flat. Two levels of supervisor is almost always too many, and a chain where each agent hands to the next is the worst shape for both latency and debuggability.
How do you debug across a boundary?
- One trace ID spanning the whole run, with each agent’s work as a nested span rather than a separate trace.
- Record the handoff payload itself, so you can see exactly what crossed the boundary.
- Attribute the outcome to an agent, because “the system failed” is not actionable when three components participated.
- Measure per-agent success as well as end-to-end, since a chain can succeed while one link is consistently poor.
Point 2 is what makes handoff bugs findable. Most cross-boundary failures are a payload missing a field the receiver needed, and that is obvious once you can see the payload and invisible otherwise.
Where do teams go wrong?
Splitting before measuring
Multi-agent architectures get chosen for their shape rather than in response to a measured limitation. The result is coordination overhead solving a problem nobody demonstrated existed.
Letting agents share mutable state
Two agents writing to the same working memory produce races and ordering bugs that are exceptionally hard to reproduce given non-determinism. Pass state explicitly at handoff instead.
Giving every agent every tool
If each agent can do everything, the split provides no benefit and multiplies the selection problem. Disjoint tool sets are one of the few strong reasons to split, and they only help if actually kept disjoint.
What do experienced teams do differently?
They define the handoff payload as a schema before building either agent.
Writing the state object first forces clarity about what each side owns, and it becomes a contract that can be validated. Teams that build the agents first and the handoff last end up with a payload shaped by whatever happened to be available rather than by what the receiver needs.
They also collapse agents back together when the reason for splitting disappears. Multi-agent architectures accumulate, and a chain that made sense when tool sets were disjoint often does not after the tools were consolidated.
A short glossary
- Handoff
- Transfer of work from one agent to another, carrying whatever state the receiver needs to continue.
- Supervisor pattern
- A coordinating agent that holds the overall goal and delegates sub-tasks, receiving results back.
- Peer handoff
- Complete transfer of ownership, where the originating agent drops out of the run.
- Handoff payload
- The structured object passed across a boundary, ideally defined by a schema.
- Rejection path
- An explicit route for a receiving agent to decline work it cannot progress.
Key takeaways
- Every handoff loses context and adds latency, so the default answer is not to split.
- Legitimate reasons are disjoint tool sets, different permission scopes, genuinely different models, and team ownership.
- Transfer structured state, not transcripts, because only structured payloads are testable.
- Always include why the handoff happened, or the receiver repeats what was already tried.
- Supervisor is the safest pattern because one component always knows the overall state.
- Receiving agents must be able to reject work, or agents loop handing it to each other.
- Use one trace spanning all agents and record the payload, since most cross-boundary bugs are missing fields.
Frequently asked questions
When should I split work across multiple agents?
When a constraint exists outside the agent: tool sets that are large and disjoint, different permission scopes, genuinely different models suiting each task, or separate teams owning each capability. A long prompt or a failing agent are not reasons to split.
Should I pass conversation history between agents?
No. Raw transcript consumes context, buries relevant facts among irrelevant exchanges, and forces the receiving agent to re-derive conclusions the first already reached. Pass a structured state object containing goal, established facts, resolved identifiers and what was tried.
What should a handoff payload contain?
The original goal, verified facts with sources, already-resolved identifiers, actions taken, what failed and why, and the specific reason for the handoff. That last field is most often omitted and prevents the receiver repeating earlier attempts.
Which multi-agent pattern is safest?
Supervisor, because one component always holds the overall state and control is centralised, which makes failures attributable. Peer handoff distributes that knowledge and makes locating a failure considerably harder.
Can a receiving agent refuse work?
It must be able to. Without an explicit rejection path, work lands with an agent that cannot progress it and either fails opaquely or passes it onward, producing loops where each agent believes the other should handle it. Log every rejection.
How much latency does a handoff add?
At least one model call to decide the transfer and one to orient the receiver, on top of the actual work. A three-agent chain can spend more time coordinating than working, so keep chains short and flat rather than deep.
How do I debug a failure that crossed agents?
Use one trace ID spanning the whole run with each agent as a nested span, record the handoff payload itself, and attribute outcomes to specific agents. Most cross-boundary failures are a payload missing a field the receiver needed.
Should agents share working memory?
No. Two agents writing to shared mutable state produce races and ordering bugs that are extremely hard to reproduce given non-determinism. Pass state explicitly at the handoff, which is both safer and inspectable.
References
- Anthropic. Model Context Protocol documentation, covering tool scoping that underpins disjoint agent capabilities.
- OpenTelemetry. Traces and spans, the model for a single trace spanning several components.
- Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. Why passing transcripts degrades the receiving agent.
