1.2 Manager/Subagent Hierarchies
1.2.1 The Manager/Subagent Shape
A manager, sometimes called an orchestrator or supervisor, coordinates one or more specialized subagents. The detail that matters most, and that's easy to skim past: each subagent runs in its own context window, not the manager's. It does its work -- which might mean reading thousands of tokens of source material, trying an approach, backtracking, trying another -- entirely inside that private window, and then returns only a condensed result to the manager. The manager never sees the raw exploration, only the conclusion.
Each subagent works in its own private context window and returns only a condensed result -- the manager never sees the raw exploration, only the conclusion.
The one idea to hold onto
The manager/subagent pattern is both an architecture pattern and a context-management technique -- the two are the same fact viewed from two angles. Keeping that dual identity in mind is what the rest of this lesson unpacks.
1.2.2 Context Isolation: The Defining Benefit
Of the reasons subagents help, one is the reason, not just one among equals: context isolation. A research subagent can read thousands of tokens of source material -- documents, logs, search results, code -- and hand back a short summary, so the manager's own context window never absorbs the raw noise. This keeps the manager's context clean for the reasoning it actually needs to do, no matter how much exploration happened underneath it.
This reframes what a subagent is for. It's tempting to think of delegation as simply splitting work across more prompts running in parallel -- but that framing misses the point entirely. The defining benefit is the separate context window itself: spawning a subagent is a first-class technique for fixing context bloat, on par with pruning stale tool output or compacting history, not merely a division-of-labor convenience.
1.2.2 -- Key Concept
Context isolation -- each subagent absorbing raw exploration into its own window and returning only a condensed result -- is the defining benefit of the subagent pattern. Treating subagents as "just more prompts" misses this; the separate context window is the mechanism doing the work.
1.2.3 Specialization and Parallelism
Two further benefits ride along with context isolation. Specialization: each subagent can carry its own focused system prompt, its own tool set, and optionally its own model tier -- a cheap, fast model for a narrow lookup subagent, a stronger model for a subagent doing genuine synthesis. Parallelism: because independent subtasks are delegated to separate subagents rather than run sequentially in one context, they can execute concurrently, which is often the practical reason a manager/subagent design finishes faster than a single long agent loop would.
# Illustrative shape of subagent definitions passed to a manager
subagents = {
"research": {
"system_prompt": "You research a narrow question and return a 3-bullet summary.",
"tools": ["web_search", "read_file"],
"model": "claude-haiku-4-5", # cheap and fast -- the subtask doesn't need more
},
"synthesis": {
"system_prompt": "You combine research summaries into a coherent recommendation.",
"tools": [],
"model": "claude-opus-4-8", # the harder reasoning step gets the stronger model
},
}
# Each subagent runs its own conversation; the manager only ever sees
# the returned summaries, never the intermediate search results or drafts.- •Specialization -- narrow the system prompt and tool set to exactly what the subtask needs, and pick a model tier matched to its difficulty.
- •Parallelism -- independent subtasks delegated to separate subagents can run concurrently instead of waiting on each other.
1.2.4 The Cost Side of the Ledger
None of this is free. The tradeoff is coordination overhead and multiplied token usage: every subagent invocation is its own set of model calls, and someone -- the manager, or you -- has to reconcile the subagents' condensed results into a coherent whole. A hierarchy that sounds elegant on a whiteboard can, in practice, cost several times what a single well-scoped agent would have cost for the same outcome.
| Signal | Favors a manager/subagent hierarchy | Favors a single agent or workflow |
|---|---|---|
| Task separability | Subtasks are genuinely independent and don't need shared context | Steps depend heavily on shared, accumulating context |
| Task weight | Each subtask is heavy enough (deep exploration, many tokens) to justify its own window | The whole task is light enough to fit comfortably in one context |
| Latency tolerance | Subtasks can run concurrently and the coordination overhead pays for itself | A tight latency bar can't absorb coordination and reconciliation overhead |
| Cost ceiling | Budget can absorb multiplied token usage across subagents | Budget is tight and multiplying calls isn't affordable |
The hierarchy earns its overhead only when subtasks are genuinely separable AND heavy -- one without the other is a reason to stay with a single agent or workflow.
1.2.4 -- Exam Trap
Exam trap: reaching for a manager/subagent hierarchy by default because a task has "multiple parts." The pattern earns its coordination overhead and multiplied cost only when subtasks are genuinely separable and heavy enough to justify a dedicated context window each -- otherwise it's over-engineering a task a single agent or workflow would have handled more cheaply.
1.2.5 Put It Together: Deciding When to Reach for a Hierarchy
The question to ask before designing a manager/subagent hierarchy is never "could this be split into pieces?" -- almost anything can be split into pieces. The question is whether the pieces are genuinely separable, whether each one is heavy enough to justify its own context window, and whether the coordination and cost overhead is something the task's constraints (latency, budget) can actually absorb.
- 1.Is each subtask genuinely independent, or does it need context the others accumulated?
- 2.Is each subtask heavy enough -- deep exploration, many tokens of raw material -- that isolating it actually protects the manager's context?
- 3.Does the task's latency budget allow for the coordination and reconciliation step, or does a tight SLA rule it out?
- 4.Does the cost ceiling tolerate multiplied token usage across several subagents, or does a single agent meet the bar more cheaply?
Where this shows up on the exam
1.2 scenario questions usually describe a task and ask whether a manager/subagent hierarchy is justified. Check separability and weight before anything else -- a task that's merely "multi-part" but light and interdependent is a trap answer waiting for you to over-architect it.
Key Takeaways
- ✓A manager/supervisor coordinates subagents, each running in its own context window and returning only a condensed result -- never its raw working process.
- ✓Context isolation is the defining benefit of the pattern: it keeps the manager's context clean regardless of how much raw exploration happened inside each subagent.
- ✓Subagents also enable specialization (a focused system prompt, tool set, and model tier per subtask) and parallelism (independent subtasks run concurrently).
- ✓The cost is coordination overhead and multiplied token usage -- every subagent call is its own set of model calls that someone has to reconcile.
- ✓Reserve manager/subagent hierarchies for subtasks that are genuinely separable AND heavy enough to justify a dedicated context window each; a merely multi-part but light task is over-engineered by one.
- ✓Treating subagents as "just more prompts" misses the point -- the separate context window is a first-class fix for context bloat, not a convenience for dividing labor.
Check Your Understanding
Test what you learned in this lesson.
Q1.Why do subagents help manage context in a multi-step task?
Q2.A design splits a task into five subtasks, each trivially short and dependent on shared context from the others, then delegates each to its own subagent. What's the issue?
Q3.A manager delegates a document-heavy research subtask to a subagent with a scoped tool set and a smaller model, then a synthesis subtask to a subagent with a stronger model. What benefit does this illustrate, beyond context isolation?
Q4.What is the correct framing of the tradeoff in a manager/subagent hierarchy?
Practice This Lesson