Quick answer
Use subagents when a task can be split into independent research, verification, or bounded implementation slices. Keep urgent blocking work local, give each subagent a concrete output, and avoid asking several agents to modify the same files.
Useful workflows
Research pass: one subagent checks official docs or changelogs while the main agent inspects the local codebase.
Review pass: one subagent evaluates a plan or diff for missing tests, unsafe assumptions, or security gaps.
Split implementation: separate agents own disjoint modules only after the write scopes are clear.
Common failure mode
Subagents are not a substitute for clear task boundaries. If two agents need the same context or files, keep the task local until the boundary is clearer.
Recommended play
- Use subagents first for research, review, and verification because those tasks have clear outputs and low file-conflict risk.
- Move to split implementation only when file ownership is already disjoint.
- Close every subagent with a decision: accept, reject, or park the finding, instead of blending all outputs into vague consensus.
Subagent delegation matrix
Choose the subagent pattern by task shape, not by how large or exciting the project feels.
| Area | Use subagents when | Keep local when | Expected output |
|---|---|---|---|
| Research | Official docs, changelogs, or API behavior can be checked independently | The answer depends on unresolved local code details | Source-backed summary and risk notes |
| Review | A plan or diff needs a second pass for bugs, missing tests, or assumptions | The reviewer would need to edit the same files immediately | Prioritized findings with file or requirement references |
| Implementation | Modules and files are clearly separated | Two agents need the same files or shared state | Scoped patch or implementation notes |
| Verification | One agent can run checks while the main thread inspects results | The failing behavior is still not reproduced | Commands, outputs, and pass/fail conclusion |
Execution steps
Name the decision
Write the exact decision the main agent needs, such as whether a migration path is safe or which docs changed.
Bound context and ownership
Give the subagent only the files, docs, or question it needs, and state whether it may edit or only report.
Collect findings before merging
Read every subagent result, separate evidence from opinion, and decide which findings change the main path.
Verify the integrated result
Run the final checks in the main thread so the completed work has one accountable owner.
Common pitfalls
Spawning agents before the boundary is clear
Write the desired output first, then decide whether parallel work is actually independent.
Letting multiple agents edit the same area
Use subagents for analysis or disjoint files; keep shared edits in the main thread.
Averaging conflicting advice
Pick the result with better evidence and explain the decision in the main thread.
Implementation checklist
- Name the output you need before spawning a subagent.
- Keep each task self-contained.
- Assign disjoint file ownership for edits.
- Close agents after collecting results.
- Merge conclusions into one decision instead of averaging blindly.
Questions this guide answers
What is the answer to Claude Code subagents examples?
Workflow patterns for using Claude Code subagents to split research, implementation, review, migration, and verification work.
Who is this practical examples tutorial for?
Developers using Claude Code for larger codebases, migrations, and multi-step reviews.
Which sources support this guide?
This guide is grounded in official or high-confidence sources from Anthropic, Anthropic.