Every multi-agent demo you’ve seen on YouTube looks like a company. A researcher agent, a writer agent, a finance agent, a social-media agent, all chattering away in their own little Slack channels, and a narrator saying “watch them collaborate.” It looks like the future. It looks like leverage.

I built a multi-agent system over a few days, and I landed on two agents. Not five, not seven. Two. Here’s the reasoning, because it went against my own instinct, and the research turned out to back the instinct rather than the demos.

What I actually built

The system is a Telegram room where two bots talk to each other and to me. One drafts — research, analysis, writing. The other guards: it holds my standards and my voice, and it challenges the first one’s work before anything reaches me. They run on different models on purpose. Nothing gets delivered to my inbox until the guardian signs off, and even then it lands as a draft for my review, never as an action taken on my behalf.

That’s it. Two agents, one drafter, one challenger, different models, human at the gate.

The obvious next move was to add specialists. A finance agent for my trading analysis. A writing agent for the Substack. A social agent for LinkedIn. Give each one a domain and a persona and let them collaborate. That’s the model every tutorial pushes. I didn’t do it, and I want to explain why, because the reason is not “I ran out of time.”

The case for more agents is real, but narrow

I’ll be fair to the other side, because there is a real case and it comes with hard numbers.

Anthropic’s own research feature spawns three to five subagents in parallel, and on their internal evaluation it beat a single agent by 90.2%. That’s not a rounding error. But read the second number: it cost roughly 15 times the tokens of a normal chat. And read their explanation of why it worked — their analysis found that token usage alone explained 80% of the performance variance. The multi-agent system won mainly because it spent more compute, spread across separate context windows, on a problem too big for one window.

That’s the honest case for more agents, and it has one shape: the task genuinely exceeds what one agent can hold. A research question that needs forty sources explored at once, where the total information won’t fit in a single context window. Split that across parallel agents, each holding a slice, and you get a real win. It’s a capacity argument, not an expertise argument.

Notice what that case is not. It’s not “I need a finance expert and a writing expert.” It’s “this one task is too big for one context, so I’ll parallelise it.”

The case against, which is most cases

Now the other side of the ledger, which the demos never show you.

A group at Berkeley catalogued why multi-agent systems fail — 1,600-plus annotated failure traces across seven frameworks — and found fourteen distinct failure modes, clustered into design problems, agents misunderstanding each other, and verification breaking down. Every agent you add multiplies that surface. I spent most of my build time killing coordination bugs with two agents. I could feel what four would have cost.

Then there’s the finding that actually changed my mind. A 2025 paper asked whether multi-agent “debate” is genuine deliberation or just a fancy way of averaging answers. The uncomfortable result: agents under group pressure conform. They drift toward consensus rather than holding independent positions. The debate becomes theatre — everyone agreeing to converge. Which means adding a third and fourth agent to “get more perspectives” can quietly give you fewer, because they start agreeing with each other instead of challenging.

And the cleanest result of all: a paper from 2025 showed that under an equal thinking-token budget, single agents matched or beat multi-agent systems on multi-hop reasoning across several model families. Their conclusion was blunt — a lot of the reported multi-agent advantage is better explained by unaccounted compute and context effects than by the architecture itself. In plain terms: the multi-agent system wasn’t smarter, it was just spending more. Give one agent the same budget and it does as well.

Where that left me

Put those together and a pattern falls out.

The one multi-agent structure with a solid basis is cross-model verification: a drafter proposes, and an independent challenger on a different model catches the errors the drafter’s own training is blind to. Different model families fail in different places, so one genuinely sees what the other misses. That’s not persona role-play. That’s structural.

That’s the two-agent shape I built. The drafter and the guardian. And a third agent doesn’t add a new kind of value to it — a “finance agent” is the same model doing finance-flavoured reasoning that my drafter already does when I ask it to reason about finance. A persona is a prompt. It isn’t a new capability. What the third agent does reliably add is coordination cost, the conformity pressure that weakens challenge, and more surface for the fourteen failure modes.

So I made the drafter more capable instead of adding more agents. Give it real tools — web search, the ability to produce a formatted document — and it covers the domains a swarm of personas would have, without the coordination tax. Capability lives in tools. Judgment lives in the two-agent challenge. Neither needs a bigger org chart.

When I’ll actually add a third

I’m not against ever adding an agent. I’m against adding one for the wrong reason. A new agent has to earn its place by clearing a wall the current pair genuinely can’t, and there are only three walls that count:

Capacity. A task that overflows one context window — the Anthropic case. Forty sources at once, a document set too large to hold. Then parallel agents each carrying a slice is a real win, and it’s about capacity, not smarts.

Permission boundary. A domain that needs tools I deliberately want quarantined. My trading system is the plausible one: live market data and trade-preflight access that I want nowhere near my general drafting agent. That’s a least-privilege argument — a security boundary drawn with an agent, not a capability I lacked.

Reactive mode. A standing job that watches something continuously — an inbox triage that runs on its own rather than waiting to be called. That’s a different mode of operation, not a smarter agent.

None of those is “I need an expert for each topic.” Expertise is a prompt my drafter already wears on request. The walls that justify an agent are structural: too big to hold, needs quarantining, or needs to run on its own. When I hit one of those, I’ll add the agent that clears it — and only that one.

The actual lesson

The swarm demos are compelling because they look like an organisation, and an organisation feels like power. But the research is fairly consistent: past the point where a task genuinely needs parallel capacity, more agents mostly buy you coordination failures and a larger token bill, while the conformity effect quietly erodes the very challenge you added them to get.

The thing that actually works — an independent challenger on a different model, holding the line before anything reaches you — needs exactly two. I built the team I could keep honest, made it more capable with tools, and left the org chart alone. It runs on one message from me and delivers work I’d put my name to.

Two agents. Different models. One challenges the other. A human at the gate. Everything else was going to be theatre, and I’d have paid for the tickets in tokens and bugs.