Multi-agent systems are supposed to be smarter than single agents. That’s the whole pitch: break a problem into specialists, hand them off to each other, let the collective reasoning do what one model can’t. It sounds like the obvious next step, and for the last eighteen months “more agents” has been the default answer most enterprise teams have reached for.

When you actually equalise the compute, it stops being true.

New Stanford research from Dat Tran and Douwe Kiela ran the comparison properly. They put single-agent and multi-agent systems on the same multi-hop reasoning tasks and gave them the same “thinking token” budget, meaning the same number of tokens for intermediate reasoning, not just the same final output. Under those conditions, the single agent matched or beat the swarm in most cases. The multi-agent setups had been winning because they were quietly spending more compute, not because they were thinking better. Tran and Kiela call the gap the swarm tax: the premium enterprises pay for an architecture whose apparent advantage is mostly a billing artefact.

That finding deserves to land, because right now the industry is making a lot of expensive decisions on the opposite assumption.

More agents has become the new "more meetings"

Look at how teams talk about agent design in 2026 and you'll hear the same vocabulary you used to hear about org charts. We need a planner agent, a researcher agent, a critic agent, a synthesiser agent. We'll add a verifier. We should have one that handles edge cases. By the time the architecture diagram is done, the system has eight boxes, twelve arrows, and a confidence that nobody has actually questioned. (I've written before about how most businesses think their agentic AI is more sophisticated than it really is; the swarm-shaped architecture diagram is one of the ways that self-flattery shows up.)

Why do those boxes get drawn in the first place? Mostly because more agents feels like more rigour. It looks more thought-through. It photographs better in a board deck. And until Stanford ran the equal-budget test, there wasn’t a clean way to call it out.

This is the same dynamic that produces standing meetings nobody questions, sign-off processes with seven approvers, and project plans with a workstream for everything. The structure is treated as evidence of seriousness. The cost of running the structure becomes invisible because everyone’s busy admiring the structure.

The Stanford paper is doing for agent architecture what a good time-and-motion study does for a process. It strips the theatre off and asks what the work actually is. The answer, most of the time, is that a single agent given enough room to think is doing the work, and the second, third, fourth agents are passing notes about it.

What's actually going on under the hood

The technical explanation is satisfying because it's so unsexy. Tran and Kiela point to something called the data processing inequality, a principle from information theory that says every time you summarise information and hand it to someone else, you lose some of it. You can't recover what you stripped out in the handoff.

A swarm is exactly that, repeatedly. Agent one reasons over the full context, summarises its conclusion, and hands it to agent two. Agent two reasons over the summary (not the original), summarises again, and passes it on. By the time the chain reaches the synthesiser, the richest information has been compressed two or three times. Each handoff is a small, invisible tax on what the system can actually know.

A single agent reasoning inside one continuous context window never pays that tax. It has the whole problem in front of it, the whole time. Tran and Kiela also noticed that the single agents in their tests were often stopping early, leaving compute budget on the table, so they added a simple prompt tweak (they call it SAS-L) that nudges the model to use what it’s got. With that one change, the single-agent setup was the strongest default for the multi-hop reasoning they tested.

The architectural punchline is anticlimactic. What beats the swarm on these reasoning tasks is the single agent given enough room to think.

Where the swarm tax meets the tokenmaxx

Timing matters, because the Stanford paper lands in the middle of a separate, weirder trend. The same week the research went out, 404 Media ran a story on "tokenmaxxing": founders publicly bragging about how much they spend on AI compute. The viral example was a four-person coding-agent startup celebrating a $113,000 monthly Claude bill on LinkedIn as proof of seriousness, alongside similar stories about Meta running an internal employee leaderboard called Claudenomics.

If you’re a CTO watching your AI line item climb, this is your real problem. Tokenmaxx culture treats compute spend as a signal of being a real AI-native company. Multi-agent culture treats agent count as a signal of architectural sophistication. Both treat the input as a stand-in for the output, and both eat your margin while nobody on the team is asked to show that the next dollar of compute, or the next agent in the chain, is doing any actual work.

Salesforce has clocked the same drift from inside the tent. Agentforce Vibes 2.0, the version they shipped at TDX in April, is explicitly designed to handle “context overload” — agents being handed so much information they start drowning in it — and they’ve invented a metric called Agentic Work Units to try to ground all that token spend in something resembling output. Translate that back into the swarm-tax framing and it says: even the platform vendors are admitting, in product form, that pouring more context and more agents at a problem isn’t free.

How far the Stanford result generalises beyond multi-hop reasoning is the open question. For long-running tool-using agents that run for hours in production, we genuinely don’t know yet whether the same maths holds. The safe move is to assume it usually does, default single-agent first, and only spend the architecture budget on a swarm when you can name what it’s solving. That flips the burden of proof. Until recently it sat on the engineer who wanted to use a single agent. Now it sits on the one who wants to use a swarm.

What this means if you're actually building something

The Stanford result isn't a blanket ban on multi-agent systems. The paper is careful: swarms genuinely do help when a single agent's context gets messy, meaning long noisy inputs with distractors, corrupted data, situations where you need structured filtering and decomposition that a single model can't reliably do in one pass. That's a real use case. It just isn't most of them.

For everyone else, three things follow.

  1. Start single, prove the need, then add agents. Default to one agent with a generous thinking budget. Only add a second when you can name the specific bottleneck (context fragmentation, a degraded input, a verification step that genuinely needs an independent pass) that the extra agent solves. "It feels safer" doesn't count.
  2. Stop accepting token spend as proof of intelligence. Per-agent token counts, per-employee leaderboards, monthly Claude bills celebrated on LinkedIn: these tell you what something cost, not what it produced. If your AI ops dashboard tracks spend without tracking equivalent output, you've built a Claudenomics, not a measurement system. Salesforce's instinct to invent a unit of work was right, even if the unit they picked is rough.
  3. Treat agent architecture like any other engineering choice. Every architecture decision has a cost, a benefit, and a counterfactual. Multi-agent systems should have to clear the same bar as a new microservice: what does this give us that we couldn't get more simply, and what does it cost us to run? Right now they're being added the way committees get formed, because the meeting felt incomplete without one.

The discipline that's coming

AI ops is about to go through the same shift cloud spending went through around 2017. Think of the founder who realised one morning that her AWS bill was eating the engineering budget, hired a single rigorous FinOps engineer, had them go through the invoice line by line, and discovered she was paying for orphaned dev instances and idle GPU boxes nobody had touched in months. That moment — when someone is finally allowed to ask "do we actually need this?" of every line — is what turns agentic loops from clever demos into something you can actually run a business on.

Single-versus-multi-agent looks like the first big test case for that shift. The Stanford paper has given engineering teams a baseline that costs nothing to apply (try the single agent with enough thinking room, only step up if you hit a wall) and saves real money the moment they do. In a market where token costs are still being subsidised by investor capital and frontier labs are running at a loss, the people who learn to ask “do we actually need this second agent?” are going to look very clever, very fast.

The first AI ops discipline of this cycle isn’t building bigger swarms. It’s having the engineering self-confidence to take one out.

Quick answers

When is a multi-agent system actually the right call? When a single agent's context genuinely can't cope with the task: long noisy inputs full of distractors, degraded data, or workflows that need an independent verification pass. The Stanford paper is explicit that these are real cases. Its argument is that they aren't most cases, and the industry has been defaulting the wrong way.

What’s the smallest thing to try before reaching for more agents? Tran and Kiela’s SAS-L approach. Rewrite the prompt so the model is explicitly encouraged to use its full reasoning budget on pre-answer analysis (list interpretations, test alternatives, identify ambiguities) before committing. In their tests that one change often closed the gap with multi-agent setups without adding any architecture at all.