When Should an AI Agent Delegate to Subagents? (And When It's Waste)
An AI agent should delegate to subagents when the work is genuinely parallel and independent, and it is waste when the work is sequential or trivial. The payoff comes from running several separate jobs at once under a coordinator; the cost shows up when subagents touch shared files or when coordination outweighs the task itself. Delegation is a throughput tool, not a default, so it earns its keep only when there is real parallel work to spread.
The mistake we made early was treating subagents as a way to look busy rather than a way to finish faster. Spinning up helpers for a job that has to happen in order, or for one small enough to do inline, does not save time. It adds a layer of prompting, hand-off, and integration on top of work that was already cheap. The question is never "can I delegate this" but "are there several things here that can honestly run at the same time."
Getting this right also changes how you hand work between sessions and models. A subagent is a fresh instance with no memory of the main thread, so delegating well shares a lot with writing a clean handoff between agents, and picking the right model for each helper overlaps with knowing when to use a cheap model versus an expensive one.
Which jobs are worth a subagent?
A job is worth a subagent when it is independent, parallelizable, and each piece needs real effort. The clearest wins are fan-outs: several research sweeps that do not depend on each other, or writing several separate files that no one else is editing. If you have five source areas to investigate and none of them feed the others, launching five workers at once turns a long serial slog into a single round of parallel work, and each one comes back with a finished chunk.
Writing is the other case that pays. When we produce a batch of separate documents, each with its own scope, a fan-out of several writers gets the whole set drafted in the time one would take. The condition is that the outputs are genuinely separate deliverables. The moment two writers need the same file, or one draft depends on another's conclusion, the parallelism is fake and you are better off doing the work in sequence in a single thread.
Effort is the third filter. A subagent carries setup cost: you write it a full prompt, wait for it, and integrate what it returns. If the task is a two-line lookup or a quick edit, that overhead dwarfs the work, and you should just do it inline. Reserve delegation for pieces heavy enough that the parallel time saved is larger than the coordination time spent. A useful test is to ask whether the helper's job would still be a real chunk of work if you had to do it yourself; if the honest answer is that it would take seconds, keep it in the main thread.
Sequential dependency is the clearest disqualifier. If step two needs the answer from step one, no amount of parallelism helps, because the second worker would only sit waiting for the first. Chains like research then draft then edit belong in a single thread where each stage reads the last one's output directly. Trying to fan them out just recreates the sequence with extra hand-offs bolted on, which is slower and more fragile than doing them in order.
What rules stop parallel agents from colliding?
Parallel agents stop colliding when no two of them write to the same file and a coordinator integrates their results. This is the rule that mattered most for us in production. Before we had it, two separate fan-outs produced file collisions where workers overwrote each other's output. After we made "no shared-file writes, coordinator integrates" a hard rule, we had zero conflicts. Each subagent produces its own artifact or returns text to the main thread, and the coordinator is the only writer that stitches the pieces together.
The second rule is that every subagent gets an explicitly chosen model. Delegation is where you match effort to cost: mechanical sweeps and data gathering go to a cheaper, faster model, while work that needs judgment and synthesis goes to a stronger one. Leaving the model implicit means a helper inherits whatever the main session runs, which is either wasteful or underpowered. Choosing per subagent is how a fan-out stays economical without getting dumber where it counts.
The third rule is to capture output immediately, because a subagent's result dies with it. The instant a helper returns, its full output goes to a file before you do anything else with it. A subagent does not persist after it finishes, so an unread or unsaved result is simply gone. We write the raw return first and synthesize from the saved copy afterward, never the other way around.
The fourth rule follows from the same fact: each subagent needs a self-contained prompt, because subagents do not share memory with the main agent or with each other. A helper knows only what its prompt contains, so you hand it every file path, constraint, and piece of context it needs to finish alone. A prompt that assumes shared knowledge produces a worker that guesses, and guessing is where parallel work quietly goes wrong.
Put together, the discipline is simple: delegate only genuinely parallel, independent, effortful work; keep writes unshared with one coordinator integrating; choose a model per helper; and save every result the moment it lands. For everything sequential or small, skip the ceremony and keep it in one thread.
FAQ
Do subagents share memory with the main agent?
No. Each subagent gets a self-contained prompt and returns a result, so you must hand it everything it needs and capture its output. Nothing persists after it finishes: it does not see the main thread's history and other subagents do not see its work. Treat every helper as a fresh instance that knows only what its prompt says.
How many subagents should run at once?
Only as many as there are genuinely independent pieces of work. If five parts can run without touching each other or waiting on one another, five helpers make sense. More than the work needs just adds coordination cost and token spend without buying speed, and helpers that share files or dependencies collide instead of parallelizing. Match the count to the real work, not to ambition.
Are subagents the same as a team of agents?
No. Subagents are short-lived workers spun up under one coordinator for parallel execution, then discarded when they return. They are not a standing roster of personas with fixed roles and titles. The value is throughput on independent work, not an org chart. You launch them for a burst of parallel effort and integrate the results, rather than maintaining a permanent team.