Multi-agent systems rarely fail because an individual agent is bad at its job. They fail at the seams — the moment one agent hands work to another and something essential does not make the trip. The user said they were in Canada three turns ago. The research agent found a caveat that the writing agent never saw. The handoff is the weakest link, and it is the part most architectures leave undesigned.
There are four patterns worth knowing, and choosing between them is mostly a question of how much context loss you can tolerate per hop.
What changed in 2026
- Handoff became a first-class primitive. Agent frameworks stopped treating delegation as an ordinary tool call and added explicit transfer semantics, including what state travels and what does not.
- Structured briefs displaced transcript passing. Teams found that forcing the sending agent to fill a typed summary schema caught more omissions than passing the whole conversation and hoping.
- Return paths became mandatory. The single highest-value addition to most multi-agent systems turned out to be letting a receiving agent refuse the work and hand it back.
- The single-agent counter-argument got stronger. As tool-use reliability improved, a growing share of workloads that were split across agents in 2025 got consolidated back into one agent with more tools.
The four patterns
| Pattern |
What transfers |
Token cost |
Context loss |
Best for |
| Full transcript |
Entire conversation history |
High, grows each hop |
Very low |
Short chains, high-stakes accuracy |
| Structured brief |
A typed summary object |
Low and constant |
Medium, depends on schema |
Most production systems |
| Shared scratchpad |
Pointer to common state store |
Very low |
Low, if reads are disciplined |
Long-running or parallel work |
| Supervisor relay |
Nothing directly; a coordinator re-briefs each agent |
Medium |
Low, centralized |
Fan-out with a synthesis step |
Full transcript is the naive default and it works fine for two hops. By hop four the prompt is mostly history and the receiving agent is paying to read a conversation that is ninety percent irrelevant to its task. Structured briefs solve the cost problem but push the risk into schema design: whatever your schema does not have a field for is information that quietly disappears.
Shared scratchpad is the pattern that scales best for long work, because state lives outside the conversation and agents read only the slice they need. It also introduces the classic distributed-systems problem of stale reads, so it wants discipline about who writes what.
Designing a brief that does not lose things
If you use structured briefs — and most teams should — the schema is the whole design. Three fields do most of the work: the task as the sending agent understands it, the constraints discovered so far, and the explicit list of things that were tried and did not work. That last field is the one people omit and the one that prevents the receiving agent from repeating a dead end.
Add a confidence or completeness marker so the receiver knows whether it is getting a finished handoff or a partial one. And always include a raw-context escape hatch: a pointer the receiving agent can follow to read the original conversation if the brief seems insufficient. The brief is a cache, not a replacement.
For the framework-level mechanics of wiring these up, AI agent frameworks compared covers which ones expose real handoff primitives versus faking it with tool calls.
Common mistakes
- No refusal path. An agent handed work outside its competence will attempt it. Give it a documented way to hand back, and log every time it does.
- Schema without a tried-and-failed field. Downstream agents will re-explore the same dead ends, burning tokens and sometimes producing contradictory conclusions.
- Splitting a linear workflow. If step two always follows step one and never branches, that is a function call, not a multi-agent system.
- Unbounded hop counts. Cap the chain depth. Circular handoffs between two agents that each think the other should handle it are a real and expensive failure mode.
- No per-hop tracing. When output quality drops, you need to know which hop lost the information. Without traces you are guessing.
FAQ
How many agents is too many?
There is no fixed number, but if you cannot name a distinct capability or tool set for each agent, you have too many. Splitting by workflow step rather than by capability is the usual overreach.
Should the handoff include the original user message verbatim?
Usually yes. It is cheap, and paraphrases drift. Include it alongside the brief rather than instead of it.
Does a supervisor agent add latency?
Yes — it adds a model call between each pair of workers. The tradeoff is that context loss becomes centralized and debuggable rather than distributed across every seam.
Can I mix patterns?
Commonly, and you should. A supervisor coordinating agents that share a scratchpad is a well-worn combination for research-style workloads.
Where to go next
For deciding whether you need agents at all, AI agents vs RAG is the right first read. Once a multi-agent system is running, AI agent observability covers the tracing that makes handoff failures visible, and AI agent evaluation frameworks covers scoring the chain end to end.