Spin up three agents on the same codebase, split the work three ways, and let them run in parallel. Ask agent one what the billing module depends on. Ask agent two the same question twenty minutes later. There is a real chance the two answers do not match, not because either agent is careless, but because neither read the same thing on its way there. One followed an import chain three files deep and stopped. The other grepped for a function name, found a call site that looked current but was not, and built its answer on that. Both report back with full confidence. Neither is lying. They are describing two different systems that happen to share a name.
This site has already covered the decision of whether to run more than one agent at all and the mechanics of how agents hand work to each other. Both pieces are about orchestration: who does what, in what order, how results get merged. This piece is about a failure that shows up even when the orchestration is right. You can route tasks correctly, delegate cleanly, and merge outputs on schedule, and still end up with agents that disagree, because agreement was never the orchestrator's job. Its job is moving work and messages between agents. Whether two agents who never compared notes are picturing the same underlying system is a separate question, and most multi-agent systems never actually answer it.
That is the failure mode here. Not bad scheduling, not a broken handoff, but agents, or parallel instances of the same agent working different pieces of one task, each building its own partial, independently derived understanding of the thing they are all supposedly working on, and those understandings quietly not matching.
Origin: why every agent starts from zero
Start with the fact underneath all of this. A model call carries no memory of any other model call. What looks like an agent's understanding of a codebase, a process, or a dataset is not a fact it looked up. It is an inference, rebuilt fresh from whatever the agent happened to read on its way through the task. The piece on agent memory covers this for a single agent working across sessions: the model itself is stateless, and anything that persists has to be engineered on top of it. Run several agents at once and the same gap opens sideways instead of across time. Each fills its own blank context window from the same source material, on its own path through it, and nothing guarantees the fills converge.
Consider what "understanding the codebase" means for an agent doing it the first time. It is not a lookup. It is a sequence of choices: which file to open first, which grep to run, how many hops to follow before deciding it has seen enough. Two agents on different subtasks make different choices for good reasons; two instances of the same agent, given the identical subtask, will still often diverge, because the exploration has enough branching points that small early differences compound. Both are running a bounded search and reporting what the search turned up, and what turned up is not automatically what is true. Nothing in a typical setup checks the two against each other, or against the actual system, before either acts on its version.
Cognition made this concrete with an example worth revisiting from a different angle than its usual reading. In Don't Build Multi-Agents, the company behind the coding agent Devin described asking a multi-agent system to build a Flappy Bird clone. One sub-agent built the background and pipes, another built the bird, and they ran in parallel without ever seeing each other's output. The first, with nothing telling it otherwise, rendered a background in a Super Mario art style. The second built a bird that did not match. The usual reading is about implicit decisions colliding, and that reading is correct. But look at what happened underneath the collision: neither agent was told what art style to use, so each invented an answer, and the two invented answers were both reasonable and both different. That is not a scheduling bug. It is the default outcome whenever a question has no shared answer on record and more than one agent has to supply its own.
Present: agreement was never the orchestrator's job
It is tempting to read the Flappy Bird story as an argument for tighter delegation or a smarter orchestrator, and a lot of multi-agent engineering effort goes exactly there. That is the wrong place to look. An orchestrator, however well designed, controls the flow of tasks and messages: which agent gets which subtask, when a result is ready, how outputs get merged. None of that touches what an agent believes about the system before it produces a result. Build the cleanest orchestrator-workers setup in the pattern catalogue, with scoped context windows and tight summaries flowing back exactly as Anthropic describes for its own multi-agent research system, and the workers can still hold incompatible pictures of the underlying system, because scoping a context window controls how much an agent reads, not whether what it read adds up to the same conclusion another agent reached from a different slice.
A 2026 paper on multi-agent architecture, Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems, makes this split explicit, treating the rules that govern how agents hand off tasks and synchronize as separate from the shared state and knowledge those agents actually draw on. Coordination logic and shared knowledge are not two names for the same fix. You can rebuild the first without touching the second, which is where a lot of engineering effort goes, because it is visible in a trace and satisfying to debug. Shared knowledge, or the lack of it, stays invisible until two agents act on different versions of it and someone has to work out why.
There is a sharper version of this in Talk is Cheap, Communication is Hard, a study of paired LLM agents negotiating over shared resources. The agents were individually capable: each one, working alone, could identify the outcome that made the best use of the resources on the table. Paired up and asked to reach that outcome together, they routinely failed to, not from a lack of reasoning but from what the paper calls a grounding failure. The pairs lost track of what had already been proposed, anchored on whatever position they stated first even after new information should have moved them, and misread which part of the exchange the other agent meant. Nothing was wrong with either agent's individual reasoning. What broke was the part in between: two parties actually landing on the same understanding of where things stood. Same failure as the Flappy Bird story, caught mid-negotiation instead of mid-build.
The math that makes more agents worse
The obvious instinct once you notice this failure is to add more agents to catch it: a checker, a second opinion, a verifier that cross-reads what the others produced. This instinct has the arithmetic backwards.
Every pair of agents is a place where two independently derived understandings can fail to match. With two agents there is one such pair. Add a third and there are three. A fourth brings six, a fifth brings ten. The count follows n(n-1)/2, the formula Fred Brooks used in 1975 to explain why adding programmers to a late software project tends to make it later, not sooner: communication overhead grows with the square of team size while the work itself grows only linearly. Ten agents on a shared task have forty-five pairwise relationships where one agent's private model can quietly contradict another's, unless something outside those relationships holds a version every agent has to agree with.
This is the concrete version of the intuition behind "more agents means more coverage." It is true only if every agent's read of the shared facts is also correct and identical, which is exactly the assumption this piece has been arguing does not hold by default. Once it does not, more agents does not mean more independent checks converging on the truth. It means more independent guesses at the same ground truth, growing quadratically while the amount of actual, verified shared truth stays flat unless someone deliberately builds it. The MAST failure taxonomy, built from more than 150 execution traces across five open-source frameworks and hosted with its full dataset at UC Berkeley, put inter-agent misalignment behind more than a third of all observed failures, a share with no natural reason to shrink as systems add agents. There is no force pulling independently formed models back into alignment. Left alone, they drift.
It gets worse before it gets better if the response is simply more cross-talk. One analysis of unstructured "bag of agents" deployments, where every agent messages every other with no shared structure underneath, put the resulting error rate at roughly 17 times higher than a comparable single-agent baseline, driven largely by agents validating each other's mistakes in circular exchanges rather than catching them. Talking more, without anything grounding the conversation, does not average out errors. It can launder them, because a wrong claim repeated back by a second agent starts to sound like confirmation instead of an echo.
A more direct line of research asks the consensus question head on. Can AI Agents Agree?, a 2026 study, sets up agents that in principle have access to the same information and measures how often they actually converge on the same answer, drawing on the decades-old distributed systems literature on reaching reliable agreement across independent parties, the line of work that runs back through Byzantine fault tolerance. This is not a new problem invented by language models. Getting several independent participants, human, machine, or otherwise, to hold the same true belief about a shared state has been a hard, formally studied problem in distributed computing for over four decades. Nothing about wrapping a language model around each participant makes it easier. If anything, it adds a participant that will confidently assert a wrong belief rather than admit it does not know one.
Why negotiation logic doesn't fix a grounding problem
Given all that, the natural next move is better negotiation between agents: a debate round, a voting mechanism, an evaluator that checks the others' work before anything ships. The piece on multi-agent debate on this site covers when that pattern earns its cost. The mistake is reaching for it here.
Debate and voting are tools for reconciling judgment. They work when the disagreement is genuinely a difference of interpretation, weighting, or taste, the kind of question where several reasonable agents could land in different places and a structured exchange surfaces the strongest case: whether a refactor is worth the risk it introduces, or which of two valid approaches reads more clearly. Those are exactly what the evaluator-optimizer pattern and multi-agent debate are built for.
They do not work when the disagreement is about a fact with one correct answer. If agent A believes the payments module calls the fraud-check service and agent B believes it does not, that is not a difference of opinion to vote on. One of them read the code wrong, stopped early, or looked at a stale version, possibly both in different ways. Put those two agents in a debate loop and you are not adjudicating a judgment call, you are asking two ungrounded guesses to argue each other into a corner, and the grounding failures covered above show what that tends to produce: anchoring on whichever claim was stated first and most confidently, not convergence on what is true. More rounds of talk add tokens and latency without adding information, because neither party has access to the one thing that would settle it, the actual system.
The field's own attempts to fix multi-agent miscommunication point the same direction, away from richer negotiation and toward shared structure. MetaGPT, an early and widely cited framework for multi-agent software generation, was built specifically to cut down the logic inconsistencies that come from letting agents chain freeform messages to each other. Its fix was not a better dialogue protocol. It replaced peer-to-peer chat with a shared, structured message pool that every agent publishes to and reads from, plus standardized procedures that pin down how a task gets decomposed in the first place, so agents work from the same recorded state rather than each other's summaries of it. When a system's own designers hit this exact failure, the working answer was less conversation and more shared record.
What a shared source of truth actually requires
If the fix is a shared record rather than better negotiation, it is worth being precise about what that record needs, because a pile of shared documents is not automatically a fix. Text still has to be interpreted, and two agents reading the same paragraph can walk away with different conclusions about what it implies, for the same reason two agents reading the same codebase can. A single source of truth, in the sense that actually closes this gap, needs a few specific properties.
It has to return the same answer regardless of who is asking. Not a similar answer, not a paraphrase: the same fact, whether the query comes from agent one at nine in the morning or agent five twenty minutes later on a different subtask. That rules out anything where the answer is itself an inference the querying agent performs on retrieved text, because that just reintroduces the independent-interpretation problem one layer down. A structural answer to "does X call Y" needs to come back as a structural fact, not a passage the agent reads and judges for itself.
It has to be structural, not merely centralized. A shared wiki every agent can read is centralized, but if what is stored there is prose, two agents can still extract different claims from the same paragraph, especially once it is months out of date and describes a decision the code no longer reflects. What closes the gap is closer to a graph: entities and the relationships between them, resolved once, so querying it is retrieval rather than interpretation. This is the same shift covered in the piece on GraphRAG, where a graph beats plain text retrieval on relationship questions because the relationships are already resolved in the structure, not left for a model to infer fresh each time.
It has to stay current, or it recreates the problem it was meant to solve, just delayed. The piece on agent memory covers staleness for a single agent's memory drifting out of date over a project's life. The multi-agent version is a spatial variant of the same bug: if the source updates on a lag, or some agents read a cached copy while others hit the live version, the system has re-introduced two versions of the truth, just with extra steps.
And it has to be cheap enough to query that agents actually use it instead of guessing. An agent under a token budget and a deadline routes around a slow, expensive source of truth the way a developer routes around a build system that takes twenty minutes to run, not because the source is wrong to consult, but because the cost of consulting it exceeds the perceived cost of guessing. A source of truth too slow to check on every subtask does not get checked on every subtask, and an unconsulted one protects nobody.
Future and impact: where the fix actually has to live
None of this is an argument against multi-agent systems, and it is not an argument for smarter agents either. The agents in the Cognition example and the negotiation study were not confused or careless. They did exactly what a capable agent does when handed a task and no shared ground truth: it builds the best model it can from what it can reach, and reports that model with the same confidence it would report an actual fact, because from the inside the two are indistinguishable. That is the uncomfortable part. You cannot fix this by telling agents to be more careful, and you mostly cannot fix it by making them talk to each other more, because talking does not manufacture facts neither party has. The fix has to sit below the agents, as something all of them read rather than something each separately reconstructs.
That is a smaller ask than it sounds once separated from orchestration. It does not require agents to coordinate better in real time, which is the part multiple teams building these systems have found current models still do poorly. It requires removing the need for that coordination in the first place, on the specific factual questions that have one right answer, so whatever negotiation remains gets spent on genuine judgment calls rather than re-litigating facts that should never have been up for a vote.
For AI coding agents working against a real codebase, this is close to what Spiderbrain is built to be. Its core is a deterministic, source-free graph of a software project rather than a flat context window that resets every session, and because the graph is deterministic, every agent that queries it gets the identical structural answer rather than inferring its own version of the same fact. Parsing runs locally on the developer's machine, and only a source-free structural map, not the code itself, goes to Spiderbrain's EU-based servers for scoring, so a shared fact layer does not require centralizing the source code to get a centralized set of facts about it. It speaks MCP and works with ten or more MCP clients at once, including Claude, Claude Code, Cursor, Continue, Cody, and Zed, which is the direct multi-agent case: several agents or tools querying one graph as common ground instead of each rebuilding its own picture of the same repository. Roughly 350 automated checks run on every release to hold that determinism claim, because the guarantee is worth little the moment it quietly stops being true.
The broader point holds independent of any one tool. Add agents to a system with no shared ground truth and you have added more independent guesses about the same reality, and more pairs in which those guesses can collide, without adding anything that resolves the collision. Add a shared, deterministic context graph instead, something every agent reads rather than reconstructs, and most of what looked like a coordination problem turns out to have been a grounding problem wearing a coordination problem's clothes. Fix the ground truth, and whatever negotiation is left over turns out to be the kind actually worth having.
Council summary
This post argues that a large share of what gets diagnosed as a multi-agent coordination failure is actually a grounding failure one layer down: each agent independently reconstructs its own partial understanding of the same system from a blank context window, and nothing guarantees two independent reconstructions match, no matter how well the orchestration routing them is built. It grounds the claim in concrete evidence: Cognition's Flappy Bird example reread for what it shows about invented defaults, the MAST taxonomy's inter-agent misalignment share, and a 2026 study of paired agents failing to reach shared understanding despite being individually capable, then uses Brooks's Law to show why the problem compounds rather than eases as more agents join, since the number of pairwise places where two independent models can disagree grows with the square of agent count while actual shared truth stays flat unless someone deliberately builds it. The post is explicit that better negotiation, debate, and voting are the wrong layer to fix this at, because those tools resolve differences of judgment, not unresolved facts, and pairing ungrounded agents in a debate loop tends to produce confident anchoring rather than truth. The reader's takeaway is a design rule: give every agent one deterministic structure to query instead of a document to interpret, reserve negotiation for genuine judgment calls, and treat a rising agent count as a reason to invest in shared ground truth rather than a reason to add more talking.
Comments