Single Agent or Subagents?

The question

Not *"is this task large?"*: large tasks often belong in one context. The question is:

Will this work produce a lot of output I do not want to keep?

If yes, isolate it. If no, keep it inline.

Why that is the right question

Everything in your context window is re-sent on every subsequent turn. A search that generates 8,000 tokens of dead ends does not cost you 8,000 tokens. It costs you 8,000 tokens multiplied by every remaining turn in the session.

A subagent is a disposable context. It does the messy work, and only the conclusion comes back.

Inline:     8,000 tokens of noise, re-sent across 40 remaining turns
Subagent:   8,000 tokens once, a 300-token answer returns

The decision table

Situation	Choice	Why
Searching for where something lives	Subagent	Enormous noise-to-signal ratio
Implementing a change you already scoped	Single agent	You need the surrounding context
Four independent investigations	Subagents, parallel	Genuinely concurrent
Step B needs step A's output	Single agent	Two cold starts for one job
Reviewing a large diff	Subagent per file, if very large	Each review is independent
Debugging one failing test	Single agent	The context is the work
Reading one file	Single agent	Setup costs more than the task

The cost of a cold start

A subagent shares nothing with its parent. Fresh system prompt, fresh tool definitions, no knowledge of the conversation. Everything it needs must be in the prompt you give it.

That makes the brief the whole skill:

Bad:   "Look into the auth thing."

Good:  "Find every place a session token is created or validated.
        Search src/ and services/. Return a list of file:line with a
        one-line description of each. Do not propose changes.
        If you find nothing, say so: do not infer where it might be."

The good version specifies scope, output shape, and, critically, what to do on failure. A vague brief produces an agent that explores broadly, burns tokens, and returns something unusable.

Parallel fan-out

Independent work runs at once. The constraint is genuine independence, if you find yourself wanting agent 2 to know what agent 1 found, they were never parallel.

Orchestrator (frontier tier)
├── Agent A: map the data layer        ─┐
├── Agent B: map the API surface        ├─ concurrent, independent
├── Agent C: find all the auth checks   │
└── Agent D: inventory the test suite  ─┘
        ↓
Orchestrator synthesises the four reports

Route the fan-out down a tier. Searching and extracting is mechanical work. The fast tier does it fine at a fifth of the price, and the orchestrator that has to reason across four reports is where the frontier tier earns its keep.

Signals you should have isolated

The conversation is slowing down and answers reference things from far back
You are compacting mid-task
Half the visible context is tool output you have already extracted the answer from
Cost per turn is climbing through a session that has not got harder