blog

One Agent or Many? How to Decide Between Single and Multi-Agent

August 3, 2026 · #ai #agents #multi-agent #architecture #orchestration #llm

In June 2025, two of the sharpest engineering teams in AI published advice that sounds like a flat contradiction, in the same month.

Cognition put out a post titled, bluntly, “Don’t Build Multi-Agents.” Anthropic put out one titled “How we built our multi-agent research system,” in which their multi-agent setup beat a single agent by over 90% on their internal research benchmark.

So which is it? Build multi-agents or don’t?

The answer, and the reason this is worth a whole post, is that they’re both right. They’re describing different tasks. The space between their two conclusions is exactly the decision you have to make every time you design an agentic system: one agent, or several? Get it right and you ship something fast, cheap, and debuggable. Get it wrong in the fashionable direction and you ship something that costs ten times as much and breaks in ways you can’t trace.

Let me lay out what each architecture actually is, the shapes multi-agent comes in, the honest costs, and a framework for choosing.

What they actually are

If you’ve read what an agent really is, the single-agent picture is familiar: one model in a loop. It gets a task, reasons, calls a tool, reads the result, and repeats until done. One context window holding everything it’s seen, one set of tools, one thread of control. Every decision is made by the same model with full view of everything.

A multi-agent system splits that up. Several LLM instances, usually specialized, each often with its own context window, its own role, its own subset of tools, coordinated by some mechanism: a lead agent that delegates, a fixed pipeline, a shared message channel, or direct handoffs between peers.

Single agent

agent tool tool

One model, one context, one control loop. It sees everything it has done. Simple, cheap, deterministic-ish, easy to debug.

Multi-agent

lead a1 a2 a3

Several specialized models, each with its own context and tools, coordinated. More capable on the right task, and far more moving parts.

The difference isn't "smarter." It's how many context windows, how many decision-makers, and how many LLM calls. That shift is what buys you capability and what costs you money and simplicity.

One thing to note before going further: this is generative-AI, LLM-agent territory. It has nothing to do with classical multi-agent reinforcement learning, which shares the name and none of the design questions.

The shapes multi-agent comes in

“Multi-agent” isn’t one thing. When you do decide to use several agents, you’re picking a topology, and they’re not interchangeable. These names are broadly consistent across LangGraph, Google’s ADK, Microsoft’s Agent Framework, and AWS Bedrock.

Supervisor
A lead agent breaks up the task, delegates to workers, and synthesizes their answers. The most common production pattern.
Pipeline
Agents run in a fixed order, each consuming the last one's output. For known, ordered stages. The order is code, not a guess.
Parallel
Agents work concurrently on independent pieces, results merged. For genuinely decomposable tasks, cuts wall-clock time.
Network / swarm
Peers hand control directly to each other, no boss. For flexible flows where the next specialist depends on what just happened.
Hierarchical
Supervisors managing supervisors. For big problems that split into sub-domains, each needing its own decomposition.
Reflection / debate
One agent drafts, another critiques, they loop until it's good. For quality over speed: code review, drafting with a validator.
Six patterns. Most production multi-agent systems are a supervisor delegating to workers. Pipeline and parallel are often better built as deterministic code (the order is yours, not the model's) rather than "true" agents making routing decisions.

The debate, and why both sides are right

Now back to those two posts, because reading them together is the whole lesson.

"Don't build multi-agents"
Cognition (Walden Yan), June 2025
Default to a single, linear agent.
When parallel agents can't see what the others are doing, they make conflicting assumptions and the whole thing gets fragile. Their case: coding. Two subagents building different parts of one app produce pieces that don't fit together, because each guessed at the shared decisions the other made.
"We built one, it won by 90%"
Anthropic, June 2025
Multi-agent, for the right task.
Their orchestrator-worker research system (a lead plus subagents) beat single-agent by 90.2% on their internal eval. Their case: research. Breadth-first questions where independent subagents each chase a separate lead in parallel, then the lead synthesizes.
Not a contradiction. Cognition's task is tightly-coupled writing with shared state (coding). Anthropic's is parallel, read-heavy exploration (research). The deciding variable is whether your task actually splits into independent pieces.

That’s the reconciliation, and it’s the single most useful idea here. Anthropic themselves say it plainly: their approach fits “heavy parallelization” and work that “exceeds single context windows,” and it does not fit “domains that require all agents to share the same context or involve many dependencies between agents.” They even note most coding tasks have fewer truly parallel pieces than research. Cognition and Anthropic aren’t arguing. They’re pointing at different tasks and giving the correct answer for each.

The part nobody puts on the slide: cost

Here’s why the default should be single-agent, and why “let’s use agents for everything” is an expensive habit. Multi-agent buys capability with tokens, a lot of them. Anthropic measured it.

Plain chat
1x
Single agent
~4x tokens
Multi-agent
~15x tokens
token use vs a plain chat interaction, per Anthropic's engineering post

An agent already uses roughly 4x the tokens of a plain chat, because it loops and accumulates context. A multi-agent system uses about 15x. And in their evaluation, token usage alone explained about 80% of the performance variance, which means the capability gain is largely something you’re paying for in tokens, not getting for free. Their own honest caveat: multi-agent only pays off “when the value of the task is high enough to pay for the increased performance.”

On top of the token bill, you get coordination latency (the lead has to plan, delegate, and synthesize, each an extra call), compounding errors across agents, and a system that’s genuinely harder to debug because the failure might be in any of several models or in how they talked to each other.

Single vs multi, side by side

DimensionSingle agentMulti-agent
Cost~4x chat~15x chat
LatencyLowerHigher (coordination)
DebuggabilityOne trace to readMany traces, plus their interaction
Shared contextTotal, sees everythingSplit, agents can conflict
ParallelismNoneReal, on decomposable tasks
Context limitOne windowScales past one window
Best fitSequential, coupled, codingParallel, read-heavy, research
Single-agent wins on almost every operational axis. Multi-agent wins on capability for a specific task shape. That asymmetry is why single should be your default and multi should be a decision you justify.

The decision, as questions

You don’t choose by vibe or by what’s trending. You choose by answering a few honest questions about the task. If you’re saying “single” to most of these, build one good agent with good tools and stop there.

multiDoes the task split into genuinely independent subtasks? If pieces can run without knowing what the others are doing, parallel agents pay off. If they're tightly coupled, they'll conflict.
multiDo subtasks need different tools or different specialized context? A researcher and a code-runner wanting totally different context is a real reason to separate them.
multiDoes the work exceed one context window? If no single agent can hold it all, splitting the context across agents is a legitimate fix.
singleDo later steps depend heavily on earlier ones? Tight coupling and shared state mean one agent that sees everything beats several that each see a slice.
singleDo cost, latency, or debuggability matter more than raw capability? Then eat a little less capability for a system you can afford and actually fix.
A rough rule: start single. Go multi only when the task is genuinely parallel, high-value enough to justify 15x tokens, and would otherwise overflow one agent's context. When in doubt, better tools on one agent beats more agents.

The takeaway

Multi-agent is not the advanced version of single-agent. It’s a different trade: you spend an order of magnitude more tokens and a lot of simplicity to buy parallelism and specialized context, and that trade is only worth it when the task actually decomposes and is valuable enough to justify the bill.

The reason so many multi-agent projects disappoint is that they were built for tasks that were really sequential and coupled, where a single agent with a good toolset would have been cheaper, faster, and easier to debug. The reason Anthropic’s worked is that research genuinely fans out into independent threads. The reason Cognition warned against it is that coding genuinely doesn’t.

So the honest default is one agent. Give it good tools, good context, and the discipline from the agent design post. Reach for many only when you can look at your task and say, truthfully, “this splits into parallel pieces that don’t need to watch each other.” If you can’t say that, you don’t have a multi-agent problem. You have a single agent that needs better tools.

Foundations for this post: what an agent really is, how AI agents actually work, and LangGraph for building the graphs these topologies run on.

References

Written from scratch. These are the primary, verified sources, including the two posts that frame the debate and the cost numbers. Nothing here is copied from them.

← Back to blog