Anthropic Says Build Manager Agents. Cognition Says Don't. Pick One.

Every AI Twitter feed this week is telling you to build a "manager agent" — one lead LLM that spawns three or five specialist subagents to knock out a task in parallel. It sounds great. It's also the fastest way I've seen to 15x your token bill on a workflow you could have run with a single prompt.

Two of the most credible teams in AI publicly disagree on whether you should build this at all. Anthropic — the people who make Claude — published a detailed blueprint showing their multi-agent Research system beat a single Claude Opus 4 by 90.2% on complex research tasks^[1]. Cognition — the people who built Devin, one of the best-known autonomous coding agents — published a piece two days later titled, literally, "Don't Build Multi-Agents"^[2]. Same industry. Same month. Opposite advice.

For most operators reading this, one of those two teams is right for your use case and the other is wrong. If you pick the wrong one, you'll spend $8,000 on API bills next month for a task that should have cost $500.

Here's the split.

What "manager agent" actually means

The pattern is simple to describe. A lead agent (call it the "orchestrator" or "supervisor") reads the user's request, decides how to break it up, and spawns two to ten subagents that each work on a chunk in parallel. When the subagents come back, the lead synthesizes their outputs into one answer. LangGraph and every other serious agent framework now ship a version of this as the default template for anyone starting a multi-agent build^[3].

Anthropic showed this working. Their orchestrator-worker system uses Claude Opus 4 as the lead and Claude Sonnet 4 as the workers. On BrowseComp, an evaluation that tests how well a system can locate hard-to-find information online, Anthropic's own analysis found that three factors — token budget, tool call count, and model choice — explained 95% of the performance variance^[1]. In plain English: the multi-agent system wins mainly because it burns more tokens, not because it's cleverer.

Anthropic reports the setup uses roughly 15x the tokens of a normal chat interaction^[1]. A single agent already burns about 4x a chat turn. Stack the orchestrator on top and you're at 15x. That's not a rounding error — that's the difference between a $2K/month invoice and a $30K/month invoice for the same category of task.

Cognition's counter

Cognition's argument, buried in a post that's been quietly circulated in every serious agent-building Slack for the last six weeks: multi-agent systems break because subagents don't share context^[2]. One subagent decides "the goal is to make this file lightweight." Another subagent, working in parallel with no memory of the first's choices, does the opposite. The orchestrator gets two conflicting outputs and has to reconcile — badly.

Cognition's two principles, restated: (1) share context across the whole trace, and (2) every action carries implicit decisions from earlier actions^[2]. Multi-agent architectures violate both by default. So Cognition builds single-threaded linear agents. Devin, one of the most-used autonomous coding agents in production, runs as one agent, not a swarm.

They're not saying multi-agents can't work. They're saying that in 2026, the coordination overhead is worse than the parallelism win for most tasks — and the failure modes are much harder to debug.

Who's right for your business

Both are right — for different problems. Here's how I sort it, and how I'd sort it for anyone running a real business rather than a research org.

Use a multi-agent supervisor pattern if:

• The task is read-heavy and highly parallelizable with no shared state between subtasks. Research, competitive intel gathering, and codebase-wide search all fit. Anthropic's Research feature works because "find board members of every S&P 500 IT company" trivially splits into 68 independent lookups^[1].
• The output value is 10x+ the token cost. Deep research reports where a good answer justifies a $50 API run — sure. Customer support chat where every message needs to be under 3 cents — never.
• You have engineers to build eval pipelines. Anthropic's team spent weeks watching agents fail in simulations and rewriting delegation prompts to fix specific failure modes^[4]. If you don't have that budget, don't build this.

Stick with a single-threaded agent if:

• The task is write-heavy, has shared state, or requires memory of earlier decisions. Any coding task, any sales workflow, any customer conversation. This is 90% of what a $5M business actually needs.
• You want to debug it in production. Single agent = one trace, one context window, one place to look when it breaks. Multi-agent = five parallel traces that all diverged, and no clean way to reproduce a failure.
• You care about token cost per unit of value. Cheap, fast, boring. This wins most of the time.

Gartner is now forecasting that over 40% of agentic AI projects will be canceled by the end of 2027, blaming escalating costs, unclear business value, and inadequate risk controls^[5]. The ones that ship are almost always the boring linear pipelines. The ones that die are almost always the ambitious orchestrator-worker demos that impressed a VP in a meeting.

The pattern I actually use

For every AI system I build for a business, the default is a single agent with tools. I add a second agent only when I can point at a specific piece of the workflow where the tasks are (a) independent, (b) parallelizable, and (c) worth the tokens.

Even then I don't call it "multi-agent." I call it "one agent that fans out one specific step." That framing forces you to justify the fanout each time, instead of drifting into an architecture where you have five agents talking to each other because a Twitter thread told you to.

If your agent bill went up 5x last month and the outputs aren't measurably better, this is why. Somewhere in your build, a subagent is spawning a subagent that's summarizing a subagent. Cut it. Go linear. Ship.

What to check today

Three things any operator can do this week if they're already running an agent stack:

1. Look at your last 100 agent runs. How many spawned subagents? What was the average token count vs. a single-agent version of the same task? If the ratio is >5x and quality is the same, refactor to linear.
2. Find your longest trace. Read it end-to-end. If two subagents made contradictory decisions and the lead had to paper over them, that's the Cognition failure mode. Fix it by collapsing the branches into one agent with a longer context window.
3. Set a token budget per task. Not per month — per task. If any single user request costs more than $2 in tokens, get an alert. That's how you catch the 15x-blowup before the invoice lands.

Multi-agent architectures aren't wrong. They're just wrong for most businesses, most of the time. The teams that ship them successfully — Anthropic, Perplexity, the labs building deep research products — have full-time engineers running evals every week. If that's not you, build linear and win boring.

I audit AI agent stacks for operators running $1M–$20M businesses who suspect their build is over-engineered. If you want a 30-minute look at yours before your next invoice, that's what the free audit call is for.

Sources 5 references

1. 1
   How we built our multi-agent research system

   Anthropicprimary

   Multi-agent research system outperforms single Claude Opus 4 by 90.2% on internal evals; uses ~15x the tokens of chat; token/tool/model factors explain 95% of BrowseComp variance.

   ↩
2. 2
   Don't Build Multi-Agents

   Cognitionanalysis

   Multi-agent systems fail because subagents don't share context; two principles: share full context, every action carries implicit prior decisions.

   ↩
3. 3
   LangGraph: Agent Orchestration Framework

   LangChaindocs

   LangGraph ships the supervisor/orchestrator pattern as a default template for multi-agent builds.

   ↩
4. 4
   Anthropic: How we built our multi-agent research system (notes)

   Simon Willisonanalysis

   Anthropic's team spent weeks watching agents fail in simulations and rewriting delegation prompts; early agents spawned 50 subagents for simple queries.

   ↩
5. 5
   Why 40% Of Agentic AI Projects May Be Canceled By 2027

   Forbesnews

   Gartner forecast: over 40% of agentic AI projects will be canceled by end of 2027 due to escalating costs, unclear business value, and inadequate risk controls.

   ↩