When One Agent Is Not Enough
Most multi-agent architectures are one agent with extra latency, extra cost and a new class of failure. The diagrams are appealing — labelled boxes, arrows between them, each box a specialist with a job title — and the measured results usually are not. Two cases genuinely win, and recognizing them is worth more than any orchestration framework.
That is a claim, and it needs arguing rather than asserting, because the opposite claim is the one the industry repeats. So this page argues it three ways: from what a boundary actually does to information, from the token and turn arithmetic of a handoff, and from a measurement Vera ran on the 120-ticket eval set with a role-based team on one side and the existing single agent on the other.
The Default Answer Is One Agent
One agent has properties that are easy to stop noticing until they are gone. Every fact the run has gathered is visible to the decision that uses it, in full, with its original wording. The whole run is one message list, so a bug reproduces by replaying it and a trace reads top to bottom without stitching. There is one place where a turn limit is counted, one place where spend is measured, and one dispatcher deciding what may execute.
Its limits are real and both are measurable: the context fills up (Chapter 5) and tool-selection accuracy falls as the tool list grows (Chapter 3). Neither of those limits is named "we should be multi-agent". Each has cheaper answers first — capping oversized tool results, budgeting per task type, deleting two tools, rewriting a schema description. A design conversation that opens with "should this be multi-agent" is running backwards. The question is which specific limit this agent is hitting today, with a number attached, and whether a second context is the cheapest thing that relieves it.
The Two Cases That Win
The first is context isolation: some material actively harms the decision that would otherwise sit next to it. A seller-liability dispute needs a conclusion drawn from forty carrier tracking records, and those records are 12,000 tokens of scan codes and depot names in a decision context budgeted at 8,000. A subagent reads them in its own window and returns three sentences. That is a measurable improvement rather than an architectural preference, and Topic 54 makes the full argument.
The second is genuine parallelism over independent work with a deadline. When a seller's warehouse flooded, 260 open orders each needed an individual assessment before the next dispatch window. Those 260 assessments have no dependency on each other, so eight of them can run at once and the wall clock divides. One ticket that reads sequentially — look up the order, check the carrier, read the policy, decide — does not become parallel because you drew it as three boxes. Topic 57 prices both.
Everything else is usually a function call. If the proposed specialist has a fixed job with a known input and a known output — summarize this passage, classify this ticket, extract these fields — that is one model call inside a function in your dispatcher, not an agent. It costs one round trip instead of a loop with its own prompt, its own tool schemas, its own turn budget and its own way of failing. Give it a name in code and move on.
What Splitting Actually Costs
A handoff is not free and the bill has four lines. Sundry's numbers make them concrete, and every one of them is paid on every ticket that crosses the boundary.
| What the split adds | Why it happens | Sundry's measurement |
|---|---|---|
| A second fixed prefix | Each agent carries its own system prompt and tool schemas, re-sent on every one of its turns | 980 tokens per turn for the returns specialist |
| Extra turns | Building the envelope and reading the summary are model turns that did no customer work | +1.4 model calls per handed-off ticket |
| Serial latency | The receiver cannot start until the sender finishes, so the two runs add rather than overlap | +4.4 s median on the handoff itself |
| Lost fidelity | The receiver gets a summary; the evidence behind it stays in a context it will never see | 12,000 tokens in, about 180 tokens out |
Read the last row twice, because it is the whole argument in both directions. A 98% reduction is exactly the benefit when the material was noise, and exactly the failure when it was not. The sender chooses what to keep without knowing what the receiver will need, and it chooses using a model that is fluent, agreeable and under a turn budget. There is a fifth cost that is worse than any of these and it gets its own section in Topic 54: a subagent that ran out of turns reports success it did not achieve, and nothing in the summary says so unless you made it.
The Role-Team Anti-Pattern
The common shape is a team of role-named agents: a researcher, a writer, a critic, passing prose between them like a newsroom. The appeal is that it maps onto something familiar. The problem is that the roles are a prompt. Each agent is the same model with a different paragraph at the top, and a paragraph at the top is available for free inside a single agent. Nothing about the split adds knowledge, skill or authority that three well-placed instructions in one system prompt did not already provide.
Vera built it rather than argued about it: a research agent with the four read-only tools, a reply writer with no tools at all, and a policy critic with search_policy. Against the single agent on the same 120 tickets, it scored 84% where the single agent scored 86% — a two-point difference, which on this set means the two are indistinguishable — while handle time went from 34 seconds to 61 and tokens came in at 2.3 times the baseline. The version that mattered took twenty minutes: three sentences added to the existing system prompt telling the agent to gather before answering, to cite the policy passage it relied on, and to check its draft against that passage. Same effect, one context, no boundary.
The mechanism behind the fidelity loss is worth stating plainly, because it is what makes role teams degrade rather than merely cost more. The writer never sees the carrier's last scan. It sees the researcher's characterization of it — "delivery confirmed" — and cannot notice that the scan is a depot arrival rather than a doorstep handover, which is the distinction the entire case turns on. Each boundary is a lossy compression whose losses are chosen by a component that does not know what the next stage needs. Chain three of them and the last agent is writing confidently about a case it has never read.
Deciding With the Eval Report
The decision is testable, so test it. Run both configurations against the eval set and compare the five numbers from Chapter 9: outcome score, trajectory score, cost per case, p95 latency and invariant violations. Require the split to win on outcome or on cost before adopting it. "Cleaner" is not one of the five, and neither is the diagram.
Respect the instrument while you read it. A set of 120 cases detects roughly a seven-point change and cannot see a two-point one, so an outcome move of a point or two is no reason to adopt anything. That cuts both ways, which is uncomfortable: it also means a small drop is not proof the split hurt. When the outcome column says nothing, the case has to be built on the columns that are not noisy, which for Sundry turned out to be latency, paid for in cost.
Keep the single-agent version working after the split ships. One flag, both configurations in the eval pipeline, and the comparison stays a command rather than a project. Sundry re-runs it every quarter against the written conditions in Topic 58, and twice the numbers have moved enough to make the conversation real. An architecture you cannot re-measure is an architecture you cannot revisit, and the ones nobody can revisit are the ones still in production five years after their justification expired.
One agent — everything stays in one context, so nothing is lost in a handoff and one trace explains the whole run. Its limits are the two you can measure: context size, and tool-selection accuracy as the list grows. Both have cheaper fixes than splitting.
Several agents — contexts stay small and focused, at the price of information loss at every boundary, more turns, higher cost, and traces that have to be stitched back into one story. Each agent also needs its own budget, its own tool permissions and its own way of reporting that it failed.
Split when a context must not contain something, or when the work is genuinely parallel and has a deadline. Not because the diagram looks tidy, and not because the system prompt has grown long.
- Splitting by role because it mirrors a human support team — humans split for reasons that do not apply here: limited attention, unshared expertise, and the fact that one person cannot work a Tuesday and a Thursday at once.
- Splitting to shorten the system prompt — it is 420 tokens, 14% of a typical Sundry context, and one handoff costs more than twice that in fixed prefix alone before anybody has answered a customer.
- Adopting a multi-agent pattern from a blog post without running the eval comparison — the numbers are usually worse on cost, indistinguishable on outcome, and nobody checks because the diagram already convinced everyone.
- Building an orchestrator before there are two things to orchestrate — you get the coordination cost, the depth-limit bug and the stitched traces immediately, and the benefit at some unspecified later date.
- Default to one agent, and make the second one prove itself on the eval set before it ships to a single real ticket.
- Split only for context isolation or true parallelism, and write down which of the two this split is, in one sentence, next to the code.
- Count the handoff cost explicitly in the comparison — fixed prefix per turn, extra model calls, added latency — rather than comparing outcome scores alone.
- Keep the single-agent configuration runnable and in the eval pipeline, so re-deciding the architecture costs one command.
Knowledge Check
A team splits the Sundry agent into a researcher, a writer and a critic. What does measuring it against the single agent most likely show?
- An outcome score it cannot be distinguished from, at more than twice the tokens and nearly twice the handle time
- A clear outcome gain, because three specialized prompts will beat one general prompt across every class of ticket
- A lower bill, because each agent carries a much shorter system prompt than the combined single agent did
- A faster reply, because the three agents work on their parts of the same ticket at the same time
Which of these is a justified reason to add a second agent?
- Forty carrier records must be read to reach one conclusion, and their 12,000 tokens would fill the decision context
- The system prompt has grown three sections and splitting it would give each agent a shorter one
- The support desk is organized into a triage tier and two specialist tiers, so the software should match
- Traces have become long and hard to read, and separate agents would give each one its own trace
What does a handoff to a second agent cost that a function call in your dispatcher does not?
- A second fixed prefix on every receiving turn, plus the evidence that does not survive being summarized
- A separate provider account for each agent, since every one of them needs its own credentials and rate limit
- A larger context window, because both of the agents' transcripts have to fit inside one request together
- An extra retrieval pass, because the policy library must be searched again for the receiving agent
A proposed split moves the outcome score from 86% to 88% on the 120-ticket set. How should that number enter the decision?
- As no evidence at all, since two points sits inside the set's noise band
- As a small but real gain, because both runs used the same cases and a paired comparison is more sensitive
- As a reason to adopt, since two points compounds with the other improvements shipped in the same quarter
- As a reason to reject, because two points is too small to repay the complexity the split introduces
Why keep the single-agent configuration runnable after the split has shipped?
- Because it keeps re-deciding the architecture cheap, and the conditions that justified the split will change
- Because the loop falls back to it automatically whenever a specialist times out part-way through a ticket
- Because the single agent can grade the specialists' runs, which halves what the eval suite costs per merge
- Because running both keeps the prompt cache warm, which is what makes the specialists cheap on repeat tickets
You got correct