Google's research and real-world practice reveal why more AI agents often means worse results — and what architecture actually scales
A solo presentation by Nate B Jones on why multi-agent AI systems fail at scale and what design principles actually work in production.
Summary
Nate B Jones opens by citing a December 2025 Google and MIT study finding that adding more agents to a system can actively degrade performance — not just produce diminishing returns, but make outcomes worse. He argues that the industry's prevailing assumptions about multi-agent AI, drawn from LinkedIn posts and framework documentation, are producing systems that collapse under scale, and that Gartner's prediction of 40% of agentic AI projects being cancelled by 2027 is likely correct for this reason. Jones then draws on real-world examples from Cursor (running hundreds of agents simultaneously) and Steve Yegge's Gas Town framework (orchestrating 20–30 agents as a single engineer) to identify five design principles that both teams independently converged on — principles that contradict most framework recommendations. The central insight is that simplicity scales because complexity creates serial dependencies, and serial dependencies block the conversion of compute into capability. Jones argues that the winning architecture for 2026 keeps workers simple and isolated, places complexity in the orchestration layer, and designs explicitly for agent endings rather than continuous operation.
Key Takeaways
FULL TRANSCRIPT
The seductive pitch for multi-agent AI — and why it breaks at scale
Nate B Jones: The pitch for multi-agent AI systems is seductive, but we're learning the wrong lessons about how to build them. I get the pitch. What if you had 10 or 100 AI agents working on a task instead of just one? Imagine how much more productive you could be. And we do see cases where that's true — it's not a hypothetical. Cursor is running hundreds of agents on tasks at a time. Steve Yegge's Gas Town orchestrates 20 to 30 agents simultaneously on sustained development work, and he's just one engineer. The technology does work. But what nobody is talking about is that the systems that scale don't often look like what the frameworks recommend.
Industry consensus often compares agents to human teams. They share context. They coordinate dynamically. They operate continuously. You see this even in cases like the Google press release for the Agent Development Kit. The frameworks provide a kind of elaborate infrastructure for inter-agent communication. But almost all of it is unproductively incorrect, or just wrong — wrong in ways that only become apparent when you try to scale, which is obviously what really matters.
And this is having real-world implications. This is not just theoretical multi-agent problems. Gartner predicts 40% of agentic AI projects are going to be cancelled by next year, by 2027. I think they're right, and I think I know why. The teams that fail will be the ones who built just what they were told to build by looking at LinkedIn posts and X.
The strange thing is that the practitioners who've actually scaled have converged on a completely different architecture. Cursor and Yegge weren't comparing notes. They were solving the same problem: how do you run many agents without drowning in coordination overhead? And they independently discovered the same counterintuitive solutions. When smart people are working on the same problem without talking to each other and they arrive at the same answer, it's probably worth paying attention to — especially if the problem is one of the most highly leveraged problems in tech, which multi-agent architecture sure is.
I've spent the last couple of weeks sorting through the disagreement between what the research claims, what the frameworks recommend, and what actually works in production. What follows are principles that hold up — the ones where theory and practice point in the same direction. And more importantly, I want to give you a sense of why these principles work, because 2026 is going to force us to look at problems underneath the surface that have similar underlying dynamics.
This is the core insight to take with you: simplicity scales because complexity creates serial dependencies, and serial dependencies block the conversion of compute into capability. And the conversion of compute into capability is what multi-agent architecture is all about.
The Google/MIT finding: more agents, worse outcomes
Nate B Jones: In December of 2025, a study from Google and MIT found something that should worry anyone planning to scale agents this year. Adding more agents to a system can make it perform worse. Not diminishing returns — actual degradation of the system. More agents, worse outcomes. The research called this a finding that contradicts the industry's prevailing assumption that adding additional compute actually improves outcomes.
The intuition that doesn't work is this: if one agent finishes a task in an hour, 10 agents should be able to finish that same task in 10 times the speed — in about six minutes. This is how most computational resource allocation works. More GPUs, faster training. More servers, higher throughput. Intuitively you would think agents would scale the same way.
But what actually happens is different. When you add agents, you add entities that need to coordinate. Every coordination point is where agents wait for each other, duplicate work, and create conflicts that need resolution. As agent count grows, coordination overhead grows way faster than capability. Past a given threshold, 20 agents will produce less than three ever would. Seventeen are effectively standing in line. That's what serial dependency means.
The Google/MIT study quantified this. Once single-agent accuracy exceeds about 45% on a task, they found that adding more agents yields diminishing or negative returns. And in tool-heavy environments with 10 or more tools, multi-agent efficiency dropped by a factor of two to six compared to single agents. It was even more ineffective because of the multi-tool environment.
In 2025, you could avoid this by not scaling — you could just say we won't touch it. But in 2026, huge cost reductions are going to make it not just economically attractive but really a requirement to run hundreds of agents. The companies that give up on AI agents, as Gartner predicts, are going to be the losers. So if you can figure out how to deploy agents correctly, you will have an architecture that can actually take advantage of the cheap compute that's coming online.
What the agentic AI community currently believes — and where it goes wrong
Nate B Jones: The agentic AI community has converged on design principles that often feel like settled wisdom. I want to name them here because I think it's useful.
Number one: multiple specialized agents should collaborate, interact, and delegate in patterns that mimic human teams. Agents should integrate tools — at least as many as are useful for the task — to extend their capabilities. They should operate continuously, accumulating context and learning the codebase. There's a lot of conversation about memory and context windows, and so much conversation about long-running agents that it's just in the water now. They should be autonomous enough to set their own sub-goals without needing explicit instructions. And you should be able to scale simply by adding more of them.
These principles do work at small scale. They fail at large scale in ways that frameworks don't warn you about. The pattern across failure modes is often the same: intuitive implementations create serial dependencies between agents. A serial dependency is any point where one agent's work blocks another — waiting for a lock on a tool, checking a shared state, coordinating on who handles what. At small scale, you don't care. You get the result you want. You see the vision realized and you think you've got it. But enough serial dependencies emerge at scale that the value of the parallelism you created proves to be fragile. It collapses. You're paying for 100 agents but getting the throughput of five.
So the rules that scale turn out to be different. They are the ones that eliminate serial dependencies, and they look almost too simple compared to the sophisticated architectures that seem like they should work better. But one of the big lessons of 2026 is that if you want to run hundreds of agents that you actually use, you need to be philosophically committed to simplicity — and you arrive there because everything else doesn't work.
Rule 1: Two tiers, not teams
Nate B Jones: Here are the rules of simplicity and scaled agents — the kind of scale that gets to hundreds of agents.
Rule number one: two tiers, not teams. There's often an assumption that agents should collaborate like a human team. Cursor actually tested this directly. They gave agents equal status and let them coordinate through a shared file. Each agent could check what the others were doing, claim tasks, and update status. It sounded wonderful, but it failed in ways we need to pay attention to. Agents would hold locks too long. They would forget to release locks on tasks. And even when locking worked, it became a bottleneck because most time in the agentic system was simply spent waiting. Twenty agents ended up producing roughly 10% of the output of two or three agents.
They tried simpler concurrency control, but that didn't solve it either. The unexpected failure mode is behavioral. With no hierarchy, a flat team of agents becomes very risk-averse. They gravitate toward small, safe changes — that's what Cursor found. Hard problems on the list sit unclaimed because claiming means taking responsibility for potential failure, while other agents rack up easy wins. If this sounds surprisingly human, it should. Work churned without progress. The diffused responsibility that was supposed to enable autonomy instead meant nobody took responsibility.
The team dynamics metaphor imports human coordination problems that we have had for centuries. Meetings are synchronization points where everyone waits for everyone else. Status updates create read-after-write dependencies. There are technical analogues to all of our human rituals that we are porting over to agents and discovering in real time don't work well.
So what happens if you change that rule? If instead of assuming a flat team, you assume a strict two-tier hierarchy: planners create tasks, workers execute them, a judge evaluates results. Workers do not coordinate with each other. They don't even know the other workers exist. Each picks up a task, executes it in isolation, pushes a change, and terminates. You can use a tool like Git to handle conflicts after the fact.
Yegge arrived at the same structure independently with his Gas Town blog post. His Polecats are ephemeral workers that spin up, execute a task, hand it into the merge queue, and get fully decommissioned. They do not coordinate with other workers. What he terms the Mayor sits above them, creating and assigning work. The architecture emerged from four different failed orchestration patterns. What he learned is that peer coordination does not scale — the same thing Cursor learned.
Research on multi-agent hierarchies backs up what Cursor and Yegge are learning in practice. Two-level systems significantly outperform both flat architecture and, interestingly, deeper hierarchies as well. Flat systems have maximum serial dependencies — we've seen how that plays out. But deep hierarchies with three or more levels of agents accumulate drift as objectives mutate through delegation layers. You're essentially playing telephone with more layers of agents, and that doesn't work well either.
Rule number one: two-tier systems.
Rule 2: Workers stay ignorant
Nate B Jones: Rule number two: workers stay ignorant. The consensus says agents should understand context, adapt to overall goals, and that smarter agents produce better results. In fact, as we've seen hinted above, workers perform better when they're in a two-tier hierarchy and are deliberately kept ignorant of the big picture.
When Cursor's workers understood the broader project context, they experienced scope creep. They decided adjacent tasks needed doing, or reinterpreted assignments based on their understanding of the goals, and every decision potentially conflicted with other workers. Resolving conflicts required lots of coordination, serial dependencies, and decreased agent productivity overall. A worker that only knows to implement one specific function cannot decide to refactor the whole code module. The narrow scope you give that worker eliminates the coordination needs and enables parallel execution.
Yegge came to the same conclusion. His worker agents receive a task, execute it, and terminate. No knowledge of others.
The rule when you start to scale to 100 agents or above: think in terms of minimum viable context. Workers receive exactly enough to complete their assigned task and no more. Enforce this. Force it through information hiding. Do not give workers a chance to get context that could confuse them.
Rule 3: No shared state
Nate B Jones: Rule number three, also counterintuitive: no shared state. The consensus says that parallel agents should share state to stay coordinated. The Google/MIT study found the opposite. In tool-heavy environments with more than 10 tools, you saw a drop in multi-agent efficiency. Tools are shared state in multi-agent environments. If multiple agents are accessing the same resources, you have contention. And contention takes coordination. It's like fighting over the toolbox in a carpenter's shop.
The same dynamic applies to context. The assumption that more tools mean more capability drives the entire MCP ecosystem, where developers are connecting dozens of integration servers. But tool selection accuracy degrades as count increases, regardless of context window size. Think about it like this: you're in the carpenter's shop and you go from having 10 tools to choose from to a thousand. What is your tool selection accuracy going to look like? It's not going to be as good. Research shows degradation curves appearing past 30 to 50 tools even with unlimited context. The problem is not context-driven — it's not about fitting the tools in the window. It's that selection accuracy drops when agents face too many choices. This is a serial dependency inside the tool catalog.
Workers should operate in isolation. They should have no shared state. They should have tool sets that are small — three to five core tools that are always available, and others that are discoverable on demand through progressive disclosure. Coordination happens through entirely external mechanisms that are designed for concurrent access: Git for code, or task queues for non-technical assignments.
This does create a downstream problem. Isolated workers that push changes will need to merge their code. Both Cursor and Gas Town discovered you need dedicated infrastructure to do this. Yegge's Gas Town framework has what it calls the Refinery — an agent responsible for merging changes. The Refinery exists because workers do not coordinate. Regardless of how you handle it, the principle is clear: the complexity of merging should not belong to the worker, and should go to a dedicated system that handles it as a queue.
Rule 4: Plan for endings
Nate B Jones: Rule four: plan for endings. The consensus says we should seek to increase the length of time that agents can operate continuously, because you can accumulate context and sustain intent over time. We measure the performance of intelligence by how long we can run our agents. But context accumulation creates a serial dependency with the agent's own past. As histories grow, context fills with information that might not be relevant.
This is part of why the viral RALPH framework for Claude Code is such a big deal — because the original implementation of RALPH wiped the context of the past conversation with Claude Code and gave Claude Code a fresh chance to attack the task. In other words, it eliminated the serial dependency on the agent's history. It enabled the agent to forget productively, because otherwise the agent doesn't forget — it just stops prioritizing correctly because signal dilutes into noise. Researchers call this context pollution. It causes drift, progressive degradation of behavior, and degradation of decision quality. It affects a surprisingly large fraction of long-running agents.
The problem is not just that context windows fill up. It's often that the agent's attention gets diluted across the history. So even if it fits, you can get the lost-in-the-middle phenomenon, where models lose track of information buried somewhere in the middle of long contexts. An agent that has been running for hours has probably accumulated so much context that it will struggle to prioritize what matters now, even if what matters now is simple.
Cursor found drift unavoidable during continuous operation. Quality degraded within hours regardless of the context window. Specifications would mutate as agents misremembered or misinterpreted earlier choices, and the system would start to experience entropy — losing coherence.
Yegge built this directly into Gas Town with GUMP — the Gas Town Universal Propulsion Principle. The guy must have a writer's DNA; it's just so fun to read him. It exists because, in his words, the biggest problem with Claude Code is that it ends. The context window fills up, it runs out of steam, and it stops. Rather than fighting this, Gas Town treats endings as a design parameter. Sessions are ephemeral. Workers are expressed almost like molecules — they're chains of tasks stored externally. When an agent ends, the next session picks up reading the same molecular state that the worker wrote to. If the workflow is captured as a single organic molecule state, it survives agent crashes, compactions, restarts, and interruptions.
You could think of this as a tiny external scaffold of memory for a particular workflow that a tiny, short-lived agent is writing to. It may never see the end of the task. It just knows it's supposed to do this particular job. If it crashes, if it compacts, if anything happens, it wrote what it did down. And that is what Yegge calls non-deterministic idempotence — a really big phrase, but it means the path is unpredictable, but the outcome is guaranteed, because workflow state lives outside any given agent's context.
That is powerful because the agent can crash and restart and make mistakes and correct them, and it does not matter, because the workflow state tracks progress and insists on starting the next session at the correct point. That is one of the big things that allows Yegge to productively run dozens of agents — because he's not individually assigning them tasks. He's using the workflow as an external trigger to instantiate an agent at the right point.
The rule looks like episodic operation: every cycle runs for a period of time, captures results to external storage, and then you wash it out and kill it. The next cycle starts fresh with clean context. The question is not whether agents will stop working at that point. It's whether your architecture will design for endings and design workflow to persist regardless.
Rule 5: Prompts over infrastructure
Nate B Jones: Rule number five — this is very interesting. The consensus says that coordination infrastructure is where a lot of the hard engineering happens in multi-agent systems: how do you handle states, how do you handle errors? But Cursor found that a surprising amount of behavior comes down to how you prompt your agents. Infrastructure does matter — you have to have it. But prompts matter more when it comes to an analysis of failure cases.
Sophisticated coordination infrastructure often adds serial dependencies rather than removing them. For example: a message queue that serializes access to shared tools, or state synchronization that requires agents to agree on what exists before proceeding. Good prompts and good isolation of agents reduces a lot of the coordination infrastructure you need to build. The whole system gets simpler because the agents are isolated. An agent that clearly understands its role in an isolated way is simpler to prompt. It has clear boundaries. It has clear success criteria. It doesn't need to check with other agents. This is a simpler prompt to write. You're more likely to write it correctly. So the agent can just go and execute.
Research supports this: 79% of multi-agent failures originate from specification and coordination issues, not technical bugs. Infrastructure problems account for only 16%. Systems fail because designs created serial dependencies, or specs were ambiguous enough that agents did the wrong thing while functioning correctly. The rule is to treat your prompts like API contracts, and make sure they're in settings simple enough that a clear spec can allow an agent to perform well.
The apparent contradiction: Gas Town is complex — and why that's fine
Nate B Jones: There's an apparent contradiction here. I keep saying simplicity scales, but Yegge's Gas Town that I'm describing is actually complex. It has seven different worker types. It has complicated terms like Patrols and Convoys. It sounds like a science fiction novel. The resolution is this: complexity can live in agents or in the orchestration layer that keeps simple agents running, and these have very different scaling properties.
Complexity in agents works at small scale but creates serial dependencies that break at larger scales. An agent that gets entangled with other agents works when you have three to five in the system. But what Yegge found out is that you cannot do that if you get into dozens of agents, let alone the hundreds that Cursor was working on.
Complexity in orchestration enables parallelism. Gas Town has a separate role for an agent that just notices when worker agents get stuck — because worker agents are that simple. It has separate agents that just focus on merging conflicts. The orchestration complexity exists because the agents are simple, and simple agents do need external systems to keep them running, feed them work, merge their outputs, and track progress.
This is the inverse of where a lot of teams are putting complexity in multi-agent systems, and it's the heart of why so many multi-agent systems fail. The intuition is that if you make agents smarter, more capable, and more autonomous — pushing intelligence down to the workers — you'll scale the ability of compute to convert to capability. But that just doesn't work. The architecture that scales keeps workers pretty dumb.
The implication for 2026 is that investment should go into orchestration, not into agent intelligence. Build systems that can feed, monitor, and merge the outputs of hundreds of simple workers. Do not build super-elaborate agents.
What winning in 2026 actually looks like
Nate B Jones: The implications here are that the teams that win this year will be the ones that can absorb the tremendous increase in compute we're on schedule for. Assume another 10x. Who can add agents and get proportional throughput gains instead of a coordination collapse?
You need to think in tiers — two tiers specifically. You need to think about isolating your workers, about having external orchestration so that complexity lives at the systems layer and not the agent layer. You need to think about how agents end. You need to think about how you can have a system simple enough that your prompts can drive agent performance, without spending a tremendous amount on agent coordination engineering. And you need small tool sets.
It is possible to get to hundreds of agents. It is possible to get to hundreds of thousands of lines of code written autonomously. I've seen it over and over again. But the teams that succeed understand that the job is not to give the agent too much scope. The job is not to make one brilliant Jason Bourne agent running around for a week. It's actually 10,000 dumb agents that are really well coordinated in the system, running around for an hour at a time, progressively getting work done against a very tight definition of the goal they're accomplishing.
That is the transition we are living through. That is what multi-agent systems are going to look like in 2026. And the teams who understand this are going to outproduce the teams that don't by a factor of 100. That is not an exaggeration. That is why the stakes are so high.