More Agents Are Not a Reliability Mechanism

In 1986, computer scientists John Knight and Nancy Leveson recruited 27 programmers at two universities and gave them the same assignment. Each would independently write a program from one specification. The program belonged to an anti-missile system, exactly the kind of safety-critical software where a single failure is unacceptable. The premise was reassuring. Build several versions separately, let them vote on the answer, and their mistakes should cancel out because independent programmers should not fail on the same input at the same time.

The individual programs performed extremely well. Six of the 27 never failed across a million tests, and 23 succeeded on more than 99.9 percent of the cases.

The trouble appeared when the researchers looked at where the programs failed. Two versions produced the wrong result on the same input 551 times, and on two test cases eight versions failed together. Those overlaps occurred far more often than statistical independence predicted. The programmers had never spoken to one another, but they had all read the same specification, and its ambiguities gave them common ways to go wrong.

Their shared specification had correlated work that was supposed to be independent.

Two things we both call "multi-agent"

When people say a system uses "multiple agents," they can mean one of two very different architectures. In the first, several agents independently produce their own answer to the same question, and then a vote or a separate checker picks the winner. There is no cross-talk between them while they work. Their errors can stay independent, and the vote or the verifier is what actually removes the bad ones.

In the second architecture, the agents form a chain. A planner breaks up the task, a drafter produces an answer, a reviewer checks it, and an executor acts. Each stage receives the previous stage's output as its starting point. The roles look separate, but the evidence path is shared.

The first architecture can suppress errors when its vote or verifier rejects the bad outputs. In the chain, one stage's mistake can become the next stage's assumption before anyone checks it against separate evidence. Both systems are called multi-agent, even though adding agents changes their error dynamics in opposite directions.

What changed since 1986

Knight and Leveson's programmers shared one fixed specification. That common starting point was enough to correlate their failures, even though each programmer read it and then worked alone.

A language-model chain shares something more active: generated context. One agent's output becomes the premise for the next. If the planner invents a constraint, the drafter can inherit it as settled and pass it downstream with more detail. By the time a reviewer encounters the claim, it may carry several stages of apparent agreement without ever having been checked against separate evidence.

Every added stage extends the path that an early mistake can travel. Catching it requires a check with its own evidence, criteria, and power to stop the chain.

Four things that look like safeguards and aren't

• Coordination: Messages can move perfectly between agents while the task still falls apart. Coordination requires a current picture of who owns what, which evidence is valid, what remains blocked, and what counts as finished.
• Independent verification: Calling an agent a critic does not give it an independent view. A reviewer using the same model, context, and evidence may inherit the producer's blind spots along with its draft. Independence comes from a separate evidence path and a verdict the producer cannot override.
• Authorization: Consensus answers whether the agents agree. Authorization answers whether a principal permitted the action, within what scope, and with what way to revoke it.
• Accountable records: A transcript preserves conversation. An accountable record also preserves the approved artifact, the evidence and verdict behind it, who had authority, what action occurred, and what changed afterward.

What the measurements actually show

Multi-agent systems can help, but the result depends heavily on the shape of the task. Recent measurements span an unusually wide range.

One recent study found that adding agents ranged from an 80 percent improvement on work that decomposed cleanly to a 70 percent decline on sequential planning. The architecture helped when work could be divided, then hurt when later steps depended on earlier state.

The extra agents also carry a cost. Another study found that a single agent role-playing the same workflow matched multi-agent performance on seven benchmarks while reusing its own context, avoiding much of the repeated inference work.

A third study produced the stranger pair of numbers. Its normalized hallucination measure fell from the first agent to the last, while factual accuracy also slipped. One possible reading is that the chain produced claims that were smoother or harder to flag as inconsistent without becoming more accurate. The divergence does not prove that mechanism, but it shows why a cleaner average score cannot rule out inherited errors.

The full source map, including the papers behind these distinctions and the limits of the comparisons, is in our research briefing, From Coordination to Authority: Evidence Boundaries in Multi-Agent AI Reliability.

The one question

When someone says a system is more reliable because several agents check one another's work, ask two questions: do the agents share context, and what can stop an error before it reaches the next stage?

If each stage inherits the previous stage's output and nothing checks it against separate evidence, the later agents are not independent reviewers. They are downstream readers of the same mistake.