Subagents
The last chapter was about choosing how hard the agent thinks. This one is about choosing where it thinks. Because some investigations are worth running but not worth keeping — and the move that lets you run them without paying for the mess is the subagent: a fresh context window that does a scoped job off to the side and returns only what you actually need.
The core idea is small and it’s the whole chapter, so hold onto it. A subagent is a separate Claude instance with its own context window. You hand it a task, it works in isolation — reading files, running greps, dumping logs into its memory, not yours — and when it’s done it returns a single summary to your main conversation. The hundred file reads it did to reach that summary never enter your thread. You get the conclusion; the agent eats the noise. That’s the trade in one line, and everything below is just learning when and how to make it.
The investigation we’ll follow
Section titled “The investigation we’ll follow”Same payments service from the last chapters. This time you’re not fixing anything yet — you’re trying to understand something before a risky migration. The question on the table:
Map every place the payments code writes to the ledger, and every test that covers those writes.
That sounds simple until you start. The ledger gets touched from the charge path, the refund path, a nightly reconciliation job, and a webhook handler — and each of those has tests scattered across three directories. Answering it by hand means reading dozens of files, running greps that return pages of hits, and skimming test suites you’ll never look at again. Do all of that in your main session and you’ve buried the actual work — the migration you came here to plan — under a landfill of file dumps the agent now has to carry for the rest of the day.
So we’ll do it the other way. Over the next few lessons:
- Hand the whole investigation to one subagent and watch what comes back — the map, not the file dumps that produced it.
- Fan it out across several subagents at once when the problem splits into independent slices — and learn when that’s leverage versus when it’s just showing off.
- Push a long-running one into the background so you can keep working while it grinds, and control or kill it when you need to.
- Define a reusable subagent so a job you run constantly — like that ledger audit — always runs the same way, with the same tools and the same instructions.
By the end, “should this work happen in my thread or somewhere else?” will be a question you ask before every noisy task. Start with delegating the investigation.