Summary: A recent systematic study of multi-agent AI failures (the MAST taxonomy) found that coordination failures account for roughly 37% of all multi-agent system breakdowns, more than verification gaps and infrastructure issues combined. This piece traces that failure pattern back to a 1982 distributed-systems proof, the Byzantine Generals Problem, and sets out four design principles for multi-agent AI architectures built on a different assumption: that some agents, some of the time, will be confidently wrong.

In brief: Most multi-agent AI systems are architected as if agents can only fail by going slow or silent. In production, the failure that actually happens is different and more dangerous: an agent reports a wrong answer with total confidence, formatted as cleanly as a right one. Lamport, Shostak, and Pease named this exact failure mode in 1982, a "Byzantine fault," and proved that tolerating it requires a specific architecture, not just better individual components. The translation to agentic AI is direct: hallucination is a Byzantine fault, not a bug to be prompted away.

In This Article:

• A real multi-agent build, and the day it broke
• Why this is a trust problem, not a quality problem
• The 1982 proof, and its direct translation to AI agents
• What changes when you take it seriously
• A confession that proves the point

A real multi-agent build, and the day it broke

In one of my enterprise builds, business users ask questions in plain English, and a team of agents turns the question into a governed answer. The cast looks like this:

• An intent router that decides what the user actually wants
• A SQL generation agent
• A knowledge agent that pulls from documentation
• A validation agent
• An execution agent that runs against the data
• A summarisation agent that writes the final answer

On the architecture diagram, it looks clean. In production, the interesting day arrives fast. Two agents produce conflicting SQL for the same question. The knowledge agent quotes documentation that contradicts what the transactional data actually says. One backend is stale while another is current. Every agent reports a confidence score, and every one of them sounds equally sure.

The orchestrator sits in the middle holding one question: which agent do I trust?

Why this is a trust problem, not a quality problem

I used to treat this as a quality problem. Better prompts, better models, and it would go away. It did not go away, because it is not a quality problem. It is a trust problem, and it was named in 1982, decades before anyone was building AI agents at all.

Leslie Lamport, Robert Shostak, and Marshall Pease wrote a paper framed as a war story. Generals surround a city and must agree on one battle plan, communicated only by messenger. Some generals are traitors who send different lies to different colleagues. The famous result: agreement must survive participants that send arbitrary, even contradictory, information, and tolerating f liars costs 3f+1 members.

The AI translation is direct. Hallucination is a Byzantine fault. Not a crash. Not a timeout. A component that confidently reports wrong things. And here is the uncomfortable part: most multi-agent architectures are built as if agents can fail only by being slow or silent, never by being wrong. The first confident falsehood is addressed directly and summarised for the business user.

This isn't just a 1982-to-2026 analogy holding up under pressure; it's now an active research field in its own right. A systematic taxonomy of multi-agent system failures, built from real production traces across mathematical reasoning and safety-assessment tasks, found that coordination failures alone account for roughly 37% of all multi-agent breakdowns, ahead of verification gaps at 21% and infrastructure issues at around 16%. That's not a rounding error. That's the dominant failure mode, and it's exactly the shape of failure the Byzantine Generals proof describes.

There's a sharper wrinkle worth naming too. Classical Byzantine Fault Tolerance assumes faults are independent, that one traitor's lie has nothing to do with another traitor's lie. Multi-agent AI systems routinely violate that assumption: when several agents share the same base model or similar training data, their failure modes become correlated. They don't fail independently. They fail together, in the same direction, for the same underlying reason, which is precisely the condition classical fault tolerance guarantees were never built to survive.

What changed in my design once I took the law seriously

Trust is earned per claim, not per agent. No agent carries a standing credential. A claim that matters gets checked no matter who produced it, even the validation agent.

Corroborate, don't interrogate. If the execution result matters, verify it against the source. Run the count, don't ask an agent whether the count is right.

Declare who wins before the fight. Conflict rules are decided upfront, not at runtime. Transactional data beats documentation for current state. Documentation beats model memory for definitions.

Evidence over testimony. Row counts, query plans, logs, and artefacts outrank any agent's confident prose, no matter how well-formatted it is.

A confession that proves the point

A small confession that proves the point better than any argument could. While preparing this article, the image tool that generated the cover slide invented a citation key that does not exist, and spelled Lamport with two Ps. A confident, wrong, beautifully formatted report. It got caught because the citation store from article #1 in this series does not accept unverified records. The laws keep policing each other.

That is the real lesson of 1982 for agentic AI. You do not get trustworthy systems by making every agent trustworthy. You get them by designing for the guarantee that some of them, some of the time, will be confidently wrong, and building the architecture that survives that, not one that assumes it away.

If your organisation is building multi-agent AI systems and the trust architecture hasn't caught up with the orchestration layer, talk to Tarento's Generative & Agentic AI team.