By the end of this chapter you can tell when to hand a slice of work to a focused subagent and when to keep it in the main thread, and you can spot the subagent patterns that quietly make things worse.
AVATAR OPENER · ~90s
Watch: delegating a research job to a subagent, and what comes back
HeyGen avatar · generated, consistent presenter
A subagent is a focused helper you hand a slice of a job to. It works in its own separate space, with its own fresh memory, and it reports back a summary when it is done. That is the appeal and, if you are not careful, the trap: because it works out of sight, you get a clean main conversation, but you also lose the ability to watch how it got there.
That single fact, that a subagent runs in its own context and returns only a summary, tells you almost everything about when to use one. If you only need the result, delegating is a gift: the messy middle happens somewhere else and your main thread stays clear. If you need to see and react to the work as it unfolds, sending it away is a mistake, because by the time you get the summary the moment to steer has passed.
Keep it in the main thread
When the intermediate work matters, when you need to see each step and course-correct, keep it in front of you. Watching is the point.
Result: you steer as it goes, nothing lost to a handoff.
VS
Send it to a subagent
When only the result matters, hand it off. The subagent burns through the mess in its own space and returns a clean summary.
Result: main context stays clear, you get the answer not the noise.
Does the intermediate work matter? If no, delegate it. If yes, keep it in the main thread.
Ask it every time before you delegate. It is the one question that decides whether a subagent helps you or hides the very thing you needed to see.
WHERE SUBAGENTS GENUINELY SHINE
There are a few jobs subagents are simply good at, and they share a shape: a lot of messy input, a clean summary out, and no need for you to watch the middle.
Research
Read dozens of files or sources and come back with a tight summary and the exact references. The reading is the mess; the summary is all you wanted.
Review
The Roast Me reviewer from two chapters back is a subagent: it reads your work in fresh context, precisely because it never built it.
A different voice
A subagent with its own brief can write in a tone your main thread is not set up for: a warmer copy voice, a stricter house style.
Parallel independent work
Two unrelated jobs at once, each in its own space, neither waiting on the other. Independent is the key word.
Notice you have already met one of these. The fresh reviewer from the Roast Me chapter is exactly a subagent: it earns its value by starting clean, having never made the choices it is now checking. That is the same reason research delegation works. The subagent reads the pile so your main thread does not have to hold it.
THE FOUR THINGS THAT MAKE A SUBAGENT GOOD
A vague subagent is worse than no subagent, because it runs off unsupervised and hands you back something you then have to redo. Four things separate a helper that earns its keep from one that wastes a run.
A specific description
It controls when the subagent is used and shapes the instructions it gets. "Tell it exactly which files to review" produces a precise brief, not a vague wander.
A defined output format
The single biggest improvement. Tell it the exact sections to return. It creates a clean stopping point and stops the run sprawling.
Obstacle reporting
Ask for an "obstacles hit" section. Otherwise the workarounds and quirks it discovered vanish, and your main thread has to find them all over again.
Limited tool access
Give it only the tools its job needs. A researcher reads and searches, nothing more. A reviewer reads but cannot edit. Scope is safety.
Of these, the defined output format does the most work, so make it a habit. When you tell a subagent exactly which sections to return, a summary, then the critical items, then the minor ones, then its verdict, you give it a natural place to stop and you get back something you can actually use at a glance. A subagent told only to "review this" will ramble; one told to fill in five named sections comes back sharp.
Brief a research subagent
Spin up a focused research helper for this, and have it work
separately so my main thread stays clean.
Its job: [the specific research task, e.g. "read these five
articles and tell me where they disagree about X"].
Tell it exactly what to look at, and require it to return only
these sections:
- Summary (three lines max)
- Key findings, each with the source it came from
- Where the sources disagree
- Obstacles or gaps it hit
- What it could not answer and why
Give it read and search access only. Nothing that can change my
files. When it is done, bring me just that summary.
Summary: the five sources broadly agree on the what, and split
hard on the timing.
Key findings: [each with its source named, so you can check it].
Disagreement: two sources say start now, three say wait for X.
Obstacles: one article was paywalled; it worked from the summary.
Could not answer: none had real cost figures, so that is still open.
THE PATTERNS THAT QUIETLY HURT
This is the part most guides skip, and it is the most useful. Some popular-sounding uses of subagents make your work worse, not better. Knowing them saves you from clever-looking setups that quietly cost you.
Expert personas add nothing
Telling a subagent "you are a senior Python expert" does not make it better. Claude already has the knowledge. The persona is theatre, not capability.
Sequential pipelines lose the thread
Chaining "do A, hand to B, hand to C" fails when each step needs the last, because detail is lost in every handoff. Keep dependent work together.
Test-runners hide what you need
A subagent that runs your tests and reports "passed" or "failed" strips out the full output you need to diagnose the failure. This one measurably performed worst.
Delegating what you needed to watch
The root error behind all of these: sending away work whose middle you actually needed to see. If you need to react as it goes, it stays with you.
The through-line is the decision rule again. Expert personas, dependent pipelines, and test-runners all fail for the same underlying reason: they delegate something whose intermediate work mattered. The persona hides that the base model was already capable. The pipeline hides the detail lost between steps. The test-runner hides the output you needed to read. Every one of them is a case of sending away the very thing you should have kept in front of you.
You can build these subagents by conversation for a single session. The durable version, a subagent whose configuration you write down and check into a project so your whole setup uses it the same way every time, needs a repo and a terminal. That waits for the next part of the course, and the companion repo has a research helper and a read-only reviewer ready to clone. For now, the judgment is the lesson: what to delegate, what to keep, and how to brief the ones you do send.
NOW YOU TRY · ANALYZE
Delegate one job, keep another
Take two real tasks on your plate. For each, ask the one question: does the intermediate work matter? Pick the one where it does not, a pile of reading, a fresh review, and delegate it to a subagent using the brief above, with a defined output format. For the one where the middle does matter, deliberately keep it in your main thread. Notice the difference in what you get back and how much control you kept.
Right if you can point to one task you correctly delegated and one you correctly kept, and say why each was the right call using the decision rule.
Show the worked solution
The drill lands when the two tasks sort themselves cleanly under the rule. Say task one is "read the last six months of my newsletter and tell me which topics got the most engagement and which fell flat." The intermediate work, the reading, does not matter to you; only the summary does. So you delegate it, and crucially you give it an output format: top topics with numbers, weak topics with numbers, one surprise. What comes back is a tight brief you can act on, not a wall of notes. Task two is "rework the pricing on my services page." Here the middle absolutely matters, because each choice, what to charge, what to bundle, how to phrase it, is a judgment call you need to make as it goes, not discover in a summary after. So you keep it in the main thread and work it turn by turn. Same afternoon, two tasks, and the decision rule sorted them correctly: the pile-of-reading went away and came back clean, the judgment-heavy one stayed where you could steer it. Get that sorting right consistently and subagents become genuinely useful instead of a clever way to lose control of your own work.
WATCH FOR
✗You delegate work you needed to watch. Ask the rule first. If you need to react as it unfolds, keep it in the main thread. The summary comes too late to steer.
✗Your subagent rambles or over-runs. No defined output format. Tell it the exact sections to return. That is the single biggest fix there is.
✗You dress a subagent up as an "expert". Personas add nothing. Spend the words on a specific task, a clear output format, and the right tools instead.
✗You chain dependent steps across subagents. Detail leaks at every handoff. Keep work that depends on the previous step together, in one thread.
WHAT YOU LEARNED
The takeaways
A subagent works in its own context and returns only a summary: clean main thread, but you lose sight of the middle.
The decision rule: if the intermediate work does not matter, delegate; if you need to watch and steer it, keep it in the main thread.
Subagents shine at research, fresh review, a different writing voice, and genuinely parallel independent work.
Four things make one good: a specific description, a defined output format (the biggest lever), obstacle reporting, and limited tool access.
The anti-patterns all break the rule: expert personas, dependent pipelines, and test-runners each hide the very thing you needed to see.
Your project · delegate with judgment
Delegate one real research or review job to a well-briefed subagent this week, with a defined output format, and consciously keep one judgment-heavy job in your main thread. That closes Part Two: you can now build skills and direct subagents. Everything up to here you can do inside the chat window you already trust. What waits on the other side of the terminal is the part that turns these habits into things that run on their own, reach your real tools, and work while you sleep. That is the actual leap this course was built for, and the next chapter makes the crossing as painless as it can be, with the terminal taught from zero, so nothing that follows feels out of reach.
A subagent is not a smarter helper, it is a separate one. Used on the right job it clears your desk and hands you exactly what you needed. Used on the wrong one it quietly buries the step you most needed to see. The whole skill is knowing which is which.