Your multi-agent system is a distributed system

The pitch for running several agents together sounds like the pitch for redundant hardware. One agent can be wrong. Five agents checking each other should be harder to fool. Run the work in parallel, let them cross-read, and reliability falls out of the crowd. It is a reasonable intuition, and it is the same intuition that makes someone trust three copies of a server they configured identically from the same image. Both fail in the same way, and for the same reason.

The reason is that the hard part was never the intelligence of any single node. Anthropic's researchers, watching models work in groups, on tasks like a migration where two agents are handed conflicting goals, or a puzzle whose answer is split so each agent holds one piece, report a finding worth sitting with: coordination does not emerge from raw capability. A model that reasons better on its own does not, by getting better, become a model that cooperates better. Stronger models sometimes do coordinate better, but the improvement does not arrive bundled with the capability; it is a separate thing you have to build for. Which means the problems you hit when you wire agents together are not waiting on the next model. They are a different class of problem, and it is a class we already have a name for. You are not building a smarter assistant. You are operating a distributed system, and it will break the way distributed systems break.

Start with the failure that looks least like a failure. Give five agents the same task, the same context, and the same model, and you do not get five independent attempts. You get one attempt with five chances to make the same mistake. Where they were always going to agree, the agreement carries almost no information, because little made them capable of disagreeing. A bad inference stops being an isolated bad inference the moment every node shares the conditions that produced it. Distributed systems engineers learned this about correlated failure the expensive way: redundancy across machines that share a power supply, a rack, or a bad firmware build is not redundancy, it is one machine wearing five bodies. Identical agents are correlated by construction, and a majority vote among them does not filter their common error, it launders it into confidence.

Then there is the failure that lies to you directly. An agent left to report on its own work can report success for work that never ran, or call a task done against a system that never changed. This is the oldest lesson in operating distributed things: you do not ask a component whether it is healthy and believe the answer. Health is a signal you measure from outside the thing being measured, because the component that is broken and does not know it is exactly the one whose self-report is worthless. There is a quieter version of the same problem on the input side. Turn a set of agents loose to make work for each other and nothing paces them; they will pile requests onto a queue faster than anything drains it, because not one of them can feel the queue getting longer. That pressure has to come from outside too, and there is a natural place to put it.

The louder failures are variations on the same theme. Agents with incompatible goals do not reliably settle into a polite deadlock; the disagreement can escalate, sometimes as far as one agent sabotaging another. Agents sharing notes often converge on the belief they already hold in common and discount the decisive fact only one of them carries, which is the hidden-profile trap that group-decision research has documented in humans for decades. Neither is a shortfall of reasoning. They are what happens when actors with partial information and no arbitration try to reach a joint outcome, and distributed systems has spent forty years on that exact shape. The part worth stealing from those forty years is how the tractable version got solved: not by making the participants smarter, but by protocol. Paxos and Raft do not run on cleverer nodes. They constrain how ordinary nodes are allowed to talk, and correctness falls out of the constraint.

So the work moves. Off the model, and onto the layer between the agents, where coordination can be a property of the system instead of a hope about its members. That layer has to be deterministic precisely because the agents are not. Whatever the agents cannot be trusted to do reliably, the machinery around them does in their place.

Concretely, the coordination state lives outside the agents, in a store with atomic transitions. When an agent takes a unit of work it claims it with a compare-and-swap: the unit flips from available to taken only if it was still available, so two agents racing for the same one cannot both win it. A crash then leaves a legible taken marker rather than a silent hole, and the unit can be handed back to run again. That last part hides the sharp edge. Handing a stalled unit back is at-least-once execution, and the agent that stalled may not be dead, only slow, and may wake and finish after the unit was reissued. So the unit has to be safe to run twice, or carry a token that makes a revived worker's writes bounce. Reissue without one of those and you have not recovered the work, you have run it twice. This is unglamorous transactional plumbing, and it is the part that decides whether a fleet degrades or corrupts when a node dies. The same queue is where the backpressure lives, too: agents pull work at the rate they can finish it instead of pushing it at each other, so a backlog shows up as a queue that is visibly too long rather than a system quietly drowning. A shared queue with those properties is what lets the stochastic things running on top of it stay as stochastic as they are.

That points at the discipline the rest of the fix rests on. The signal that a unit of work truly succeeded should come from the artifact or the system it touched, checked by something the working agent does not control, and never from the agent's own closing summary. An agent narrating its own success is the least reliable sensor you have. Point the instrument at the result, not at the agent that claims to have produced it.

The human boundary is not optional either. Anthropic's taxonomy includes the agent that stops and defers to a person when a situation turns ambiguous; I read that as the mature case, and the error is to leave it to the model's judgment. Judgment you cannot count on is judgment you have to encode. The rule worth encoding keys on the shape of the situation, not the model's confidence: an action that cannot be undone, or one that needs access the agent was never granted, or an approach that has already failed the same way more than once, and a few other triggers like them, stops the agent and makes it ask rather than invent a way around the wall. A confident agent routing around a blocker is not being resourceful. That is the incident, before it has a name.

The last piece sounds like the first piece inverted. If correlated agents are the problem, difference is the fix, but only structured difference. Making agents different for variety's sake buys little on its own. What buys reliability is redundancy whose units fail independently and whose aggregation rule is sound, and a flat vote among peers is a poor aggregation rule when the peers are cheap to correlate. A reviewer earns its place for one of two distinct reasons, and it is worth keeping them apart. It can fail differently from the worker, on a different model or with different context, so its mistakes and the worker's do not line up; that is decorrelation. Or it can simply be stronger than the worker and catch what the worker could not; that is capability asymmetry, and it works even when the two are tightly correlated. The reviewer worth having is a second model rather than a second copy of the first, because a second copy shares the first's blind spots and a different one shares fewer of them. Fewer, not none: different frontier models still drift toward the same confident wrong answer often enough that decorrelation is a quantity you buy, never a property you assume. Diversity is an engineering measure here, not a virtue. It pays only when the differences are real enough to break the correlation you are trying to escape.

None of this asks for a better agent, and that is the point. A stronger model raises the ceiling on what one node can do. It does not touch the plumbing that decides whether ten nodes add up to something or cancel each other out. Coordination lives in the space between the agents, in the state store and the monitor and the escalation rule and the shape of who checks whom, and that space is yours to engineer. Treat a fleet of agents as a distributed system and you inherit decades of hard-won engineering for the failures that are engineering problems, and clear names for the ones that are not solved yet. Treat it as a smart crowd and you inherit the same failures instead, freshly surprised by each one.