How to decide when a task needs its own agent

This is written for Claude Code, where spawning a subagent is a first-class move. The economics generalise, but the specifics are Claude's.

For a few weeks I spawned a subagent for almost everything. Reading a file, checking a research index, summarising a pull request. It felt like the more agentic way to work. Most of the time it was the wrong call, and it cost more for worse results.

Here's the point up front, because it's the whole article: a subagent is a tool for a specific shape of problem, not a default way to work. Start with the simplest thing that works, one continuous session, and only reach for a fresh agent when the task actually earns it. Anthropic's own guidance says the same thing about agents in general: "find the simplest solution possible, and only increase complexity when needed." Below is how I decide where that line is.

What a subagent actually is, and what it costs

A subagent is a fresh instance of the model with its own separate memory. It doesn't inherit your conversation, your project instructions, or anything you've already worked out. You hand it a task, it goes and does that task in its own window, and it hands you back a summary. Then it's gone.

That isolation is the entire point when you want it, and the entire cost when you don't. The upside: the subagent's work, all the file contents and logs and dead ends, never clutters your main session, and it can't be biased by what you were already thinking. The downside: it starts from nothing, so it has to re-gather everything the main session already knew before it can even begin.

So the test is simple. Spawn a subagent when keeping all the intermediate detail in your main session would cost you more than sending a fresh agent to go and re-gather it. That's the whole decision. Most single file reads, most quick edits, most things you can finish in a couple of steps, fail that test on sight, because a fresh instance would have to rebuild context the main session already has. You'd pay twice to do the thing once.

Route the model, don't default it

The cost lever most people miss is which model runs the agent, not whether to spawn one. Every subagent is a chance to pick the cheapest model that can do the job, and most tasks don't need your most expensive one.

The rule I follow now:

• Haiku for fast, read-only, exploratory work: searching, reading, summarising. Claude Code's own built-in Explore agent runs on Haiku for exactly this reason.
• Sonnet as the default for real work: writing code, coordinating a multi-step task.
• Opus only for reasoning that genuinely needs the strongest model.

For a while I ran every subagent on whatever model I happened to have the parent session set to. That's not a decision, it's a default, and it's usually the wrong one. Picking the model deliberately, per task, is most of the saving right there.

The expensive end: multiple agents at once

Running several subagents together, coordinating and sharing findings, is the priciest mode there is. Anthropic's data puts multi-agent systems at roughly 15 times the tokens of a single chat, and a single agent at about 4 times. In my own runs, switching a task from one session to a coordinating team lands around seven times the cost of just doing it in one place.

That is a lot to pay for something you turned on because it felt more sophisticated. The question is whether it buys you anything, and the honest answer is: only sometimes.

Does splitting a task across agents even help?

The advice everywhere in 2026 is that narrow agents beat broad ones. The strongest controlled evidence says it's far more conditional than that.

A Google DeepMind study tested 260 setups across six benchmarks, five architectures and three model families. Splitting a task across agents helped a lot when the work genuinely broke into independent parallel pieces, up to an 81% gain. It hurt badly when the work was sequential and tightly linked, down to a 70% loss. What decided which way it went was whether the task actually splits into independent parallel work, and whether one coordinator stays in charge, not how narrow each agent was.

Two numbers from that research changed how I think about fanning work out:

• Coordination is what contains error, not narrowness. Left uncoordinated, multiple agents amplify mistakes about 17 times over a single agent. Put one orchestrator in charge that checks the work before it goes anywhere, and that drops to about 4 times. A fleet of narrow agents with nothing checking between them fails just as badly as a fleet of broad ones.
• There's a ceiling. Once a single agent is already handling a task reasonably well, adding more agents tends to make it worse, not better. If one well-scoped session is coping, splitting it up is more likely to hurt.

So before I split any task across agents, I run three checks: does this genuinely break into independent parallel work, will one coordinator stay in charge rather than agents chatting freely, and is a single session already handling it fine? If any answer points the wrong way, I keep it in one thread and save the money.

The next level: make the system tell you

Knowing the test is the entry level. The real win is not having to run it by hand every time.

Those three checks are simple enough to build into your harness as a gate: before any workflow fans out into multiple agents, it has to clear them. That turns "remember to think about this" into "the system won't let you over-engineer without a reason." It's the same move as everywhere else in a good setup, take the judgement you keep making by feel and make it a rule the system enforces, so your attention stays on the work instead of policing yourself.

The takeaway

None of this argues against subagents. It argues against treating them as your default posture. They earn their cost in a few specific cases: verbose work you don't want cluttering your main session, work that genuinely needs to be isolated from what came before, and high-stakes checks where an independent pass catches what the original author would miss. Outside those, direct work in one continuous session beats fanning out, on cost, on speed, and more often than the narrow-agent crowd admits, on quality too.

Start simple. Add an agent only when the task's shape earns it.