The seven ways are seven ways distributed systems have always broken, except for the one twist that turns the oldest fix into part of the disease.
Here's a scene that played out a few hundred times in 2026, probably including at your company.
A team builds an AI agent pipeline, a planner hands to a researcher, who hands to a writer, who hands to a reviewer. It works in the demo and flakes in production: every so often it confidently does the wrong thing. So the team reaches for the obvious fix, the one every instinct screams: add another agent to check the work. A second reviewer. Then a third to break ties when the first two disagree. They've built a little committee, a quorum, a vote, and the system gets worse. More confident, more expensive, and less reliable.
That failure is worth understanding in detail, because it's not a bug in their prompt. It's a fifty-year-old result in computer science wearing a brand-new costume, and the fact that a sharp team walked straight into it tells you something important: the field is speed-running half a century of distributed-systems pain without the textbook. Here's the textbook, and the one chapter that hasn't been written yet, which is exactly the chapter that bit them.
Practitioners have converged on a rough catalog of how agent teams break, call it seven modes: cascade hallucination (one agent's mistake gets treated as fact by the next, and the error compounds downstream), state loss (context falls out of the conversation between handoffs), contradictory outputs (parallel agents produce irreconcilable answers), scope creep (an agent quietly does more than it was asked), infinite loops and deadlocks (agents wait on each other forever, or repeat a step endlessly), tool-output confabulation (an agent reports a tool result it never actually got), and memory poisoning (one bad entry in shared memory infects every agent that later reads it).
Now read that list again as a distributed-systems engineer, and every single one snaps into a name you already know.
Cascade hallucination is Byzantine fault propagation. In 1982, Leslie Lamport and colleagues described the Byzantine Generals Problem: a node that is confidently wrong and tells different stories to different peers, corrupting the group's decision. An LLM that hallucinates is structurally identical, a participant that emits authoritative, mutually-inconsistent claims, and the 1982 framing fits 2026 without editing a word. State loss is the consistency problem: no shared, durable state across handoffs. Contradictory outputs are split-brain, the classic failure where partitioned nodes diverge with no reconciliation protocol. Infinite loops and deadlocks are livelock and deadlock; the "deadlock detector" people are reinventing is literally cycle-detection in a wait-for graph, a 1970s technique. Tool confabulation is an unverified RPC return, a component reporting success it didn't earn. Memory poisoning is cache poisoning / data-integrity corruption, one bad write, every reader infected.
And the fix teams keep "discovering"? The most popular reliability pattern in agent frameworks is the circuit breaker, wrap a flaky dependency, trip open after repeated failures, stop hammering it. That's not new either. That's the Netflix/Hystrix pattern from 2011. As one engineer put it bluntly, the agent community is "rediscovering hard-won lessons from distributed systems, often without the vocabulary or theoretical foundations that would accelerate progress." The good news, if you build these systems, is enormous: you are not in uncharted territory. There are decades of theory, consensus protocols, idempotency, append-only logs, quorums, Byzantine fault tolerance, sitting right there, most of it solved. You should read it before you reinvent it.
But there's a catch, and it's the reason that committee of reviewers made things worse instead of better.
Classical fault tolerance rests on one load-bearing assumption: failures are independent. A crashed server is statistically unrelated to its neighbors, so you can outvote f faulty nodes with 3f+1 honest ones. Redundancy plus voting is the foundational move of the entire field, more nodes, more safety. It works because the nodes fail in different ways at different times, and a majority is therefore likely to be right.
That assumption is false for LLM agents, and falsifying it quietly detonates the whole edifice.
When every agent in your committee runs on the same base model, they share the same training, blind spots, and priors, and therefore the same failure modes. They don't fail independently; they fail correlated. They hallucinate the same wrong fact at the same time, for one reason. So when you add reviewers and take a vote, you are not sampling independent opinions that average toward truth, you're polling five copies of one mind. "Five agents agree" can mean "five instances of the identical mistake, now wearing the badge of consensus." As the distributed-systems-for-agents literature states it directly: shared base models make failure modes correlated, which breaks classical fault-tolerance guarantees, and so design diversity becomes essential.
This isn't just theory; the scaling curve bends the wrong way in measurement. On consensus tasks, LLM agents reach valid agreement unreliably even in benign conditions, and it degrades as the group grows, one study reports valid consensus dropping from 46.6% with four agents to 33.3% with sixteen. Read that twice: doubling and redoubling the team made agreement less trustworthy. The instinct that saved distributed systems, throw redundant nodes at it, is, on a shared model, an instinct toward the disease. You're not building a quorum. You're building an echo chamber with a voting ritual.
If redundancy is the wrong lever, where's the right one? The most useful evidence comes from the most rigorous study of the question to date. UC Berkeley's Sky Computing Lab built MAST, the Multi-Agent System Failure Taxonomy, by hand-annotating failures across 200-plus tasks on seven popular multi-agent frameworks, with expert agreement measured at a serious Cohen's κ of 0.88, producing a public dataset of over 1,600 failure traces. They found fourteen distinct failure modes, and sorted them into three buckets: specification and system-design issues, inter-agent misalignment, and task-verification failures.
The headline finding is the one to tattoo on the wall: these are system-level failures not detectable at the individual-agent level. They are, in the paper's words, "properties of interaction rather than of individual components." Your agents can each pass every unit test you write, and your system can still fail, because the bug doesn't live in any agent. It lives in the seams between them: the handoff where context silently drops (MAST measured loss-of-conversation-history and step-repetition as some of the most common modes), the reviewer that doesn't know the task is already done, the role boundary that quietly erodes. You cannot find an interaction failure by testing components in isolation, any more than you can find a bad marriage by interviewing each spouse alone.
There's a brutal piece of arithmetic underneath all of it that explains why seams dominate. Reliability across a chain is multiplicative: the probability a workflow succeeds is the per-step success rate raised to the number of steps. At a per-step reliability of 95%, which sounds excellent, the kind of number that gets a feature shipped, a twenty-step agent workflow succeeds only about 36% of the time. Make every agent two points better, to 97%, and you're still at 54%. You cannot reach reliability by polishing individual agents, because the failure isn't concentrated in any agent; it accumulates in the chain. Reliability is a systems property. This is precisely why reported failure rates for complex multi-agent workflows run so high, figures across studies land anywhere from roughly 40% to the high 80s, and why the recurring conclusion is that the failures "arise from organizational design and coordination rather than individual agent limitations." The bug is in the seams.
So the playbook inverts. If failures are correlated and they live in the seams, then the two moves that feel productive, add more agents, make each agent smarter, are the two that don't help. What holds is boundary discipline and genuine diversity. Four things, concretely:
Provenance at every handoff. Treat each claim that crosses a seam as needing a source, not a vibe. Where did this fact come from, a tool you can re-run, a document you can cite, or a previous agent that might be confabulating? Cascade hallucination is only possible because the second agent trusts the first's output as ground truth; tag every handoff with its origin and you can refuse to build on an unverifiable claim instead of compounding it. This is the same instinct as not citing a confident source you can't trace, applied to your own pipeline's internal messages.
Bounded scope, enforced. Scope creep, the one mode without a tidy distributed-systems ancestor, is an authorization failure: an agent doing more than it was granted. The fix is the same as it's always been for privilege: give each agent the narrowest mandate that lets it do its job, and gate anything outside it rather than trusting it not to wander. An agent that can't exceed its scope can't creep.
An append-only audit trail. Memory poisoning and state loss are both integrity problems, and the database world solved integrity with the log: an append-only record you can replay, where a bad write is visible and reversible rather than silently overwriting the truth every later reader depends on. If you can't reconstruct who wrote what, when, and why across your agents, you can't find the poisoned entry, and you can't prove the system did what it claims.
And the one most teams skip: diversity, not redundancy. Because the failures are correlated, the antidote is decorrelation. A verifier that catches a model's mistakes has to be a genuinely different kind of thing, a different model, a different prompt strategy, a deterministic check, an adversarial reviewer whose job is to refute rather than agree, not another instance of the same model nodding along. This is the part that's intellectually honest to admit is hard, and worth admitting plainly: even a system built on disciplined boundaries, if it runs every role on one shared model, has to import its diversity deliberately. A same-model peer review is the redundancy trap with extra steps. A different-model adversary, or a hard check against ground truth, is the thing that actually breaks the correlation. The cheapest reliability upgrade available to most agent teams isn't a smarter agent or a bigger committee, it's one differently-built skeptic wired to disagree.
If your multi-agent system is unreliable, here is the practical sequence, in order, and notice that the first instinct doesn't appear on it.
First, resist adding agents. On a shared model, more voters is more echo, and the consensus data says agreement gets worse as the group grows. Second, do the compound math before you do anything else, count your steps, raise your per-step reliability to that power, and let the result tell you honestly whether you have an agent problem or an architecture problem (at twenty steps, it's almost always architecture). Third, police the seams: provenance on every handoff, bounded scope per agent, an append-only audit trail, because that's where the failures actually live. Fourth, buy a skeptic, not a clone: one decorrelated, adversarial, differently-built verifier beats N copies of the same mind.
And the deepest move, the one that compounds: go read the distributed-systems literature you already have. Cascade hallucination, split-brain, livelock, cache poisoning, the circuit breaker, these have names, proofs, and battle-tested fixes going back to the 1970s and '80s. The agent field is re-deriving them the expensive way, in production, one outage at a time. You don't have to. The only genuinely new problem in the whole catalog is the correlated-failure twist, and even that has a one-word answer the old field already knew to reach for when independence breaks down: diversity. Everything else is a rerun, and the reruns come with a textbook. Read it before you reinvent it.
More agents won't fix it. The seams need a trust stack.
The failures live in the seams between agents, and they're correlated, so a bigger committee is an echo chamber with a voting ritual. What holds the seams is architecture: provenance on every handoff, an append-only audit trail, bounded scope, and one decorrelated verifier. The agent-trust-stack packages those pieces, so you wire provenance, verification, and audit into the handoffs instead of hoping a smarter agent saves you.
pip install agent-trust-stack · npm install agent-trust-stack
vibeagentmaking.com →