It usually starts on a whiteboard: a box for a planner, another for a researcher, then a writer and a reviewer, with arrows running between them. It looks like a team, and that's part of the appeal, because everyone already knows how a team splits up work.
Then you run it. The planner's plan reaches the researcher as a summary, and the researcher's findings reach the writer as an even shorter one. The reviewer sends the draft back for missing something the planner knew at the very start, so the loop goes round again. Every one of those hops costs tokens, and a little of what the previous agent understood gets lost along the way.
Give a single agent the same tools and, quite often, it would have done better for less.
It's the shape of the task that decides
The evidence here has been a lot more specific over the past year. Researchers at Google Research, Google DeepMind and MIT tested 260 agent system configurations across six benchmarks in Towards a Science of Scaling Agent Systems (last revised in April 2026). On a financial analysis benchmark where the work splits cleanly into independent parts, a centralized multi-agent setup beats a single agent by 80.8%. PlanCraft went the other way. It's a planning benchmark where every step depends on the one before, and every multi-agent variant they tried did worse there, by somewhere between 39% and 70%. They also found that once a single agent was already scoring around 45%, adding more agents tended to make things worse rather than better.
In April, Dat Tran and Douwe Kiela compared single and multi-agent systems on multi-hop reasoning, with the number of thinking tokens held fixed. The single agents matched or beat the multi-agent ones. They also pointed to artifacts in common benchmarks, and in API budget controls, that can make multi-agent gains look bigger than they really are.
The newest work points the same way. In a study published in September, Yishuo Yuan and colleagues found multi-agent collaboration helped on long-horizon tasks with sparse dependencies, but single agents stayed ahead on tightly coupled, sequential workflows. More agents, or agents nested deeper, didn't reliably improve things.
The best-known result in the opposite direction comes from Anthropic. Its multi-agent research system (written up in June 2025) beat a single Claude Opus 4 agent by 90.2% on an internal research eval, using Opus 4 as the lead agent with Sonnet 4 subagents. The same post also spells out the cost. Those systems used about 15 times the tokens of a chat, and on BrowseComp, token usage on its own explained 80% of the variance in performance. Anthropic also says that domains where every agent needs the same context, or where agents have many dependencies on each other, aren't a good fit for multi-agent systems today.
So, splitting helps when the pieces of work don't depend on each other, and it hurts when the work is a chain. Tran and Kiela's result adds a wrinkle: part of whatever gain is left may simply come from spending more tokens, and you could hand those tokens to one agent instead.
Every handoff is a lossy copy
A single agent carries all of its working context from one step to the next, so if it decides something in step three, step nine can still see why. Spread the same work across agents, and every boundary turns into a message. Usually that message is a summary, written by a model that has no idea what the next agent is going to need.
The receiving agent has less information than the sender, so it has to fill in the gaps with guesses, and some of its assumptions will be wrong. Those mistakes are also harder to catch, since no single agent sees the whole task. When the output does come back wrong, you're left working out which agent made the error and which one passed it along without noticing.
There's a more mundane cost as well. Every agent has its own system prompt, its own tool descriptions, and its own conversation to send on each turn. The same Google study found a trade-off between coordination and tool use, where the more tools a task needed, the more the overhead of running several agents hurt.
Split at a permission boundary
Of all the reasons to split, the one that holds up best has to do with authority rather than performance. Say that you have an agent that reads incoming customer emails and can also issue refunds. Every email it reads is untrusted input, and any of them could try to talk it into handing out a refund. Now put the reading and the refunding in separate agents. The reader has no refund tool at all; the most it can do is pass along a request, which can be checked, or sent to a person, before anything moves.
This is the multi-agent design we'd defend hardest, because here the boundary is actually doing something. The agent exposed to hostile text holds as little as possible, and the agent with the dangerous tool only ever sees structured requests.
We did get one part of this wrong early on. When an agent starts workers, it seemed obvious that a worker shouldn't get any tool its parent doesn't have, so we built that rule in. Then we took it out again, because it broke the most common pattern there is: a supervisor whose only tool is starting workers, handing shell or file access to the workers that need it. What a tool list describes is a role, and trust is a different question, so trust is what we pass down. In practice, a worker inherits the files its parent is allowed to touch and the way its parent's shell commands are run, and starting a child can't be used to get around a restriction that applies to the parent.
Split when the context runs out or the work is wide
There are two other reasons we'd accept. One is context. Some jobs need more reading than a single context window can hold, or more than it can hold while still reasoning well. A worker that reads a large codebase or a long contract and hands back a short answer keeps the main agent's context clean, so the main agent gets the conclusion without the hundred pages behind it.
The other is wide, independent work, like checking ten sources or comparing five vendors. None of those parts depends on the others, so running them in parallel saves time and nothing gets lost at the handoff. It matters that they only read, though. Parallel workers writing the same record or the same file need coordinating, and coordination is exactly where the overhead creeps back in.
If a proposed split doesn't separate permissions, doesn't get around a context limit and doesn't run independent work in parallel; it's probably just an org chart, and you're better off with one agent.
When you do split, make the handoffs boring
Once you have more than one agent, most of the risk sits in what happens between them. We prefer a fixed graph, with each agent's inputs named up front, its output passed on as a defined result, and branch decisions you can read back later. Letting the agents work out among themselves who speaks next does have its uses, but it's the hardest version to test, and to explain after an incident.
We also treat the whole tree of agents as a single run. In the systems we build, every agent in the tree draws on one shared token budget, so when a worker hits the limit, it halts and that halt reaches its parent. Failures from all the agents count toward one circuit breaker, which means a run stops when its workers keep failing rather than spawning more of them. If a worker runs out of turns, it returns its partial work to the parent, and we don't count that as a failure. A worker spawned at runtime can't start workers of its own, and there are caps on how many workers one request can start and how many of them can run at once.
There's nothing clever about any of this. These rules are there because a group of agents can fail in ways a single agent can't. One runaway branch can burn through the whole budget, and a bad prompt can start a hundred workers before anyone notices.
Start with one agent and make the second one earn its place
Before you split a design into several agents, it's worth going through these questions for each boundary you're proposing:
- Does this split separate permissions, or just job titles?
- Would one agent really run out of context doing this work?
- Are the parallel parts independent of each other, and do they only read?
- What exactly crosses this handoff, and what gets left behind?
- Have we measured a single agent on the same task, with the same token spend?
If most of your answers point to one agent, build one agent with good tools and put the savings into evaluation. And when a workflow really does have the shape that justifies several, our post on the rise of multi-agent systems covers where they fit in the business.
So, add that second agent when a test tells you to, rather than when the whiteboard does.
