Using subagents effectively

You know what subagents are. You know how to create one. You know the patterns that make them effective. The question left is the one that actually decides whether subagents earn their place in your workflow: when should you use them, and when should you leave the work in your main thread?

The answer comes down to a single question — and three use cases where the answer is almost always yes, and three where it's almost always no.

The decision rule

When deciding whether to use a subagent, ask yourself: does the intermediate work matter to my main thread?

If the answer is no — you just need the final result and don't care about the journey — delegate it. If the answer is yes — you need to see and react to what's happening along the way — keep it in your main thread.

That's the whole rule. Everything else in this lesson is cases where one answer or the other is obvious.

Subagents shine when exploration is separate from execution — when you need a result, not a play-by-play of how it was found. They get in the way when each step in a task depends on what the previous step discovered, because the handoff between contexts costs more than it buys.

Use for: research tasks

Research is the classic subagent use case. Imagine investigating how authentication works in an unfamiliar codebase. Your main thread needs to know where the JWT is validated — it does not need to see every file that was searched along the way.

A research subagent can read dozens of files, trace through function calls, and explore different code paths. All of that exploration stays in the subagent's context. Your main thread receives something like:

JWT validation happens in middleware/auth.js line 42, called from the Express router in route/api.js.

One line. That's what the main thread needed. The subagent did the digging; the main thread moves forward with exactly the fact it was missing. This is the pattern for every "where does X live in this codebase?" question you'll ever ask.

Use for: code reviews

Claude reviews code more effectively when the code is presented as being authored by someone else. That's not a marketing claim — it's a behavior you can reproduce. If you build a feature over many turns with your main thread and then ask that same thread to review it, you get weak feedback. Claude was involved in creating it. It struggles to see it with fresh eyes.

A reviewer subagent sees the changes in a separate context. It runs git diff, reads the modified files, and applies its review criteria without any history of how the code was written. The separation is the point.

This also lets you encode project-specific review standards in the subagent's system prompt — security checklists, architectural conventions, performance gates — so every review across the team applies the same criteria.

Use for: custom system prompts

Claude Code's default system prompt emphasizes concise, code-focused responses. That works beautifully for coding. It doesn't work for everything.

Two cases where a custom system prompt makes a subagent genuinely better than the main thread:

• Copywriting subagent. Give it instructions about tone, audience, and voice. Claude Code's default prompt tends toward concise technical writing, which really isn't what you want for a landing page or email campaign — unless you want to put your customers to sleep. A copywriting subagent can have completely different instructions about structure, rhythm, and brand.
• Styling subagent. Point its system prompt at your design system files with @ mentions. When the subagent runs, those files load into its context automatically, so it knows your color variables, spacing conventions, and component patterns before it writes a single line of CSS.

The shared pattern: the subagent does something the main thread genuinely can't — not because of knowledge, but because of prompt shape.

Avoid for: expert claims

Subagents that claim expertise rarely help. Prompts like "you are a Python expert" or "you are a Kubernetes specialist" add no value because Claude already has that knowledge. There's nothing a so-called expert subagent can do that your main thread can't do directly — so you pay the overhead of launching a subagent (losing visibility, compressing findings into a summary) for no actual capability gain.

If the only reason to create a subagent is a persona, don't create it. The main thread is already an expert at whatever you're asking about.

Avoid for: sequential pipelines

Sequential subagent pipelines look clever on paper and fail in practice. Consider a three-agent flow: one to reproduce a bug, one to debug it, and one to fix it.

Pipelines work when tasks are truly independent. They fail when each step depends on discoveries from the previous step — and bug fixing almost always does. The fix agent doesn't know the subtle clue the debug agent noticed in a stack trace, because the debug agent compressed its work into a summary before handing off. Information gets lost in the handoff, and the fix ends up working on a partial picture.

If the steps depend on each other, keep them in one thread.

Avoid for: test runners

Test runner subagents tend to hide information you need. When tests fail, you want the full output — assertions, stack traces, log lines — to diagnose what broke. A subagent that returns "tests failed" forces you to create additional debug scripts just to recover details that would have been visible in direct output anyway.

This isn't a theoretical concern: in practice, the test runner pattern performed worst among the subagent configurations that have been tested. The overhead of the subagent buys you nothing, and the summary compression costs you the signal you actually needed.

If you need the full output, run the tests in the main thread.

The framework

Here's the decision framework in one piece:

Use subagents for:

• Research and exploration — you need a fact, not a tour of how it was found
• Code reviews — fresh context produces better feedback, and the system prompt can encode project standards
• Tasks that need a custom system prompt — copywriting, styling, anything where Claude Code's default voice gets in the way

Avoid subagents for:

• Expert personas that don't add real capability
• Multi-step pipelines where each step depends on the last
• Running tests where you need full output for debugging

All six cases reduce to the same question: does the intermediate work matter? For research, reviews, and custom-prompt tasks, no — the intermediate work is exactly the noise you're trying to get rid of. For expert personas there is no meaningful intermediate work; for pipelines and test runs, the intermediate work is the whole point.

A reflection

Before moving on, take a minute and think about your recent Claude Code sessions.

• Pick one task where you would have benefited from a subagent — one where you cluttered your main context with exploratory work to get a simple answer. What was the question? What would the subagent have returned?
• Pick one task where you used a subagent (or considered one) and it was the wrong call — maybe a pipeline, maybe a test runner, maybe an expert persona. What would have worked better?

Apply the decision rule to each. Did the intermediate work matter? The answer should tell you immediately whether subagents were the right tool.

Closing the loop

Across this course we've covered the full arc of subagents in Claude Code: what they are (isolated threads that return summaries to the main context), how to create them (the /agents command and the config file anatomy), how to design them effectively (specific descriptions, structured output, obstacle reporting, limited tool access), and now when to use them.

The underlying idea in all of it is the same. Subagents are a context management tool. They exist to keep your main thread clean when the intermediate work doesn't matter, and to give specific tasks a custom-shaped environment to run in. Use them where that's true. Leave the work in the main thread where it isn't.