When You Should NOT Use Sub-Agents

Sub-agents have become a reflex. Hard task? Spawn a fleet. Big codebase? Fan out. The multi-agent pattern is genuinely powerful — Anthropic reported a ~90% improvement over a single agent on their internal research evaluation — and that headline number has quietly turned "use sub-agents" into the default answer to every difficult problem. But the same engineering teams that built these systems are unusually blunt about where they backfire. The interesting question in 2026 isn't how to use sub-agents. It's knowing when not to.

This is a summary of where the recent guidance from Anthropic — their multi-agent research system and effective context engineering writeups — says you should keep the work inside a single agent. The patterns are consistent, and most of them come down to one idea: architecture has to follow task structure. When you impose a parallel structure on work that isn't parallel, you pay for it.

1. When the Task Doesn't Actually Decompose

The whole case for sub-agents rests on one assumption: the work splits into independent threads that can run without talking to each other. Research is the canonical fit — "find everything about X" naturally breaks into "explore angle A," "explore angle B," each in its own clean context window, each returning a condensed summary.

The trap is that most tasks aren't shaped like that. Anthropic's guidance is explicit:

"Some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today."

If sub-agent B needs to see what sub-agent A discovered before it can do its job, you don't have parallel work — you have sequential work wearing a parallel costume. Splitting it forces you to either serialize the agents anyway (losing the entire benefit) or run them blind and reconcile contradictory results afterward (adding a hard coordination problem you didn't have before). The decomposition test is simple: can each sub-agent succeed knowing nothing about what the others are doing? If the honest answer is no, don't split.

2. When the Task Is Cheap (The 15× Tax)

Sub-agents are not free, and the cost is not small. The numbers Anthropic published are the ones to internalize:

A single agent already uses about 4× more tokens than a plain chat interaction.
A multi-agent system uses about 15× more tokens than a chat.

That multiplier is the entire economic argument. As they put it:

"For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance."

This sets a floor. If the task is a quick lookup, a single-file edit, a format conversion, or anything you could plausibly do in one or two turns yourself, fanning out is pure waste — you're paying a 15× bill to make a $0.50 task cost $7.50, and often getting a worse answer because the work got chopped up and stitched back together for no reason. Sub-agents earn their multiplier only on tasks where the value is high and the token budget is genuinely worth spending. Most tasks aren't that.

3. When It's Coding, Not Research

This one surprises people, because coding agents are exactly where the fan-out reflex is strongest. But the guidance singles coding out directly:

"Most coding tasks involve fewer truly parallelizable tasks than research."

The reason is dependency density. In research, two facts about different subtopics rarely conflict. In code, everything touches everything: a change to a function signature ripples into its callers, a new field in a type propagates through every consumer, two agents editing "different" files can still produce an incoherent whole because the files share an interface contract that neither agent fully sees. The shared state that makes a codebase a codebase is exactly what sub-agents are bad at coordinating around.

There's a real exception, and it's worth naming: read-only, strictly-partitioned work fans out fine — "audit these 30 files for the same issue," "search the repo five different ways," "review each of these independent modules." The danger is parallel writes to interdependent code. When agents mutate a shared design at the same time, you get merge conflicts at best and silent incoherence at worst.

4. When Agents Would Need to Coordinate in Real Time

A subtle limit, and an honest one from the people building these systems:

"LLM agents are not yet great at coordinating and delegating to other agents in real time."

The clean multi-agent pattern is fire-and-forget: the lead agent dispatches sub-agents, they go off and work in isolation, they each return a tidy 1,000–2,000 token summary, and the lead reconciles. That works precisely because there's no live back-and-forth. The moment your task needs agents to negotiate mid-flight — "wait, you take that part, I'll adjust" — you're asking them to do the thing they're currently worst at. Tasks that require continuous mutual adjustment belong in one agent's head, where "coordination" is just sequential reasoning instead of an inter-process protocol.

5. When Information Gets Lost in the Hand-Off

The mechanism that makes sub-agents scale is also their biggest information risk. Each one "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000–2,000 tokens)." That compression is a feature — it keeps the lead agent's context clean — but it's lossy by design.

If your task depends on nuance that doesn't survive a summary — exact quotes, precise numbers, the specific shape of an edge case, the full reasoning chain behind a decision — then the hand-off boundary is where that nuance dies. Anthropic describes the related failure as a "game of telephone": information gets condensed and re-summarized through several iterations until the fidelity is gone. When the task is about the details, keep it in one context window where nothing has to be distilled to cross a boundary.

The Failure Mode to Fear: 50 Sub-Agents for a Simple Query

Early in development, Anthropic's own system did exactly the thing the rest of us now do by default — it would "spawn 50 sub-agents for simple queries," hunting for sources that didn't exist and burning tokens on coordination overhead. Agent proliferation has a way of feeling like progress: more agents looks like more work getting done. It usually isn't. Past a point, each additional agent adds coordination cost faster than it adds capability, and a swarm on a simple task is slower, pricier, and less coherent than one agent doing the obvious thing.

A Practical Heuristic

Before reaching for sub-agents, run the task through four questions. Reach for a fleet only if you can answer yes to all four:

Does it genuinely decompose? Can each piece succeed in isolation, knowing nothing about the others? If pieces depend on each other → single agent.
Is it worth the 15× tokens? Is the task valuable enough to justify the multiplier? If it's cheap or quick → single agent.
Is it more research than construction? Parallel exploration of independent information → fan out. Editing interdependent code or building one coherent artifact → single agent (or read-only fan-out at most).
Does the work survive compression? If the answer needs full-fidelity detail that a 2,000-token summary would destroy → single agent.

Sub-agents are a scaling tool for a specific shape of problem: high-value work that splits into independent, parallel exploration, with too much information for one context window and no tight dependencies between the threads. That's a real and important category — but it's a minority of the work most of us actually do. For everything else, the boring answer is still the right one. One capable agent, in one clean context window, finishing the job without a committee.