Updated June 2026

A sub-agent is a second model instance your main agent delegates work to, with its own context window and its own (often narrower) tools. Used well, they’re the difference between an agent that scales and one that drowns in its own transcript. Used badly, they’re a way to pay twice for work the main agent could have done in one tool call.

What sub-agents actually buy you

Context isolation. This is the big one, and it’s about quality as much as cost. An agent that reads thirty files to answer one question now carries thirty files of noise into every subsequent decision. Delegate the exploration to a sub-agent and only its conclusion (a paragraph, not the thirty files) returns to the main thread. The main agent stays sharp because its context stays relevant.

Parallelism. Independent workstreams (read these eight files, run these five test suites, check these candidates) can fan out to sub-agents running concurrently instead of executing serially.

Tiered pricing. Grunt work doesn’t need the frontier model. A common pattern: the main loop runs on an expensive model while search-and-summarize sub-agents run on a cheap one. This also sidesteps a caching constraint, since switching models mid-conversation invalidates the prompt cache, but spawning a sub-agent on a different model doesn’t touch the main thread’s cache at all.

Fresh-context verification. A sub-agent that checks the main agent’s work without having watched it being done is a more honest reviewer than the agent critiquing itself. Self-review inherits all the assumptions that produced the bug.

When not to delegate

  • The task is one step. Spawning a sub-agent to read a single file costs a cold start, a delegation message, and a hand-back, all to avoid one read call. Models sometimes do this unprompted; tell them not to.
  • The steps are sequential and dependent. If step 2 needs step 1’s full context, splitting them across agents means re-explaining everything in the delegation message, badly.
  • You can’t specify the task crisply. Which leads to the main failure mode.

The failure mode: cold starts

A sub-agent knows nothing your delegation message doesn’t tell it. It hasn’t seen the conversation, the user’s preferences, or the three approaches already ruled out. Vague delegation (“look into the auth bug”) produces a sub-agent that cheerfully re-derives everything the main agent already knew, then returns an answer that ignores the constraint nobody passed along.

The fix is treating the delegation message like a ticket handed to a contractor: the goal, the relevant context, what’s already been tried, and what the deliverable looks like. If writing that feels like more work than doing the task, that’s the signal not to delegate.

Telling your agent when to delegate

Models won’t get this calibration right by default; some generations over-spawn and some under-spawn. The guidance that works is explicit and symmetric. Something like: “Delegate when work fans out across independent items, like many files to read or many cases to check. Do not spawn a sub-agent for work you can complete directly in a single response.” Say when, and say when not.