More agents,
more problems.

The appeal of multi-agent systems is intuitive: decompose a hard task, assign each part to a specialist agent, run them in parallel, combine the results. It mirrors how human teams tackle big problems, and it promises both parallelism (do things at once) and specialization (each agent focused on what it's good at). So a lot of ambitious AI systems are built as elaborate agent org-charts.

And often they underperform a single well-built agent. The failure isn't that the agents are bad — it's that coordinating them costs more than anyone budgeted. Agents have to share context, reconcile conflicting results, wait on each other, and recover when one goes off-track, and all of that is overhead that a single agent simply doesn't pay. The question isn't "would a team be nice?" but "does the parallel benefit exceed the coordination cost?" — and the coordination cost has a shape that makes the answer "no" more often than you'd think.

Here's the cost nobody prices in. When agents must coordinate, the work isn't just "N agents doing their bit" — it's the communication between them. Every pair of agents that needs to share context or reconcile a result is a coordination link, and the number of pairs in a group of N is N(N−1)/2 — it grows quadratically. Two agents: 1 link. Five agents: 10 links. Ten agents: 45 links. The overhead explodes far faster than the headcount.

Meanwhile the useful work only divides linearly: split a job across N agents and each does about 1/N of it. So you're trading a linear speedup against a quadratic overhead. For small N the speedup wins; as N grows, the quadratic term catches up and then overwhelms it. This is the same reason human teams hit diminishing returns — adding people adds meetings faster than it adds output. A single agent, by contrast, has zero coordination overhead, which is why it's such a strong baseline and so often the right default.

Put the two forces together and you get a U-shaped cost curve. Total cost falls at first as agents parallelize the work, hits a minimum at some optimal number, then rises as coordination overtakes the shrinking marginal speedup. There's a best N — and it's usually small.

Where the minimum sits depends on two things: how parallelizable the task is (more independent work → more agents pay off) and how expensive coordination is (cheaper coordination → more agents optimal). A tightly-coupled task where every step depends on the last has almost no parallelism, so its optimal N is 1 — a single agent. A task that fans out into many independent sub-tasks with light coordination can profitably use several. The math pins down exactly where.

Model total cost as parallelized work plus pairwise coordination. Work W divides across N agents; coordination costs c per pair, and there are N(N−1)/2 pairs:

First term (work) shrinks like 1/N; second (coordination) grows like N². Their sum is a U-curve with a minimum.

Two consequences fall out. Adding agents past the minimum makes it worse — the quadratic term wins — and the optimal N depends on the ratio of work to coordination cost:

Halve the coordination cost and more agents pay off; make it expensive and a single agent wins. The runnable version below computes the cost curve, shows more agents hurting past the optimum, and finds the best N.

The way to beat the quadratic wall is to constrain who coordinates with whom. The best patterns route coordination through a hub or a line instead of a full mesh:

Orchestrator-workers is the workhorse: because the coordinator is the only hub, communication grows with the number of workers, not with the number of pairs, keeping overhead near-linear even as you add specialists. It also composes with everything else — each worker is itself a bounded agent loop, and the orchestrator applies the same agent patterns at the team level. The design lesson is blunt: don't build a democracy of agents that all confer; build a clear hierarchy or pipeline where coordination is deliberately limited, and add agents only where you can point to real parallel work.

The cardinal error is reaching for multi-agent by default — building an agent team for a task a single agent handles fine, and paying the coordination tax for nothing. Start with one agent; add more only when you can name the specific parallelism that will pay for the coordination. A close cousin is the full-mesh design where every agent talks to every other: it hits the quadratic wall fastest, and it's usually a hierarchy or pipeline in disguise that just hasn't been structured yet.

Two more. Error compounding: each agent hand-off is a chance to lose context or propagate a mistake, so a longer chain of agents is a longer chain of failure points — more agents can mean lower reliability, not just higher cost. And context duplication: agents that each carry the full context multiply your token bill, so coordination overhead is a cost line too, not only a latency one. The through-line: multi-agent is a real tool for genuinely parallel, specialized work — but it is not a free upgrade. Respect the quadratic, keep the team small and the coordination structured, and default to one agent until the task demands more.