A single agent fails in ways you can see. A multi-agent system fails in the spaces between the agents , and those failures are quiet, weird, and expensive.
Here’s the seductive pitch for multi-agent systems: instead of one giant agent trying to do everything, you build a team of specialists. One agent pulls the data, one assesses risk, one checks compliance, one makes the call. Each is simpler, easier to reason about, easier to test. Divide and conquer.
It’s a genuinely good idea, and it works , right up until the agents have to actually coordinate. Because the moment you have more than one agent, you’ve introduced a whole category of failure that doesn’t exist in a single-agent system: the failures that live between the agents. Not “this agent is wrong,” but “these two agents were each right and the system still did something insane.”
I want to walk through five of these coordination failures, because they’re the ones that quietly kill multi-agent projects in production, and they’re almost never what the architecture diagram prepares you for. I’ll use one running example to make them concrete: an SMB lending system , an multi-agent AI system that evaluates small-business loan applications, because money, compliance, and real consequences make the failure modes impossible to hand-wave.
Picture the setup. Five agents:
- Intake , reads the application, extracts fields.
- Data , pulls credit bureau, bank transactions, business records.
- Risk , scores creditworthiness from the data.
- Compliance , checks fair-lending rules, sanctions, policy limits.
- Decision , an orchestrator that weighs it all and approves, declines, or escalates.
On the happy path, it’s beautiful. Now let’s break it, five ways.
Failure 1: The Telephone Game (Context Degradation)
In a single agent, all the context lives in one place. In a multi-agent system, context gets passed , and every handoff is a chance to lose or distort something.
In our lending system, Intake extracts “requested amount: $50,000” and passes a summary to Risk. But somewhere in the summarization , because agents often pass natural-language summaries, not structured data , “$50,000 requested, $200,000 annual revenue” becomes “strong revenue relative to request.” Risk scores on that framing. Compliance never sees the raw numbers, only Risk’s conclusion. By the time Decision acts, the actual figures have been three times abstracted into a vibe.
Each agent did its job correctly on the input it received. The failure is that the input degraded at each hop, like the children’s game of telephone. The output is confident and wrong, and worse, no single agent’s logs show the error , because no single agent made one.
The fix is discipline about what travels between agents. Pass structured, verifiable data (the actual numbers, with provenance), not prose summaries, for anything decision-critical. Let agents summarize for readability, but make the orchestrator able to see ground truth. The rule: a downstream agent should never have to trust an upstream agent’s interpretation when it could have the fact.
Failure 2: The Overlapping Mandate (Who Owns This Decision?)
This is the subtle one, and it’s a design failure disguised as a runtime bug.
Both Risk and Compliance, reasonably, have opinions about whether to decline a loan. Risk declines for creditworthiness; Compliance declines for policy. Fine , until a borderline case comes in where Risk says “approve, decent score” and Compliance says “decline, exceeds exposure limit for this sector.”
Who wins? If you never explicitly decided, the answer depends on accidental details , which agent the orchestrator happens to query last, how their outputs get merged, whether a later agent’s text overrides an earlier one. The system produces an answer, but not a principled one, and the same application could get a different result depending on ordering. In lending, that’s not just a bug , it’s a fair-lending problem, because inconsistent decisions on similar applicants is exactly what regulators look for.
The failure isn’t in either agent. It’s that two agents had overlapping authority over the same decision and nobody defined the precedence. This is the multi-agent version of an org chart where two people both think they own a call , and it fails the same way: in the ambiguity.
The fix is explicit decision rights. For every decision the system makes, exactly one agent (or one rule) must own the final say, and the precedence between agents must be defined, not emergent. Compliance overrides Risk, always, by design , written down, not left to query order. If you can’t say which agent wins a conflict, you don’t have an architecture yet; you have a race condition with opinions. (The same clarity you’d want when choosing types of AI agents for each role , a deliberative compliance agent and a fast reactive intake agent aren’t interchangeable, and their authority shouldn’t be either.)
Failure 3: The Cascade (One Wrong Agent Poisons the Chain)
In a pipeline, agents trust their inputs. That trust is the vulnerability.
Suppose the Data agent has a bad day , the bank-transaction API times out, and instead of failing loudly, it returns partial data (three months instead of twelve) without flagging it. Risk scores on three months, sees no red flags (because the problem months aren’t in the window), and passes a clean score downstream. Compliance sees a clean score. Decision approves.
One silent degradation at the start cascaded through every downstream agent, each of which behaved perfectly on the corrupted input it was handed. The error didn’t get caught because each agent trusted the one before it, and the bad data looked plausible all the way down.
This is the single most dangerous multi-agent failure, because it’s invisible. Nothing errored. Everything “worked.” The loan just shouldn’t have been approved.
The fix is that agents must distrust their inputs, and failures must be loud. Every agent validates what it receives against expectations (is this the full 12 months? does the data look complete?) and, critically, every agent must fail loudly , an upstream timeout should produce an explicit “incomplete data, cannot proceed,” never a silent partial result. Confidence and completeness must travel with the data, so a downstream agent knows it’s reasoning on 25% of the picture. In a chain, the most important thing an agent can say is “I’m not sure.”
Failure 4: The Infinite Handshake (Deadlocks and Loops)
When agents can call each other, they can also get stuck calling each other.
Our Decision orchestrator, facing a borderline case, asks Risk to re-evaluate with more weight on cash flow. Risk says “I need Compliance to confirm the sector classification first.” Compliance says “I need the Data agent to re-pull with the corrected business type.” Data re-pulls, Risk re-scores, Decision is still unsure, and asks Risk to re-evaluate again. Round and round. The application never resolves, tokens burn, and a human only notices when the latency alarm goes off or the bill does.
Or the subtler version: two agents each waiting for the other to go first, a classic deadlock, and the whole case just hangs.
Multi-agent systems, especially ones where the orchestrator can loop, are prone to exactly the pathologies distributed systems engineers have fought for decades , livelocks, deadlocks, infinite retries. The agents are each being “reasonable.” The system as a whole is stuck.
The fix is hard limits and a circuit breaker. Every workflow needs a maximum number of agent-to-agent round-trips, a maximum total time, and a maximum cost, after which it force-escalates to a human with whatever it has. No loop runs forever. An agent that’s been asked the same question twice should escalate, not re-answer. Treat “the agents couldn’t converge” as a first-class outcome that routes to a person , because an un-resolvable case resolved by a human in five minutes is infinitely better than one the system churns on for an hour and then gets wrong.
Failure 5: The Shared-State Collision (Two Agents, One Truth, No Lock)
The last one is pure distributed-systems gravity, and it bites the moment your agents share any mutable state.
Say two applications from the same business come in close together (a renewal and a new line), and both workflows touch a shared “total exposure to this borrower” record. Agent A reads exposure ($0 committed), decides there’s room, approves $50k. Agent B, running concurrently, also reads exposure ($0, because A hasn’t written yet), decides there’s room, approves another $50k. Now you’ve committed $100k against a $60k limit, and each agent was individually correct , they just both read stale state before either wrote.
This is the oldest bug in distributed computing , the race condition , and multi-agent AI systems reintroduce it enthusiastically, because agents act concurrently and the “state” they share (an exposure ledger, an inventory count, a rate limit) is exactly the kind of thing two agents will read-then-write without coordination.
The fix is the same as it’s always been: treat shared state as shared state. Anything multiple agents can read and modify needs proper concurrency control , locking, transactions, atomic updates , not hope. If two agents can act on the same record at once, assume they will, at the worst possible moment. The LLM part of your system is new; this part is a solved problem, and the solution is to stop pretending agents are the exception to fifty years of concurrency engineering.
The Thread Running Through All Five
Step back and notice what these have in common. Not one of them is “the AI wasn’t smart enough.” Every single failure is a coordination failure , context lost in a handoff, authority left ambiguous, bad data trusted, loops left unbounded, shared state left unlocked. The intelligence of the individual agents is almost irrelevant to whether the system works.
That’s the uncomfortable lesson of building real multi-agent systems: the agents are the easy part. Making several of them cooperate reliably, under real load, with real consequences, is a distributed systems problem wearing an AI costume. The field spent decades learning how to make independent processes coordinate without corrupting shared state or deadlocking each other. Multi-agent AI doesn’t get to skip that curriculum just because the processes now happen to reason in natural language.
So if you’re building one , or evaluating one someone else built , don’t start by asking how clever the agents are. Start by asking the five coordination questions: How does context travel, and does it degrade? Who owns each decision when agents disagree? What happens when one agent gets bad data? What stops the loop? And what locks the shared state?
Answer those well and you have a system that survives production. Skip them and you have a very impressive demo that will do something inexplicable the first busy Tuesday it meets the real world. The difference between those two outcomes is the entire job, and it’s the thing the serious AI agent builders spend most of their time on , not the agents, the coordination between them.
Multi-agent systems are powerful. They’re also distributed systems, with all the hard-won discipline that implies. Respect that, and the “team of specialists” pitch actually delivers. Ignore it, and the team of specialists turns into a committee that can’t agree, loses the paperwork, and occasionally approves a loan it shouldn’t.
Which of these has bitten you? For me the sneakiest is Failure 3 , the silent cascade , because nothing errors, everything “works,” and you only find out when the outcome is already wrong. What’s your worst coordination war story?
Top comments (0)