Stop Making One AI Do Everything — Use Subagents Instead
TL;DRWhen one AI thread does everything, it fills up with junk and does your work serially. Instead, delegate a scoped task to a subagent — it works in its own clean context and reports back a result — and match a cheap fast model to grunt work, a strong one to real reasoning. Faster, cheaper, and your main thread stays focused.
…
Is a subagent a different AI model?
Not necessarily — it's a fresh instance of an AI with its own clean context, dispatched to do one scoped task. You can also tell it which model to use, which is where the cost/speed win comes from.
Do I need Claude Code for this, or does any AI work?
The pattern — hand off a scoped task, get a clean-context worker, review the result — works with any tool that supports it. Claude Code has it built in (the Agent/Task tool); that's what the examples here use.
How many subagents can I run at once?
As many as are genuinely independent. If task B needs task A's output, run them one after another. If they don't depend on each other — three separate research questions, say — fire them in parallel and read all three reports when they land.
Isn't this just... delegating to another chat?
Basically, yes — that's the whole trick. A subagent doesn't share your context, so it doesn't drag your main thread down with search results and file dumps. It only hands back the finished answer.
One AI thread doing every step of a big task hits a wall fast: it fills up with search results, file contents, and half-finished side quests, and by hour two it's slow, confused, and expensive. The fix isn't a smarter prompt — it's stopping being the one doing all the work. Hand off scoped pieces to subagents, each working in its own clean context, and send the right model to each job. Here's the pattern.
What is a subagent, really?
A subagent is a fresh AI instance you dispatch with one clear, scoped task. It doesn't see your whole conversation — it starts clean, does its job (research a question, review a diff, extract data from ten files), and reports back a result. Your main thread only receives that result, not the mess it took to get there.
That's the entire value: your context stays about the actual decision you're making, not the legwork. The subagent's legwork happens somewhere else and never touches your thread.
When do you actually reach for one?
Two situations, and they cover almost everything:
Independent work you'd otherwise do one at a time. Research three unrelated questions? Review a PR while you keep building? Look up docs for two different libraries? These don't depend on each other — so don't run them serially in one thread. Fire them off together and read the reports when they land.
Anything big enough to pollute your main thread. Grepping through a huge codebase, reading a stack of long files, chasing a search that might take twenty tool calls before it pays off — none of that belongs in the thread where you're actually deciding what to build. Delegate it, get the summary back.
If a task is small — one file, one quick lookup — just do it yourself. Subagents are for the parts that would otherwise flood your context with noise.
The other half: route the right model to each job
Not every task deserves your best (and most expensive) model. Match the model to what the task actually needs:
Cheap, fast model — search, extraction, mechanical edits, "read these five files and pull out the pricing," simple lookups. It doesn't need deep judgment, just speed and volume.
Strong model — architecture decisions, debugging something genuinely confusing, judgment calls, anything where being wrong is expensive.
This is where the real savings show up. A cheap model doing grunt work in parallel finishes faster and costs a fraction of what it'd cost to have your best model grind through it step by step. Save the expensive reasoning for the moments that actually need it.
A prompt you can paste to try this pattern right now:
I need to research three things before I decide on X: <topic A>, <topic B>,<topic C>. Dispatch a separate subagent for each — they're independent, runthem in parallel — with a clear scoped question for each one. Use a fast/cheapmodel for each since this is lookup work, not judgment. Report back a shortsummary from each so I can decide.
The discipline: dispatch, then verify
A subagent's report is a claim, not a fact. It describes what it thinks it did — not always what actually happened. Before you act on a result:
Give one clear brief per agent. A vague ask gets a vague, generic result. State the exact question, what's in scope, what's out.
Check the actual output, not just the summary — if it edited code, look at the diff; if it researched something, skim a source or two.
Don't chain trust. If subagent B's task depends on subagent A's claim, verify A's claim first, or B inherits the mistake.
This is the whole discipline: delegate scoped work, don't blindly trust what comes back.
Why this matters
This pattern is how the other things in this series scale. A skill (the packaged workflow from episode 05) often runs as a subagent — dispatched, executed in its own context, reporting back. A big multi-step build isn't one giant thread grinding serially — it's a main thread staying focused on decisions while scoped subagents handle the legwork in parallel, on the model that fits the job.
The result: your main thread stays about the thing you're actually deciding, work that used to take an hour serially finishes in minutes running in parallel, and you stop paying premium-model prices for work a cheap model does just as well.
How this connects to the rest of the setup
Subagents are how the system does work in parallel — and they inherit everything the main thread has:
The same vault and graph, read from their own clean context.
The same rules file, so a delegated task behaves the way you'd want it to without re-briefing.
They can run skills and call MCP tools — that's what makes a subagent useful instead of just another chat window.
What they come back with goes into memory, so the next session starts already knowing it.
AI FROM MY POV