▶️ LISTEN TO THIS ARTICLE

Once a single agent can solve a task correctly 45% of the time, adding more agents makes the system worse. That's the counterintuitive finding from Google and MIT researchers who ran 180 experiments measuring multi-agent coordination overhead. The degradation isn't marginal. Independent multi-agent systems amplify errors 17.2 times compared to their single-agent baselines. Even centralized architectures, with all their orchestration machinery, still see 4.4× error amplification. The coordination tax compounds faster than the capability gains.

This mirrors what software engineering learned fifty years ago. Fred Brooks observed that adding programmers to a late project makes it later because communication overhead grows quadratically. Three workers need three times the intercommunication of two. A five-person team has 10 communication paths. An eight-person team has 28. The formula is n(n-1)/2, and it applies to agents just as ruthlessly as it does to humans. When Microsoft's Azure team published their multi-agent guidance in 2024, the first recommendation was stark: start with a single agent, and only introduce multiple agents when you're crossing security boundaries or need true parallelism.

Brooks's Law Scales to Silicon

Human team research has consistently found optimal sizes cluster around 4.6 members, with practical recommendations in the 5-7 range. Beyond that, coordination costs overwhelm productivity gains. Agent systems hit the same wall, just faster. At 100 sub-agents, you get context rot and orchestrator bottlenecks. Early versions of Anthropic's multi-agent research system spawned 50 subagents that spent more time distracting each other than advancing the task. The problem wasn't the agents themselves but the combinatorial explosion of communication overhead.

CommCP, a framework analyzing multi-agent communication patterns, found 41% of bandwidth goes to redundant messages. Agents restating what other agents already know, checking status that hasn't changed, confirming coordination that's already happened. SocialVeil's research on communication barriers showed that even intentional friction, like privacy-preserving protocols, reduces mutual understanding by 45%. Every layer of indirection, every handoff, every synchronization point extracts its toll.

The "Multi-Agent Security Tax" paper quantified what happens when you add defensive measures to multi-agent systems. Security constraints reduce collaboration capability because agents can't freely share context or delegate tasks. The tax is necessary for production systems, but it's still a tax. When agents can't trust each other's outputs, they duplicate work. When they can't access shared memory, they repeat discoveries. The coordination mechanisms that make multi-agent systems safe also make them slower.

What Scaling Studies Actually Reveal

The Google/MIT experiments tested single agents against two-agent, three-agent, and four-agent systems across reasoning, coding, and knowledge tasks. On sequential tasks where one step depends on the previous one, multi-agent systems degraded performance by 39-70%. The error wasn't in individual agent capability but in handoff fidelity. Information got lossy at boundaries. Context got truncated. Assumptions got misaligned. By the time the fourth agent in a chain finished its work, the output bore little resemblance to what the first agent started.

ChatDev and MetaGPT illustrate the cost difference between architectures. ChatDev uses seven agents in a waterfall workflow, spending under seven minutes and less than $1 per software generation task, achieving a quality score of 0.3953. MetaGPT deploys five agents but uses expensive serial processing, spending over $10 per HumanEval task for a quality score of 0.1523. More agents, worse results, higher cost. The architecture matters more than the agent count.

But parallelizable tasks tell a different story. When subtasks are genuinely independent, multi-agent coordination overhead becomes multi-agent coordination advantage. The 90% Jump documents the enterprise scenarios where multi-agent systems overcome coordination overhead to deliver transformative performance gains. The same Google/MIT study showed 80.9% improvement on tasks where agents could work simultaneously without blocking each other. Anthropic's research system, when properly architected for parallel literature search and synthesis, delivered 90.2% performance gains over single-agent baselines. The difference is task structure, not team size.

The Parallelization Exception

Read-heavy tasks parallelize cleanly. When you need to scan 50 papers, extract findings, and synthesize themes, five agents working independently beat one agent working sequentially every time. Write-heavy tasks don't. When the output requires coherent narrative or consistent state, handoffs introduce friction. The limits show up fastest in formal verification, where even minor coordination gaps cascade into proof failures.

Anthropic's system works because the architecture matches the task. Literature search is embarrassingly parallel. Each agent gets a subset of papers, extracts structured findings, and returns results to a central synthesizer. No agent blocks another. No sequential dependencies. The orchestrator merges outputs without requiring cross-agent communication. This is the pattern that justifies multi-agent overhead: when coordination is sparse and synchronization is infrequent.

The research on expert teams versus integrative teams shows the same dynamic. When you force experts to reach consensus through deliberation, performance drops 37.6% compared to letting each expert work independently and aggregating their outputs mathematically. The discussion itself degrades results because experts compromise toward mediocrity rather than defending their specialized knowledge. Multi-agent systems face identical pressure when you architect for collaboration instead of parallel execution.

Sizing Agent Teams for Production

The heuristic that emerges from both human and agent research is simple: default to one, scale to the minimum viable team size, and only parallelize when tasks are genuinely independent. If a single agent with access to tools and skills can solve the problem, adding agents won't improve it. If the task requires sequential reasoning, adding agents will make it worse. If the task is parallelizable, size the team to match the number of truly independent subtasks, not the number of agents you can deploy.

Microsoft's guidance to start single-agent and only go multi-agent for security boundaries reflects hard-won production experience. Security boundaries are the legitimate reason to pay coordination overhead. When you need to isolate privileges, separate trust domains, or enforce least-privilege access, multi-agent architecture is the tax you pay for defense in depth. The alternative is a monolithic agent with god-mode permissions, which is worse than coordination overhead.

The 45% threshold from the Google/MIT study provides a quantitative decision rule. If your single agent solves the task correctly less than 45% of the time, a well-architected multi-agent system might help by providing redundancy, voting, or verification. Above 45%, you're trading known capability for coordination risk. The error amplification curve crosses the capability curve, and returns go negative.

Prediction: the multi-agent systems architecture that survives production deployment will look less like ChatDev's seven-agent waterfall and more like Anthropic's parallel research system. Small teams, sparse coordination, independent execution, centralized synthesis. The systems that try to simulate human organizational hierarchy, with managers and specialists and iterative discussion, will collapse under their own communication overhead. Brooks's Law doesn't care whether the agents are biological or synthetic.

Sources

Research Papers:

Industry / Case Studies: