Agent teams stop paying off once one agent clears 45% success

The idea looks obvious at first glance, and yet multi-agent systems still aren't the default in most applications. Put concretely: if one LLM-based agent can do a task, several agents ought to do it better. You can split the work, or convene a "council" so they check each other. In practice, teams of agents often run slower, cost more and behave dumber than one. A paper by researchers at Google and MIT, "Towards a Science of Scaling Agent Systems", takes on an engineering question worth asking: when is a multi-agent system actually more effective than a single agent?

What was compared, and why it matters

The authors single out "agentic" tasks — the ones that need not a one-shot generation but multi-step interaction with an environment, digging out missing information, revising the plan against feedback and holding a model of the world in mind (a model that will itself keep changing and sharpening). These are exactly the tasks where multi-agent systems look most promising, and exactly where they lose most of their efficiency to coordination problems.

Rather than trade in special cases, the researchers ran a large and careful sweep: 180 configurations across four benchmarks and three LLM families (OpenAI, Google, Anthropic). The comparison is worth trusting because parity was enforced across systems — the same tools, the same prompts, the same token budgets. In other words, the team systems weren't handed extra resources or any aces the other systems didn't hold.

Five ways to organize a team

The study compares five architectures: a single large language model working alone (SAS) and four multi-agent designs. In the independent architecture, each agent solves the task separately and the answers are aggregated afterwards. In the centralized architecture, an orchestrator splits the task into subtasks for the agents, then evaluates and aggregates what comes back. In the decentralized architecture, agents exchange messages in a shared chat. The hybrid architecture combines centralized control with horizontal communication between agents. These descriptions lean on organizational vocabulary — "agents", "orchestrator" — but what matters is not the metaphor, it's the concrete measurement of how tasks get solved under each of these organizational approaches. Multi-agent architectures hand different models different assignments, yet they don't look optimized for resource use: several models end up doing substantially overlapping computation. In some scenarios errors compound, and it isn't clear when spending several times the resources pays off.

Where the team delivers and where it doesn't

Multi-agent systems gained the most on Finance-Agent under centralized coordination (up to +80.9%), which fits the shape of a task where teamwork helps: it breaks into subtasks, agent solutions can be checked, and a mistake is catchable at the level of the orchestrator. On BrowseComp-Plus (dynamic web navigation), the best multi-agent system — decomposition — adds +9.2% over SAS. Discussion among peers may simply be useful in a messier environment: one agent spots a path to the answer, a second checks it, a third notices that we have wandered off the right page. Results on PlanCraft (planning in Minecraft) were unexpectedly bad for every multi-agent system studied (-39% to -70%). That seems obvious once you think about sequential planning in real life, where each step depends on the one before it. Any additional coordination costs time and tokens without supplying new information. No gain showed up because the task can't be parallelized effectively.

The two main coordination problems: tokens and errors

The first unpleasant consequence is that coordination is almost always expensive. Token overhead averaged roughly +58% for independent agents, +263% for decentralized, +285% for centralized and as much as +515% for hybrid. Under a fixed budget that means one thing: the system spends a meaningful share of its resource on negotiating rather than on thinking about the task. The second risk is error amplification. When one agent makes a mistake, another may not merely repeat it but wire it into its own chain of thought and amplify it further. This was most visible in the Independent architecture, where errors were amplified 17.2x relative to the SAS baseline. Centralized setups, by contrast, handled cascading errors better — up to 4.4x — because every decision passed through the orchestrator's bottleneck, which provided some deterministic checking.

Predicting the right approach in advance

The most useful part of the paper is where the authors try to turn their observations into a prediction. They take several measurable properties of coordination (efficiency per token, overhead, redundancy, error amplification) and build a score that explains a substantial share of the variance (R² = 0.513) and appears to transfer to new domains without refitting.

The main result is a "team usefulness threshold" rule: if a good single agent already solves the task at a success rate of at least 45%, further coordination often brings diminishing and sometimes negative returns. Which is to say, "help a strong agent with a team" is not the most universal strategy.

The more tools a task uses, the larger the coordination overhead, assuming the token budget stays fixed. My guess is that tools already drain the budget — they demand a lot of context and have to be used carefully. Adding coordination on top simply spreads the budget too thin.

What this changes in building agent systems

The work argues that a team of agents is not always more effective. If a task decomposes and allows independent verification, coordination — centralized coordination especially — delivers a huge gain in quality. If a task is strictly sequential and requires agreement on a model of the world, redundant negotiation between agents backfires fast.

What stands out is that the paper shows not only which design beats which, but why: through token economics, error cascades, observable coordination metrics. That moves multi-agent system design closer to engineering and away from trying architectures at random.