Course Review and Exam Tips
The Whole Course on One Page
You've gone from 'what is a subagent?' to orchestrating a 90%-better multi-agent research system. Let's consolidate. A subagent is a specialized assistant that runs in its own isolated context, does focused work, and returns only a summary. Everything else is a consequence of that one idea.
| Topic | The essential | Key fact |
|---|---|---|
| What & why | Isolated context, summary out | Keeps the finite main context clean |
| Built-ins | Explore / Plan / general-purpose | Explore = Haiku read-only; no nesting |
| Creating | /agents + .claude/agents/*.md | name + description required |
| Designing | 4 pillars | description, output format, obstacles, limited tools |
| Using | Decision rule | 'Does the intermediate work matter?' |
| At scale | Orchestrator-worker | +90.2%, ~15× tokens, parallel |
The entire course distilled — six topics, six essentials.
High-Yield Facts
- •A subagent receives a system prompt + a task prompt and returns only a summary; its conversation is discarded. The only parent→subagent channel is the task prompt.
- •Built-ins: Explore (Haiku, read-only), Plan (inherit, read-only, plan mode), general-purpose (inherit, all tools). Subagents CANNOT spawn subagents.
- •Config: Markdown + YAML frontmatter at .claude/agents/ (project) or ~/.claude/agents/ (user); only name + description required; model defaults to inherit; omitting tools inherits all.
- •The 4 design pillars: specific description (shapes the input prompt), defined output format (stopping points), obstacle reporting, limited tool access (least privilege).
- •Anti-patterns: expert personas, sequential dependent pipelines, test runners. Decision rule: does the intermediate work matter?
- •SDK: AgentDefinition (description + prompt required); invoked via the Agent tool (renamed from Task in v2.1.63); Workflow tool for dozens–hundreds of agents.
Two questions answer most subagent decisions
(1) 'Does the intermediate work matter?' → No: delegate. Yes: main thread. (2) 'What does this subagent actually need to do?' → tells you its tools, model, and output format. Master those two and the rest follows.
Common Traps
- 1.Thinking a subagent inherits your conversation — it does NOT; put everything it needs in the task prompt.
- 2.Forgetting subagents can't nest — orchestrate chains/fan-out from the main thread.
- 3.Creating 'expert' subagents that add no capability over the main thread.
- 4.Building dependent pipelines where summary handoffs lose the context each step needs.
- 5.Using a test-runner subagent that hides the output you need to debug.
- 6.Assuming multi-agent is always better — it costs ~15× tokens and is a poor fit for interdependent or coding work.
Watch the control boundary
Most subagent mistakes come from forgetting the isolation boundary: information only crosses it via the task prompt (in) and the summary (out). Design every subagent around what must cross that boundary in each direction.
Where to Go Next
You now have a complete mental model of subagents — from a single research helper to system-scale orchestration. To cement it, build something real:
- •Create a project code-reviewer subagent with the 4 design pillars (read-only tools, a structured output format with an Obstacles section), check it into git, and use it after your next change.
- •Try a parallel research delegation: 'Research modules X, Y, Z in parallel using separate subagents.'
- •If you build apps, define an AgentDefinition subagent in the Agent SDK and detect its invocation via the Agent tool.
- •Read Anthropic's multi-agent research engineering post and the official subagents docs to reinforce the wire-level details.
You've completed the course
From context isolation to the orchestrator-worker pattern, you can now explain, create, design, and scale subagents — and make the right call on when to delegate. Congratulations.
Key Takeaways
- ✓A subagent runs in an isolated context, does focused work, and returns only a summary — every other behavior follows from that.
- ✓Built-ins: Explore (Haiku, read-only), Plan (inherit, read-only), general-purpose (inherit, all tools); subagents cannot nest.
- ✓Creating: Markdown + YAML at .claude/agents/ (project) or ~/.claude/agents/ (user); only name + description required; model defaults to inherit; omitting tools inherits all.
- ✓The 4 design pillars: specific description (shapes the input prompt), output format (stopping points), obstacle reporting, limited tools.
- ✓Two questions decide most things: 'does the intermediate work matter?' (delegate vs main thread) and 'what does it need to do?' (tools/model/output).
- ✓At scale: orchestrator-worker (+90.2%, ~15× tokens); AgentDefinition + the Agent tool (renamed from Task in v2.1.63); the Workflow tool for dozens–hundreds of agents.
Check Your Understanding
Test what you learned in this lesson.
Q1.What is the single most important property of a subagent that everything else follows from?
Q2.Which two questions resolve most subagent design and usage decisions?
Q3.Which is a genuine subagent fact, not a common trap?
Q4.What are the four design pillars of an effective subagent?
Practice This Lesson