Course B · Module B2 Going Agentic · Lesson 12 of 18
Big jobs go faster when you split them up and run the pieces in parallel.
A single agent doing a long, complex job is like one person trying to research, write, proofread, and format a report all at once. It works — but it's slow, the context fills up with everything from every stage, and one misfired step can tangle the whole run. The alternative is subagents: fresh, focused helpers that each own one scoped piece of the job. Your single win: by the end you'll understand when to delegate to subagents, and what the orchestration pattern looks like — so you can hand off parallel work without losing oversight.
A subagent is just another agent — a model, tools, context, and a loop — that you spin up to handle a specific, bounded task. What makes it a subagent is context: it was launched by a main (orchestrator) agent rather than directly by you, and it reports its result back to that orchestrator when done.
Think of a project manager who has three team members: a researcher, a writer, and a fact-checker. The PM doesn't do all three jobs herself — she delegates, waits for the results, and then assembles the final deliverable. The researcher, writer, and fact-checker are her subagents. Each works in their own lane; none is distracted by the others' work. The PM is the orchestrator.
Multiple subagents run at the same time. Researching three topics in parallel takes the same wall-clock time as researching one. For anything with independent pieces, this is a straightforward speed win.
Each subagent starts fresh — its context window contains only the task it was given, not the entire history of the parent job. This keeps reasoning sharp and prevents the "context contamination" where early steps confuse later ones.
You can configure each subagent differently — give the researcher a web-search tool and a skeptical research skill, give the writer your brand-voice skill and a draft template. Right tools, right instructions, for each role.
Short, linear tasks — draft one email, answer one question — don't need subagents. The overhead of spawning and coordinating them costs more than it saves. If the whole job fits in a single agent's context and runs in under a minute, keep it simple.
Orchestration is just the word for the main agent managing the subagents. Here's how it flows in plain English:
A note on cost. Every subagent uses tokens — the model's unit of work. Running five parallel subagents uses roughly five times the tokens of one agent doing the same work sequentially. For time-sensitive tasks the trade-off is usually worth it; for simple jobs it isn't. Check your usage after your first multi-agent run.
Answer before opening — recalling it now is what makes it stick.
Role, not technology. Both are ordinary agents. The orchestrator receives the high-level goal, breaks it down, and delegates pieces. A subagent receives a scoped task from the orchestrator and returns a result. You could run the same agent as an orchestrator in one job and as a subagent in another.
Because subagents start fresh — they only see their own scoped task, not the full history of the parent job. This matters because a cluttered context causes the model to lose track or get confused by irrelevant earlier steps. A focused context means sharper, faster reasoning for that specific piece.
No — overkill. A single short task fits easily in one agent's context and takes seconds. The overhead of spawning, configuring, and coordinating subagents would take longer than just running one agent straight through. Subagents pay off on jobs with multiple independent pieces that benefit from parallelism or specialization.
Read this next (primary source)
Create custom subagents — Claude Code Docs. The official guide to defining and deploying subagents in Claude Code: how to write the agent definition file, set descriptions, and control which tools each subagent gets. See RESOURCES.md for more.
Key terms — agent, context, human-in-the-loop — are in the course glossary. Keep it open.