The hard problem in multi-agent AI is not the agents. It is the coordination between them — who decides, how state is shared, how one agent's error becomes another's input, and how the whole thing knows when to stop. Nearly every multi-agent failure I have seen or built is a coordination failure wearing an agent costume: the individual models were fine, and the system around them had no answer to a question distributed-systems engineers settled decades ago.
This matters because the industry is spending its attention in the wrong place. The pitch for multi-agent systems is that you decompose a hard task into specialists — a researcher, a critic, a planner, a coder — and let them collaborate. The implicit assumption is that collaboration is free, that if each agent is good enough the ensemble will be good. It is the same assumption that makes people think a group project succeeds because the members are smart. It fails for the same reason: the smartness of the parts is not the binding constraint. The protocol between them is.
So let me name the coordination problems precisely, because "the agents didn't collaborate well" is not a diagnosis. There are four, they are distinct, and each has a known shape borrowed from distributed systems and, in one case I keep returning to, from cell biology.
Control: an emergent conversation has no locus of decision
The seductive design is a group chat. You put four agents in a shared thread, give them roles, and let them talk until they converge. It feels intelligent because it looks like a meeting. It fails because a meeting with no chair does not converge — it stalls or it thrashes.
The concrete problem is that there is no locus of decision. When agent A proposes something and agent B objects, who adjudicates? If the answer is "they keep talking until they agree," you have built a system whose termination depends on emergent social dynamics between stochastic processes, which is not a thing you can put a service-level objective on. In practice one of two things happens. Either the agents are agreeable — trained toward helpfulness and assent — and they rubber-stamp each other into premature false consensus, or they are not, and they loop, each re-litigating the last turn with slightly different words.
There is also a cost curve nobody prices in. An all-to-all conversation among N agents has N(N−1)/2 potential channels — 6 for four agents, 45 for ten — and every agent typically has to read every other agent's output to stay current. Message volume and token cost scale quadratically in the number of participants while the useful work scales, at best, linearly. You are paying O(N²) to coordinate O(N) of actual thinking.
Distributed systems solved this a long time ago, and the answer is not "better participants." It is a coordinator. Raft and Paxos exist because consensus among equals is expensive and fragile, so real systems elect a leader that owns the sequence of decisions and lets the followers do the work. The multi-agent analog is a deterministic orchestrator: a piece of ordinary code — not a model — that owns the control flow. It decides which agent runs, with what input, in what order, and what happens to the output. The agents are still intelligent and open-ended inside their turn. What is no longer open-ended is who is in charge. A deterministic orchestrator with structured handoffs beats an emergent conversation for the same reason a leader-based consensus protocol beats a gossip free-for-all: control flow is a place you want legibility, not creativity.
Shared state: agents acting on stale views produce incoherent joint behavior
The second problem is the one people underestimate most, because it is invisible in a demo where everything happens in one context window. The moment your agents run in parallel, or persist anything, or hand off across steps, you have a distributed state problem, and distributed state is where correctness goes to die.
Here is the failure in its plainest form. Agent A reads the current plan and decides to book a flight. Concurrently, agent B reads the same plan — the version before A's booking — and decides the budget allows a hotel that A's flight just consumed. Neither agent is wrong given what it saw. The joint behavior is incoherent because they acted on inconsistent views of the world. This is a read-modify-write race, exactly the class of bug that database isolation levels and consensus protocols exist to prevent. Agents do not get a pass on it just because the actors are language models instead of threads.
The deeper issue is legibility of state. Much of the time, "the state" in a multi-agent system lives implicitly in a pile of conversation transcripts — each agent's private memory of what it thinks happened. There is no canonical answer to "what is true right now" that you can point at, diff, or validate. When the shared truth is smeared across a dozen chat histories, you cannot reason about consistency because you cannot even name the state.
The fix is unglamorous and non-negotiable: a single source of truth that is explicit, structured, and separate from any agent's private context. A shared task state — a document, a typed object, a small database — that the orchestrator reads and writes, and that agents propose changes to rather than mutate directly. This is CQRS and event-sourcing wisdom reheated for a new substrate: separate the authoritative state from the actors' local views, route every mutation through a single writer, and give every agent a fresh read of the canonical state at the start of its turn rather than letting it act on a memory that may be minutes and three decisions stale. State quality gates joint coherence at least as hard as model quality does. You can have four brilliant agents and a system that behaves like a committee with amnesia.
Error propagation: one agent's confident-wrong output is another's trusted input
The third problem is where multi-agent systems are strictly more dangerous than single agents, and it is why I am wary of long agent-to-agent graphs. In a chain of agents, one agent's output is the next agent's input, and language models emit fluent, confident wrongness by default. So a hallucinated fact or a subtly broken plan does not get caught — it gets inherited, wrapped in the next agent's equally confident prose, and passed downstream with compounding authority. The critic trusts the researcher; the writer trusts the critic; by the time a human sees it, the original error has been laundered through three layers of plausible-sounding agreement.
This is the compounding-error problem, and multi-agent topologies make it worse, not better, because they multiply the number of trust boundaries where an unverified handoff can occur. I have argued the arithmetic at length in The Compounding-Error Problem: per-step success probabilities multiply, so reliability decays exponentially in the length of the chain, and a graph of agents is just a chain with extra edges. The escape there is the escape here — verification gates between agents. A handoff from agent A to agent B should not be a raw pipe. It should pass through a check: does A's output satisfy the contract B is entitled to assume? If not, discard and retry the segment rather than let the bad state travel.
Cell biology has run this design for hundreds of millions of years, and it is the part of my flagship work — signal transduction — that I cannot stop mapping onto agent systems. A cell does not let a signaling cascade run unchecked. A receptor binds a ligand, a second messenger amplifies it, a kinase phosphorylates the next target — and at each stage there are thresholds, phosphatases, and negative-feedback loops whose entire job is to stop a spurious or runaway signal from propagating. A signal that fails to clear a threshold dies at that node instead of triggering the downstream program. The pathway is built so error does not travel, because in a cell, a signal that propagates when it should have been killed is how you get cancer: constitutive, unchecked signaling is a hallmark of oncogenesis. The gate between agents is the phosphatase that terminates the signal before it commits the organism to a decision it cannot take back. Put the intelligence in the agents; put a checkpoint on every edge.
Termination: agents that can call agents need a budget or they burn forever
The fourth problem is the most embarrassing when it happens and the easiest to prevent. An agent that can invoke other agents — or invoke itself — is a recursive process, and recursive processes without a base case do not terminate. In a multi-agent system the base case is not automatic. Agent A delegates to B, B decides it needs A's expertise and delegates back, and you have a delegation cycle that will happily consume your entire token budget re-deriving the same subproblem until someone kills the process or the bill does.
Emergent designs are especially prone to this because the stop condition is itself emergent: the agents are supposed to decide, collectively, that they are done. But "are we done?" is exactly the judgment a stalled or thrashing conversation is worst at. I have watched a reviewer-and-editor pair volley a document back and forth thirty times, each pass making a cosmetic change to justify its existence, neither willing to declare completion, because neither owned the termination decision.
The orchestrator owns termination, and it enforces it with mechanisms, not vibes:
- Budgets. A hard ceiling on total steps, tokens, wall-clock time, and dollars, decremented by the orchestrator and checked before every dispatch. When the budget is exhausted, the system returns its best current state rather than continuing.
- Cycle detection. Track the delegation graph. If A→B→A appears, or the same subtask is dispatched twice with no state change between, break the cycle — this is loop detection on a call graph, deterministic code, not a judgment call handed to a model.
- Explicit stop conditions. A structured definition of "done" the orchestrator can evaluate — a schema satisfied, a gate passed, an approval granted — rather than waiting for the agents to feel finished.
This is backpressure and circuit-breaking from distributed systems, and it is, again, the negative-feedback loop from biology: the mechanism that says enough, terminate the signal, return to baseline. A cascade with no off-switch is not a feature. It is a seizure.
The principle: intelligence in the agents, reliability in the orchestration
Collapse the four problems into one design rule. Prefer deterministic orchestration with structured handoffs and gates over "let the agents figure it out." The agents are where you want intelligence, open-endedness, and the model's full capability. The orchestration is where you want reliability, and reliability comes from determinism, legibility, and control — properties language models by their nature do not provide and should not be asked to provide. Do not make a model responsible for the parts of the system that need to be ~100% correct. Make code responsible for those, and let the model be brilliant inside the boundaries the code enforces.
Concretely: a deterministic orchestrator owns control flow; a single explicit source of truth owns state; every agent-to-agent edge carries a verification gate; and every recursive path carries a budget, cycle detection, and a stop condition. None of this is exotic. All four are load-bearing patterns lifted from systems that have coordinated unreliable components at scale for decades. The novelty of the substrate — that the components are now language models — does not repeal the coordination problems. It sharpens them, because language models fail more fluently and confidently than the flaky network calls we built these patterns for.
There is one genuine exception, and it is worth stating precisely so it is not mistaken for a license to build chatrooms. Sometimes the interaction is the mechanism. Adversarial structures — two agents arguing opposite sides of a claim before a judge — are productive precisely because the disagreement surfaces errors a single confident chain would sail past. That is not an emergent free-for-all; it is a structured protocol with defined roles, a bounded number of rounds, and an explicit adjudicator, which is to say it is orchestration in the shape of an argument. I make the full case in The Best Multi-Agent Design Is a Debate. The lesson does not contradict this one. It confirms it: the debate works because it is structured, terminated, and judged — because someone built the coordination instead of hoping it would emerge.
The agents were never the hard part. The wiring between them was, and it always is.