Google Just Proved More Agents Can Make Things WORSE -- Here's What Actually Does Work

Multi-agent AI systems can degrade in performance as more agents are added—because coordination overhead grows faster than useful work. A December 2025 Google-and-MIT study found that scaling agent count can flip the expected “more compute = better outcomes” assumption, with multi-agent efficiency dropping sharply in tool-heavy settings. That finding matters because 2026 is likely to force teams to run far more agents under tighter budgets, and the wrong architecture could turn “agentic” ambition into costly failure.

The core mechanism is serial dependency: points where one agent’s progress blocks another’s—waiting on shared tools, locks, shared state, or agreement about what exists. At small scale, these bottlenecks hide behind the promise of parallelism. At larger scale, they dominate. The study reported that once a single-agent accuracy exceeds roughly 45% on a task, adding more agents yields diminishing or even negative returns. In environments using 10 or more tools, multi-agent efficiency fell by a factor of 2 to 6 compared with single-agent runs. The implication is blunt: past a threshold (the transcript cites around 20 agents), many agents spend most of their time queued rather than contributing.

Industry frameworks often recommend agent designs that resemble human teams—continuous operation, shared context, dynamic coordination, and inter-agent communication infrastructure. But practitioners scaling to hundreds of agents tend to converge on a different architecture aimed at eliminating serial dependencies. Cursor and Steve Yaggi’s Gas Town are cited as examples where the system is structured around two-tier roles rather than flat teams. In Cursor’s experiments, giving agents equal status and coordinating through shared files led to lock-holding and bottlenecks; output collapsed to a small fraction of what parallelism promised. Flat teams also became risk-averse, gravitating toward small safe changes while harder work went unclaimed.

The scalable alternative is a strict two-tier hierarchy: planners create tasks, workers execute them in isolation, and a judge evaluates results. Workers stay ignorant of the broader project context and do not coordinate with each other. This “minimum viable context” prevents scope creep and reduces conflict resolution—two major sources of waiting and rework. A second counterintuitive rule follows: avoid shared state. Tool access becomes contention, and tool selection accuracy degrades as the number of available tools grows, even with large context windows. The transcript argues for small, stable tool sets (about three to five core tools) with additional tools discovered progressively.

Because long-running agents accumulate context pollution—drift, lost attention, and entropy—the architecture must plan for endings. Instead of treating continuous operation as the goal, systems should run in episodic cycles: workers execute, externalize results, and terminate so the next cycle starts with clean context. Gas Town’s approach is described as storing workflow state externally so progress survives agent crashes and restarts.

Finally, the transcript claims that many failures come from specification and coordination issues rather than raw technical bugs, and that prompts should be treated like API contracts. The practical takeaway for 2026 is to invest in orchestration—feeding, monitoring, merging, and scheduling many simple workers—rather than building highly autonomous, deeply context-aware “super agents.” The winning pattern is thousands of relatively constrained workers operating in short bursts against tightly defined goals, coordinated by external systems that keep complexity out of the agents themselves.