How Multi-Agent Systems Actually Coordinate

The only question that matters

Almost every piece of writing about multi-agent LLM systems starts in the wrong place. It starts with a framework — a decorator, a Crew, a graph builder — and then works backwards to justify why you would want five language models talking to each other. The framework makes the architecture feel inevitable. It is not.

Start instead from the computational question, which is embarrassingly simple to state and surprisingly hard to answer:

Notice what this question does. It refuses the comparison that most papers and most demos actually run, which is “four agents versus one agent,” where the four-agent system silently spends four times the tokens. Under that comparison a multi-agent system almost always wins, and the win tells you nothing, because you have not isolated the variable you care about. You have discovered that spending more compute helps. We already knew that.

The honest comparison holds the budget fixed and asks whether partitioning that budget across several policies with private contexts and explicit messages buys anything that spending it inside one context does not. That is a real question with a real answer, and the answer has a shape: for a broad class of tasks the single agent wins, and there is an identifiable regime where it stops winning. Most of this article is about locating that boundary and understanding what governs it.

Two things happened between 2023 and now that make this worth revisiting rather than settling. First, the empirical literature turned sceptical: once compute is matched, the multi-agent advantage on reasoning benchmarks largely evaporates. Second, the engineering practice went the other way: the systems people actually ship in 2026 — deep research products, coding swarms, orchestrator-trained models — are aggressively multi-agent and demonstrably work. Those two facts are not contradictory. They are measuring different things, and the gap between them is exactly where the interesting content lives.

What makes a system multi-agent

A single agent is a policy stepping through states:

\[ s_t \;\xrightarrow{\;\pi\;}\; a_t, \qquad s_{t+1} = \mathrm{Env}(s_t, a_t). \]

Everything the agent knows is in one context window. Everything it decides is decided by one forward pass conditioned on that window. There is exactly one thread of decision-making.

A multi-agent system replaces \(\pi\) with a family \(\pi_1,\dots,\pi_N\), and — this is the part that matters — gives each of them a different view. Agent \(i\) acts according to

\[ a_i^{(t)} \;\sim\; \pi_i\!\left(\,\cdot \;\middle|\; o_i^{(t)},\; M_i^{(t)},\; \{m_{ji}^{(t')}\}_{j,\,t'

where \(o_i\) is agent \(i\)’s observation, \(M_i\) is its memory, and \(m_{ji}\) are messages received from agent \(j\). Four things can differ across agents, and each is a genuinely separate design axis:

• Instructions. Different system prompts, different objectives, different stopping rules.
• Observations. Different tools, different data, different permissions. This is information partitioning, and it is doing more work than most people realise.
• Parameters. Different models entirely, or the same model with different weights after fine-tuning.
• Communication. Who may send what to whom, when, and in what format.

Running the same model twice on the same prompt is not a multi-agent system. It is sampling. The multi-agent claim is that

\[ \underbrace{\text{specialisation}}_{\pi_i \neq \pi_j} \;+\; \underbrace{\text{partitioning}}_{o_i \neq o_j} \;+\; \underbrace{\text{communication}}_{m_{ij}} \;+\; \underbrace{\text{coordination}}_{\text{who acts when}} \]

buys you something that a bigger context and more samples cannot. Each of those four terms has a cost. The cost is not hypothetical: it is measured in tokens, latency, and the specific ways coordination breaks.

The baseline you have to beat

Before adding a second agent, you owe the design a comparison against the ladder of things a single agent can already do with the same money. Each rung spends more compute; none of them requires a second policy.

1. One sample. \(y \sim \pi(\cdot \mid x)\). The floor.
2. Longer thinking. Same policy, larger reasoning budget. On a reasoning model this is a single knob.
3. Self-consistency. Draw \(y_1,\dots,y_K\) independently and take the mode. Costs \(K\times\), needs no verifier, needs no coordination.
4. Best-of-N. Draw \(N\), score with a verifier or reward model, keep the best. Strictly stronger than voting if you have a good scorer.
5. Iterative refinement. \(y_0 \to \text{critique} \to y_1 \to \dots\), all inside one context.
6. Search. The single agent branches internally — tree search over reasoning steps or over tool-call trajectories.

Only after those does “make the branches into separate communicating agents” become a distinct proposal. And the moment you frame it that way, the question sharpens: what does making the branches independent policies with private contexts add, given that we already had branches?

The 2024 comparison of debate protocols by Smit and colleagues is the cleanest early answer. Benchmarking a range of debating and prompting strategies against each other, they found that multi-agent debating systems, in their current form, did not reliably outperform other proposed prompting strategies such as self-consistency and ensembling over multiple reasoning paths. Their diagnosis was not that debate is inherently worse but that it is fragile: debate protocols turned out to be unusually sensitive to hyperparameters, and tuning a single knob — how strongly agents are prompted to agree with one another — moved the worst-performing protocol to the best. A method whose ranking flips on one prompt-level dial is not yet a robust architectural advantage.

Why one agent should win — and when it stops

There is a clean information-theoretic reason to expect the single agent to win at matched budget, and it is worth deriving because it also tells you precisely where the argument fails.

The data processing inequality

Let \(X\) be the task — everything relevant about the problem instance. A single agent forms an internal reasoning state \(Z\) from \(X\) and emits an answer \(Y\). That is a Markov chain \(X \to Z \to Y\), and the data processing inequality says

\[ I(X;Y) \;\le\; I(X;Z) \;\le\; H(X). \]

Information about the task can be destroyed by processing but never created. Now take a multi-agent system. Sub-agent \(i\) forms its own state \(Z_i\) from its slice of the task, and then — here is the crucial step — it does not hand \(Z_i\) to the aggregator. It hands a message \(M_i = g_i(Z_i)\), which is a short natural-language summary of a long reasoning trace. The chain is

\[ X \;\to\; \{Z_i\} \;\to\; \{M_i\} \;\to\; Y, \]

and so \(I(X;Y) \le I(X; \{M_i\})\). Every handoff is a lossy compression step that the single agent simply does not perform. Under a fixed reasoning-token budget and perfect context utilisation, the single agent is strictly more information-efficient.

This is not a thought experiment. Tran and Kiela made exactly this argument and then tested it, holding the thinking-token budget constant across single-agent and five multi-agent architectures. Across three model families, single-agent systems consistently matched or outperformed multi-agent systems on multi-hop reasoning once reasoning tokens were held constant; their conclusion was that many reported multi-agent advantages are better explained by unaccounted computation and context effects than by inherent architectural benefits. They also found something methodologically uncomfortable: artifacts in API-based budget control and in the benchmarks themselves can inflate apparent multi-agent gains, which means part of the earlier literature was partly measuring its own instrumentation.

The escape clause

Read the condition again: perfect context utilisation. That is the load-bearing assumption, and it is false in every long-horizon system anyone actually runs.

Real models do not use a 400,000-token context as well as they use a 20,000-token one. Call \(\eta(L) \in (0,1]\) the fraction of the information in a length-\(L\) context that the model actually brings to bear on the current decision. Empirically \(\eta\) declines with \(L\) — not because of a hard limit but because attention is a finite resource being spread over more material, and because the ratio of relevant to irrelevant tokens falls as tool outputs, retries, and dead ends accumulate. Then the single agent’s effective information is not \(I(X;Z)\) but roughly \(\eta(L)\,I(X;Z)\), and a partitioned system with \(k\) short contexts retains \(\eta(L/k)\) of each slice.

The crossover condition is the whole subject in one line: split when the loss from compressing at the handoff is smaller than the loss from degrading a context you were going to overfill anyway.

Two consequences follow immediately, and they explain most of the apparent disagreement in the field.

If your task fits comfortably in one context and the model uses it well, you should expect multi-agent architectures to lose at matched cost, and the sceptical literature is measuring exactly that regime. Multi-hop question answering over a handful of retrieved documents is that regime.

If your task cannot fit — a week-long build, a search across hundreds of sources, a repository too large to read — then \(\eta\) for the single agent is not merely degraded, it is undefined, because the context does not exist. There the comparison is not “one agent versus many” but “many agents versus nothing.” Anthropic put it plainly when describing their research system: the architecture pays off on breadth-first queries where the total information exceeds a single context window, and is a poor fit for tightly interdependent work.

Three real reasons to add an agent

Strip away the org-chart cosplay and there are exactly three mechanisms by which a second policy can beat spending the same tokens on the first. Every real system is some combination of them, and knowing which one you are relying on tells you what will break.

1. Independent search

Different agents explore different trajectories \(\tau_1,\dots,\tau_N\). If each independently solves the problem with probability \(p\), then

\[ P(\text{at least one succeeds}) = 1 - (1-p)^N, \]

which climbs fast. With \(p = 0.4\), five agents give you \(0.92\). This is the argument people reach for first, and it is the one that most often fails to survive contact with reality, for a reason developed in the next section: independence is the assumption doing all the work, and language model errors are not independent.

Note also that this mechanism does not require agents at all. It requires samples plus a way of choosing among them. Best-of-N with a verifier gets the same \(1-(1-p)^N\) without any messages. If your justification for a multi-agent system is independent search, you have justified best-of-N.

2. Specialisation

One policy conditioned on “research, then design, then implement, then test, then review” is being asked to hold five distinct sets of priors, five output formats, and five failure vocabularies in one context. Splitting the roles makes each handoff explicit:

— gives each stage a tighter prior and a shorter context. This is the insight MetaGPT formalised: encode human standard operating procedures into the agent workflow rather than letting agents free-associate in a group chat. ChatDev took the same idea through a waterfall of design, coding, testing, and documentation phases. The claim is not that a coding agent is smarter than a general agent. It is that a prompt is a prior, and narrower priors produce lower-variance behaviour.

The interesting question — taken up in §10 — is what kind of specialisation you are actually buying. A different system prompt is not a different policy in the way a different model is.

3. Information partitioning

An agent does not need to see everything, and there are three separate reasons that helps:

• Attention economics. A shorter context is a context the model uses better. This is the \(\eta(L)\) term from §4 and it is the strongest of the three.
• Permissions. A finance agent that cannot read security logs cannot leak them. Partitioning is an access-control primitive as much as a performance one.
• Decorrelation. Two agents that read different things make different mistakes. This is the only mechanism that attacks the correlation problem head-on.

Partitioning is also the mechanism with the sharpest cost, because the partition boundary is the lossy compression step from §4. Everything you gain in attention fidelity you pay for in what fails to cross the handoff.

The crowd is only wise if it disagrees

Majority voting over \(N\) agents is the workhorse aggregation rule, and the arithmetic that makes it look good assumes independence. Drop that assumption and the picture changes qualitatively, not quantitatively.

Model it the simplest honest way. Let each agent be individually correct with probability \(p\). Introduce a latent common-mode variable \(C \sim \mathrm{Bernoulli}(\rho)\): with probability \(\rho\) the whole ensemble shares a blind spot — the same misread of the question, the same wrong fact memorised in pretraining, the same seductive-but-wrong approach — and every agent produces the same answer, correct only with the base probability \(p\). With probability \(1-\rho\) the agents fail independently. Then majority-vote accuracy is

\[ A(N) \;=\; \rho\,p \;+\; (1-\rho)\,\Pr\!\big[\mathrm{Bin}(N,p) > \tfrac{N}{2}\big]. \]

Take \(N \to \infty\). The binomial term goes to \(1\) for \(p > 1/2\), and you are left with

\[ \boxed{\;A_\infty \;=\; 1 - \rho\,(1-p)\;} \]

The ceiling on voting does not depend on \(N\) at all. It depends on \(\rho\). With \(p = 0.6\) and \(\rho = 0.5\), no number of agents gets you past \(80\%\). You can spend a hundred times the compute and buy nothing, because the errors you needed to cancel were the ones that never disagreed.

This is why “run the same model five times with different personas” underdelivers so reliably. Persona prompts perturb style far more than they perturb the underlying belief distribution. The blind spots come from pretraining, and a system prompt does not reach them.

It is also why heterogeneity is the resource, not agent count. Mixture-of-Agents built on precisely this: layers of proposer models from different families whose responses feed an aggregator, exploiting the observation that models tend to produce better responses when shown other models’ answers — even answers from weaker models. On AlpacaEval 2.0 a stack of open-source models reached a length-controlled win rate of 65.1%, above GPT-4 Omni’s 57.5%.

And it is why the follow-up result matters. Li and colleagues asked whether the mixing was really doing the work, and found that ensembling multiple outputs from a single strong model — Self-MoA — often beat mixing different models, because ensembling performance turned out to be more sensitive to proposer quality than to proposer diversity. Diversity helps only when it is diversity among models that are individually good. Adding a weak model to your ensemble adds \(\rho\)-reducing variance and quality-reducing noise at the same time, and the second effect usually wins.

Context, not parallelism

Here is the reframing that the 2026 practice converged on, and it is not the one the 2023 literature would have predicted.

The dominant reason to split a task across agents is not that the pieces run concurrently. It is that splitting keeps every context short. Cursor, after running hundreds of concurrent coding agents on multi-week projects, stated it directly: they suspect the ability to scale the swarm comes from context efficiency more than from parallelism, which is why the same decomposition helps even on moderately sized tasks where there is no wall-clock pressure at all.

The mechanism is easy to see once you draw the task as a tree. A goal at the root subdivides recursively into units of work at the leaves. A single agent taking the whole task has to walk that tree itself, descending to each leaf while holding its ancestors, its current position, and the overall goal in context the entire time. It gets one bad choice: focus on the work in front of it and lose the plot, or hold the plot and do the leaf badly. Split the roles and neither agent has to do both — a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend its whole context on one narrow piece.

Cognition’s reviewer result is the same mechanism from the other side. When a coding agent has worked for hours — reading the repo, running commands, considering approaches, fixing errors — its context is enormous. A dedicated review agent skips all of that, looks only at the diff, and re-discovers whatever it needs by reading the code fresh. With a shorter context the improved intelligence naturally leads to catching more nuanced issues. On pull requests written by Devin, their review agent catches roughly two bugs per PR, about 58% of them severe.

Notice how strange that is under the classical framing. Same model, same harness, no additional information, no debate — and it finds real bugs in its own work. Not because a second mind was added, but because a second context was, and context is the scarce resource.

Topology is the architecture

Represent the system as a graph \(G = (V, E)\) where \(V\) are agents and \(E\) are permitted communication channels. Almost every design decision people describe in prose is a statement about \(G\), and the graph determines four quantities that matter more than any prompt:

\[ \underbrace{|E|}_{\text{channels}},\qquad \underbrace{\text{msgs per round}}_{\text{token bill}},\qquad \underbrace{\text{depth}(G)}_{\text{latency floor}},\qquad \underbrace{\text{blast radius}}_{\text{failure containment}}. \]

Fully connected

Everyone talks to everyone. Maximum information sharing, and \(\binom{N}{2}\) relationships. With \(N = 8\) that is 28 channels and 56 directed messages per round. Each agent’s context now contains \(N-1\) other agents’ output, which means you have reintroduced the long-context problem you split the task to avoid. The mesh is a trap: it looks like the most capable topology and is usually the least.

Coordinator, or star

One agent decomposes, delegates, gathers, integrates. \(|E| = N-1\). This is the dominant production pattern, and for good reason: it bounds every worker’s context to its own subtask, bounds the coordinator’s context to \(N\) summaries rather than \(N\) full traces, and gives you one place to put the plan. Anthropic’s research system is exactly this shape — a lead agent that plans, saves its plan to memory so it survives context exhaustion, spawns three to five subagents in parallel, and synthesises their condensed findings with a separate citation pass.

Hierarchy

Star, recursively. Necessary once \(N \gg 1\), because a single coordinator’s context becomes the bottleneck at exactly the moment you wanted to scale. Cursor’s swarm is a planner/worker tree where planners split goals and delegate, and workers execute leaves. The economic argument they invoke is Coase’s: coordination costs grow faster than the work itself, so organisations settle into tiers of bounded units rather than letting everyone talk to everyone. That is not a metaphor, it is the same \(O(N^2)\) versus \(O(N \log N)\) trade you would reason about in any distributed system.

The overhead is real and worth naming. Every management layer is a lossy re-encoding of intent, and a manager without deep context tends to compensate by being overly prescriptive — a failure Cognition report hitting when they extended delegation to larger scopes.

Pipeline

Strictly sequential stages. Good when the dependency structure genuinely is sequential and you want each stage’s prior to be tight. Zero parallelism benefit, maximum specialisation benefit, and the worst error-propagation profile: stage \(k\) inherits every mistake from stages \(1..k-1\) with no independent check.

Blackboard

Agents do not message each other. They read from and write to a shared workspace — files, a task database, an issue tracker, a design doc. Communication cost drops from \(O(N^2)\) to \(O(N)\) per round because each agent writes once and reads a slice.

This is what production systems mostly do, and the name for the biological version is stigmergy: ants and termites coordinate by shaping the environment, and the environment shapes the next organism. Cursor pushed this into an explicit “Field Guide” — a folder owned entirely by the agents whose index is injected into every agent at start, with a line budget as the only constraint. The logic is sharp: model weights are frozen, so it is precisely the surprising encounters that are worth writing down, because that is what shortens the next agent’s trajectory.

Who decides who works

Given a task \(x\), something has to select the working set \(r(x) \to \{A_i\}\). The options form a ladder of increasing flexibility and decreasing predictability:

1. Fixed workflow. Code determines the sequence. Predictable, debuggable, brittle to task variety.
2. Rule-based router. if code task -> coder. Fine until the taxonomy leaks.
3. LLM router. A model reads the task and picks. Flexible, opaque, and prone to picking the same thing every time.
4. Learned router. Train \(P(A_i \mid x)\) against expected utility net of cost. This is where the field is heading and it is the subject of §16.

The structural analogy is worth stating precisely because it is illuminating and also imperfect. A mixture-of-experts layer routes tokens to parameter experts inside a forward pass; a multi-agent orchestrator routes tasks to reasoning experts across forward passes. Both face load balancing, both face router collapse, both need an auxiliary term to stop the router degenerating onto one expert.

Where the analogy breaks: MoE routing is differentiable and trained end-to-end with the experts, at a granularity of one token and a cost of one matmul. Agent routing is a discrete decision, made once, whose consequences unfold over minutes and thousands of tokens, with no gradient path back through the subagent’s execution. That gap — credit assignment across a non-differentiable, long-horizon, multi-policy trace — is the central technical difficulty in training these systems, and we will come back to how Kimi’s PARL sidesteps it.

Five kinds of specialisation

“Agent A is a security expert, agent B is a performance expert” sounds like two policies. Formally it is one set of parameters \(\theta\) with two different contexts \(c_A, c_B\). Whether that counts as specialisation depends entirely on what you expect it to buy.

The table has a blunt implication. Persona specialisation — the kind that costs nothing and is therefore the kind everyone starts with — is the only row that does not move any of the levers that matter. It changes tone. It does not change what the model believes, what it can see, or how much context it burns.

The rows that do work are the ones that change what enters the context or what parameters process it. That is a useful filter to apply to any proposed multi-agent design: if you cannot say which row it lives on, it is probably persona specialisation wearing a hat.

Homogeneous versus heterogeneous

A homogeneous team — every agent on the same model — is simple and predictable, and shares every blind spot. A heterogeneous team mixes a strong reasoner, a cheap router, a coding specialist, a vision model, a verifier. The heterogeneity buys decorrelation, but only if every member is individually strong, per the Self-MoA result.

There is a nuance from practice worth flagging, because it cuts against intuition. Cognition argue that two instances of the same model in two agents are not self-biased in the way one human doing both jobs would be: these are systems that perform based on their context, they do not have egos, and any shared bias comes from training rather than from psychology. Which means same-model, different-context pairings can be more decorrelated than the human analogy suggests — but only along the dimensions that context controls. The pretraining-level blind spots remain shared.

Debate, and what it actually buys

Debate is one protocol, not the definition of the field. Two independent proposals cross-examine each other before a judge sees the revision:

Du and colleagues showed that having multiple model instances propose and debate their responses over several rounds improves mathematical and strategic reasoning and reduces hallucinated content. That result is real and was influential.

Then came the compute-matched comparisons, and the picture got complicated. Smit and colleagues found debate did not reliably beat self-consistency at comparable cost, and that debate’s ranking was unusually sensitive to hyperparameters. Tran and Kiela, holding thinking tokens constant, found debate among the multi-agent architectures that failed to beat a single agent. And their quieter finding is the sharpest: single-agent prompts with explicit pre-answer analysis recovered most of what looked like a collaboration benefit. The extra thinking was the source of the gain, not the collaboration — and you can have the extra thinking without the extra agents.

So the honest reading of debate is: it is a way of spending more compute with a structure that sometimes helps and often does not, whose benefit is bounded by \(\rho\) exactly like voting, and which must be compared against self-consistency at equal cost before any claim is made. The 2026 audit of automatically-designed multi-agent systems reported the sharpest version of this: frameworks that search for good topologies frequently degenerate into trivial ensembles, rediscovering basic ensembling motifs under the guise of an optimised graph, so that roughly a tenfold cost increase bought little more than a redundant, poorly-routed version of a standard chain-of-thought-with-self-consistency baseline.

Consensus rules

Once you have \(N\) candidate answers the aggregation rule is its own design space: majority vote \(y^\star = \mathrm{mode}(y_1,\dots,y_N)\); weighted vote \(S(y) = \sum_i w_i \mathbf{1}[y_i = y]\); a judge agent \(y^\star = J(y_1,\dots,y_N)\); pairwise tournament; or a critic-refiner loop. Sparse variants of Mixture-of-Agents add a judge that keeps only the top responses and a moderator that halts early once quality plateaus, which is a direct attack on the cost side.

But every one of these inherits the same constraint. When errors are correlated — \(P(e_i, e_j) \gg P(e_i)P(e_j)\) — voting does not produce correctness, it produces confidence. The ensemble agrees, the judge sees unanimity, and the system reports high confidence in a wrong answer. That is strictly worse than a single agent that would at least have been uncertain.

Talking has a bill

In a single agent, thinking and communicating are the same act — tokens go into the context and stay there. In a multi-agent system they are separate, and the second one is a line item.

Suppose \(N\) agents run for \(R\) rounds, each producing \(L\) tokens per round, in an all-to-all discussion. Every agent must read what the others wrote. The prefill cost alone scales as

\[ T_{\text{comm}} \;=\; O\!\big(R\,N^2\,L\big), \]

because each of \(N\) agents processes \(\sim (N-1)L\) tokens per round. At \(N = 8\), \(R = 4\), \(L = 1500\) that is roughly 340,000 tokens spent purely on agents reading each other. If the actual work was 40,000 tokens, you are running at about 12% useful utilisation.

So the real objective is not accuracy. It is

\[ \max_{\text{system}} \;\; \underbrace{Q}_{\text{quality}} \;-\; \lambda_1 \underbrace{T}_{\text{tokens}} \;-\; \lambda_2 \underbrace{W}_{\text{wall clock}} \;-\; \lambda_3 \underbrace{\$}_{\text{price}}, \]

and every architectural choice is a point on that surface. Anthropic’s number for their research system is the honest version of this: it consumes roughly fifteen times the tokens of a normal chat interaction, which makes it suitable only where the value of the answer justifies the spend. They also reported that in their browsing evaluations, token usage alone explained about 80% of the performance variance, with tool-call count and model choice explaining most of the rest. Read that carefully — it says the architecture’s main contribution is that it lets you spend more tokens usefully, by giving those tokens somewhere to live other than one saturated context.

Compressing the channel

The fix is to stop sending trajectories and start sending conclusions. Instead of a 10,000-token trace, send a structured artifact:

{
  "claim":            "The rate limiter drops bursts above 200 rps",
  "evidence":         ["limiter.rs:88-140", "load-test-3.json"],
  "confidence":       0.72,
  "assumptions":      ["single-node deployment"],
  "open_questions":   ["behaviour under clock skew"],
  "artifact_pointer": "s3://runs/3f2a/report.md"
}

This is protocol design, and it is the part of multi-agent engineering that most resembles ordinary distributed systems work. Three properties matter: messages should be bounded (so \(L\) does not grow with trajectory length), typed (so the receiver can validate rather than interpret), and referential (a pointer to an artifact instead of the artifact, so the receiver decides whether to pay for it).

The industry has converged on two protocol layers for this. MCP standardises how an agent reaches tools and data; A2A standardises how agents discover and delegate to each other, with agents publishing capability cards and exchanging typed task lifecycles. Both now sit under the same Linux Foundation umbrella, which matters mostly because it means the wire format is no longer the interesting problem. The interesting problem is what you put on the wire.

Shared state and the reconciler

Each agent has private memory \(M_i^{\text{private}}\) and the system has shared memory \(M^{\text{shared}}\). Everything hard about multi-agent systems lives in the boundary between them:

• When should private reasoning be promoted to shared state?
• Who may edit shared state, and does a write need review?
• What happens when researcher A writes fact \(X\) and researcher B writes \(\lnot X\)?
• How do you version, attribute, and expire what is written?

The third question is the one that has no clean answer, because a blackboard cannot store both \(X\) and \(\lnot X\) as equally valid truths and expect downstream agents to behave. Cursor’s solution is instructive because it is structural rather than prompt-level: agents record decisions in shared design documents, code that depends on a decision carries a compile-checked reference back to its document, and when two planners unknowingly contradict each other a reconciler merges the documents and the references propagate the resolution downstream. The disagreement is resolved once, in one place, and the type system carries the consequence everywhere.

Their merge-conflict finding is equally telling. Worker agents are bad at resolving conflicts — to do it properly a worker would have to stop, absorb the other agent’s context, and merge around it, and in practice they either overwrite the other change or abandon their own. The fix was a neutral third-party agent whose only goal is to be impartial and efficient, playing the role a merge queue plays for human teams.

That is the general shape of the answer. Do not ask agents to negotiate. Give them a mechanism. Locks, queues, reconcilers, compile-checked references, single-writer discipline — these are the primitives, and they work for the same reason they work in databases: they replace agreement with structure.

Amdahl, Brooks, Coase

The parallelism argument is the one that is easiest to state and easiest to over-claim. If tasks are independent, wall-clock time is \(\max_i T_i\) rather than \(\sum_i T_i\). But dependencies impose a critical path, and Amdahl’s law applies to agent workflows exactly as it applies to threads. With parallelisable fraction \(f\) and \(N\) workers,

\[ S(N) \;=\; \frac{1}{(1-f) + f/N}, \qquad S(\infty) = \frac{1}{1-f}. \]

With \(f = 0.8\), infinite agents buy you \(5\times\). Not 100×. Five.

Then subtract the coordination term. Agents must be briefed, their outputs read, their conflicts resolved — and in the mesh case that cost grows superlinearly. A serviceable model is

\[ T(N) \;=\; T_1\!\left[(1-f) + \frac{f}{N}\right] \;+\; \kappa\,N^{\alpha}, \qquad \alpha \in [1, 2], \]

which has an interior minimum. Past \(N^\star\), adding agents makes the system slower as well as more expensive. This is Brooks’s law with a token bill attached, and Coase’s explanation for why firms have tiers rather than universal mutual coordination.

Cursor’s old-versus-new swarm comparison is the most vivid measurement of that coordination term anyone has published. Running the same task with the same models under two different harnesses, the old harness produced 68,000 commits in two hours — roughly seventy times the new harness’s pace — while accumulating more than 70,000 merge conflicts and accelerating rather than stabilising, until they paused the run. The new harness logged fewer than a thousand conflicts over four hours. The single hottest file in the old run collected 7,771 conflicts across 1,173 different agents; in the new run the most contested file in the entire codebase saw 47.

All of that thrash showed up in the artifact. On the same task and the same model mix, the old swarm needed 64,305 lines of engine code to pass the suite where the new one needed 9,908. Nearly all of that difference was coordination failure rendered as code.

How these systems actually fail

This section is not optional. Multi-agent systems have a characteristic failure profile, and it is not “the model was not smart enough.”

The most careful study is Cemri and colleagues’ failure taxonomy, built from more than 1,600 annotated execution traces across seven multi-agent frameworks, with high inter-annotator agreement. They identified 14 distinct failure modes clustering into three categories: specification and system design issues, inter-agent misalignment, and task verification and termination. Their headline framing is worth quoting in spirit: despite the enthusiasm, gains on popular benchmarks are often minimal, and the failures often stem from system design rather than from limitations of the underlying model.

That last clause is the whole point. These are engineering failures, not intelligence failures, which means they are fixable by engineering.

Termination is a policy, not an accident

Agent conversations do not naturally stop. You need an explicit predicate:

\[ \text{stop} \;\Leftarrow\; \big[\text{verifier accepts}\big] \;\lor\; \big[\Delta \text{information} < \epsilon\big] \;\lor\; \big[\text{budget exhausted}\big] \;\lor\; \big[\text{confidence gain stalls}\big]. \]

Missing termination conditions appear in the failure taxonomy for a reason: absent a rule, the system converts your budget into transcript.

The security surface is different in kind

A single agent facing a prompt injection has one compromised context. A multi-agent system has a graph, and injection becomes an epidemiological problem. The prompt-infection work demonstrated malicious prompts that self-replicate across interconnected agents, behaving like a computer virus — the compromised agent embeds the payload in its otherwise-legitimate outputs, and each recipient relays it further. The multimodal version showed a single adversarial image propagating through pairwise exchanges to reach on the order of a million agents.

The structural implication is uncomfortable for the star topology in particular: trust in these systems flows top-down, with subagents executing orchestrator instructions without independent verification, which means a compromised low-privilege subagent can inject upward through a channel that is trusted by construction. The mitigations are the boring ones — least privilege per agent, treating every inter-agent message as untrusted input rather than as instruction, and bounding what any single agent can write — and they are boring precisely because they are the same mitigations that work everywhere else.

Learned orchestration

Every design decision discussed so far — how many agents, which topology, what to send, when to stop — has been treated as something a human writes down. The most consequential development of the last year is that these decisions have started being learned.

The clearest publicly documented instance is Moonshot’s Parallel-Agent Reinforcement Learning. Rather than executing a task as a reasoning chain or applying a fixed parallelisation heuristic, the model initiates an agent swarm through dynamic task decomposition, subagent instantiation, and parallel subtask scheduling — and, crucially, parallelism is not presumed to be advantageous. Whether, when, and how to parallelise are learned through environmental feedback and exploration.

The architecture sidesteps credit assignment

PARL uses a decoupled design: a trainable orchestrator and frozen subagents instantiated from fixed intermediate checkpoints. During training the subagents’ execution traces are treated as environmental observations rather than as differentiable decision points, and only the orchestrator is updated.

This is a deliberate refusal to do end-to-end multi-agent optimisation, and the stated reasons are precisely the two problems flagged in §9. Outcome-based rewards in a multi-agent setting are sparse and noisy: a correct final answer does not mean every subagent performed well, and a failure does not mean they all erred. Freezing the subagents turns an \(N\)-policy credit-assignment problem into a single-policy RL problem where the swarm is part of the environment. It is the same move as centralised training with decentralised execution in classical multi-agent RL, taken to its simplest extreme.

Serial collapse and the shape of the reward

Training an orchestrator to parallelise turns out to have a specific pathology. Left to optimise task success alone, the orchestrator discovers that single-agent execution is a reliable local optimum and stops spawning subagents at all — serial collapse. The path of least resistance is to do the work yourself.

The fix is staged reward shaping over three terms:

\[ r_{\text{PARL}}(x,y) \;=\; \underbrace{r_{\text{perf}}(x,y)}_{\text{did it work}} \;+\; \lambda_1 \underbrace{r_{\text{parallel}}}_{\text{did you spawn}} \;+\; \lambda_2 \underbrace{r_{\text{finish}}}_{\text{did they finish}}. \]

The parallelism term exists only to push the orchestrator out of the serial basin early in training, and it is annealed toward zero so that the final policy optimises task success rather than parallelism for its own sake. The finish term guards the opposite failure — spurious parallelism, where the orchestrator spawns many subagents that do no meaningful work, gaming the parallelism bonus.

The reported deployment envelope is the part that makes this feel like a phase change rather than a refinement. The trained orchestrator self-directs a swarm of up to 100 subagents across as many as 1,500 coordinated steps without predefined roles or hand-crafted workflows, with an internal evaluation reporting an 80% reduction in end-to-end runtime on complex tasks. Subsequent product materials describe scaling further, to 300 subagents and 4,000 coordinated steps.

The academic side has been converging on the same problem from the other direction, with a cluster of methods jointly training multiple LLM policies under Dec-POMDP formulations — multi-agent variants of GRPO, debate-with-verified-rewards, meta-thinker/executor decompositions — and training infrastructure that combines centralised multi-agent interaction with distributed per-agent policy training and workflow-level reward allocation. The recurring theme across all of it is that credit assignment, not capability, is the binding constraint.

The advisor inversion

One more pattern deserves its own mention because it inverts the standard hierarchy. In the usual orchestrator-worker arrangement, a large model decomposes and delegates to smaller ones. The advisor pattern runs it backwards: a smaller, cheaper model executes the task end to end, and escalates to a frontier model only when it hits a decision it cannot resolve. The advisor never calls tools and never produces user-facing output; it returns a plan, a correction, or a stop signal, and the executor resumes.

Anthropic report that Sonnet with Opus as advisor scored 2.7 percentage points higher on SWE-bench Multilingual than Sonnet alone while reducing cost per agentic task by 11.9%, and that Haiku with an Opus advisor more than doubled its solo BrowseComp score, from 19.7% to 41.2%. Cognition, running the same idea under the name “smart friend,” found it works today when both models are strong, and that the version with a genuinely weaker primary — which would be the bigger unlock — is still open, because the hard part is a weaker model knowing when it is at its limits.

That difficulty is worth sitting with. In the standard hierarchy the smartest model makes the routing decision. In the advisor pattern the least smart model does. Routing quality is therefore capped by the executor, which is exactly the wrong model to cap it. Cognition’s read is that this is a training problem rather than a prompting one, and the interesting cross-frontier finding is that between two strong models the delegation logic stops being a difficulty escalator and becomes a capability router — some models debug better, some handle visual reasoning better, some write tests better.

How the field moved

Four generations, four distinct answers to the same question, each forced by a specific limitation of the one before.

2023 — role-play. CAMEL showed that two role-conditioned agents could sustain a task-oriented conversation without a human in the loop. AutoGen generalised this into programmable conversational orchestration. The limitation that forced the next step: free-form agent chat produced unpredictable, unterminating conversations and cascading errors.

2024 — structure and debate. MetaGPT encoded standard operating procedures into the workflow; ChatDev ran a software waterfall; multi-agent debate turned agents into independent critics. Meanwhile Mixture-of-Agents exploited cross-model complementarity. The limitation that forced the next step: compute-matched comparisons showed the gains were mostly bought with tokens, and the failure taxonomy showed the breakdowns were in the design rather than the models.

2025 — orchestrator-worker in production. The star topology with condensed returns, private contexts per subagent, and an explicit synthesis pass. Anthropic’s research system and Cognition’s read-only subagents are the reference points. The limitation that forced the next step: the topology was hand-written and static, and it did not extend to tasks big enough to need hundreds of agents.

2026 — learned orchestration and swarm infrastructure. Orchestrators trained with RL to decide decomposition and parallelism; planner/worker trees with purpose-built version control, reconcilers, review lenses, and agent-authored shared context. Kimi’s PARL and Cursor’s swarm are the reference points.

Read down the “2026” column and notice how little of it is about agents. Version control, reconcilers, review lenses, shared documents, learned budgets — the frontier is infrastructure. The agent count went up by two orders of magnitude and almost none of the difficulty was in the agents.

The economics changed too

One consequence of planner/worker separation is that you can put different models in different roles, and the cost structure comes apart from the token structure. In Cursor’s SQLite comparison, every model mix produced similar quality while total cost ranged from about $1,339 to $10,565. Workers carried at least 69% of the tokens and over 90% in most runs, but planner tokens cost far more, so in the frontier-planner-plus-efficient-worker mix the planner produced a small fraction of the tokens and roughly two-thirds of the cost.

The sharpest single comparison: where one frontier model did both jobs, the workers alone cost $9,373; where a frontier planner directed an efficient worker model, the entire worker fleet cost $411. The reasoning is that few moments in a large task genuinely require frontier intelligence — the original decomposition, the design decisions, certain trade-offs — and once a frontier planner has collapsed the ambiguity into an explicit instruction, cheaper models only have to follow it.

Lab: should you split this task?

Everything above reduces to a handful of quantities. This lab makes them tunable so you can find the boundary yourself.

The toy model composes the three effects we derived. Quality relative to a single agent is

\[ \frac{Q_{\text{MAS}}}{Q_{\text{SAS}}} \;\approx\; \underbrace{\frac{\eta(L/N)}{\eta(L)}}_{\text{context gain}} \;\times\; \underbrace{\frac{\rho p + (1-\rho)\Pr[\mathrm{Bin}(N,p) > N/2]}{p}}_{\text{ensemble gain, capped by }\rho} \;\times\; \underbrace{(1 - \delta)^{d}}_{\text{handoff loss}}, \]

where \(d\) is the number of handoffs on the critical path and \(\delta\) is the fraction of relevant information lost per handoff. Cost and wall-clock follow the models in §12 and §14. None of this is calibrated to anything; it is a way of holding four intuitions in one place and watching them fight.

Evaluating honestly

If you take one methodological point from this article, take this one: never compare \(N\) agents against 1 agent without matching compute. A four-agent system must be compared against

• one agent with 4× the thinking budget;
• self-consistency with \(K = 4\);
• best-of-4 with the same verifier the multi-agent system uses;
• one agent plus the same verifier, in a refinement loop;
• and a same-token-budget search baseline.

Nearly every reversal in this literature came from someone running one of those baselines properly. The audit of automatic multi-agent design frameworks found that across a stratified set of backbone models and hard benchmarks, automatically-designed systems rarely outperformed a strong single agent once cost and baseline strength were accounted for, and it identified two mechanisms for why the advantage erodes as models improve: signal saturation, where flattening accuracy gradients leave controllers without the signal they need to route, and positional and primacy biases in verifiers and controllers that favour early reasoning steps and effectively terminate the multi-agent benefit before interaction happens.

The second mechanism is the one to watch. It implies a moving target: a multi-agent architecture validated against a 2024 backbone may have no advantage against a 2026 one, not because the architecture got worse but because the baseline absorbed the gain.

Report, at minimum: task success, total tokens split by role, number of model calls, wall-clock, dollar cost, and communication overhead as a fraction of total tokens. A controlled 2026 evaluation of agent workflows under aligned execution found that fixed and evolving multi-agent systems do not consistently beat a matched single-agent anchor and occupy different accuracy-cost trade-offs — which is a more useful finding than a win or a loss, because it says the honest answer is a Pareto frontier rather than a ranking.

What is still open

Five things I do not think anyone has settled, stated as questions rather than positions.

Does the multi-agent advantage survive scaling? The signal-saturation finding suggests it shrinks as backbones improve. The swarm results suggest it grows as task horizons lengthen. Both can be true, and which dominates depends on whether context windows or task sizes grow faster. I do not know of a clean experiment that separates them.

Can a weak model learn when to escalate? The advisor pattern’s biggest potential unlock is a cheap executor that reliably knows its own limits. Cognition report this remains open and believe it is a training problem. If it is solved, the cost structure of agentic systems changes substantially; if it is not, the advisor pattern stays confined to pairings of already-strong models.

Is end-to-end multi-agent training worth it? The most successful published system deliberately freezes its subagents to avoid credit-assignment ambiguity. Academic work is pushing on joint optimisation with agent-wise advantage normalisation and workflow-level reward allocation. Whether joint training beats the decoupled shortcut at scale is genuinely unknown.

What is the right unit of communication? Everyone agrees full trajectories are too much and one-line summaries are too little. Nobody has a principled account of what belongs in a message. The Field Guide idea — agents curating shared context under a line budget for their successors — is the most interesting live experiment, and its authors flag training models to write for their successors as an open research direction.

How do you make a swarm feel coherent? Cursor’s SQLite result — passing a held-out suite with 4,645 lines where the previous harness needed 19,013 — suggests coherence is achievable. But that task had a crisp verifiable criterion. Real software requires scaling human taste, which is exactly the property that does not reduce to a test suite, and Cognition name making a delegating system feel as coherent as a single agent as the centre of their current work.

The compressed version

If you want a single decision rule, it is this. Add an agent when you can name which of three things it buys — a shorter context, a decorrelated check, or a cheaper token — and when you have measured that a compute-matched single agent does not already give you it. Otherwise you are buying coordination overhead and calling it collaboration.

The interesting future is almost certainly not more agents. It is adaptive orchestration: the right number of specialised policies, exchanging the right information, under a fixed compute budget, with the decision about all three learned rather than configured.

References

Grouped by the argument each source supports. Every entry links to its primary source.