Domain 1 questions rarely ask "what is a subagent?" They hand you a scenario — a migration across 40 files, a research task with three independent lookups, a rule that a secret must never reach a tool — and ask which mechanism fits. The distractors are almost always the adjacent concept: the one that shares vocabulary but plays a different architectural role. If you only memorized definitions, both answers look right.
This guide attacks that directly. Each section takes a pair that test-writers love to blur and pulls them apart along the dimensions that actually decide a question: who makes the decision, when it happens, what it does to the context window, and what it is for. The goal is a mental model you can run in your head, not a glossary you recite.
A quick orientation before the pairs. An agent is a loop: the model proposes an action, the harness executes it, the result feeds back, and the loop repeats until the model stops. Two facts fall out of that. First, some things are decided by the model (which tool to call, whether to spawn help) and some are decided by the harness around it (whether a hook fires, whether tool calls in one turn run concurrently) — confusing those two actors is the single most common Domain 1 mistake. Second, every subagent gets its own fresh context window and hands back only a distilled result, which is the whole reason the pattern exists. Keep the actor and the context window in mind and the five pairs below mostly answer themselves.
Coordinator vs Subagent
These are two roles in the same delegation, not two competing tools — which is exactly why they get swapped. The coordinator (also called the orchestrator or lead agent) is the agent that holds the plan, decides what to farm out, and stitches results together. A subagent is a worker it spawns to run one focused subtask in an isolated context and return a distilled answer. One thinks about the whole job; the other executes a slice of it and reports back.
| Dimension | Coordinator | Subagent |
|---|---|---|
| Purpose | Plan the overall task, delegate slices, integrate results into a final answer | Execute one bounded subtask and return a condensed result |
| Scope | The whole objective, end to end | A single slice defined by the prompt it was handed |
| Who decides | The coordinator model chooses what to spawn and when | The subagent model decides only how to accomplish its assigned slice |
| Context window | Long-lived; holds the plan and the final synthesized answers (not each worker's raw scratch work) | Fresh and isolated — sees only the prompt passed in, not the parent's history |
| Lifetime | Spans the entire session | Lives only for its one subtask, then terminates |
| Best for | Multi-part goals needing planning, routing, and synthesis | Isolating a noisy or specialized job (deep search, focused audit) so its tokens never bloat the parent |
| When NOT to use | A single simple task with no parts to coordinate — delegating adds pure overhead | A step that needs the parent's full running context, or that must interact turn-by-turn with the user |
Coordinator vs Task tool
This pair confuses a design role with the mechanism that implements it. The coordinator is the architectural pattern — an agent that orchestrates. The Task tool (surfaced as the Task/Agent tool) is the concrete capability the coordinator invokes to actually spawn a subagent. Saying "use a coordinator" describes intent; "call the Task tool" describes the button that makes it happen. A coordinator that never calls Task has simply chosen not to delegate yet.
| Dimension | Coordinator (role) | Task tool (mechanism) |
|---|---|---|
| Purpose | Be the orchestrating agent that plans and delegates | Provide the actual call that launches a subagent with a prompt |
| Category | A design pattern / responsibility | A tool in the model's toolset |
| Who decides | N/A — it is the deciding agent | The coordinator model decides whether and how to call it |
| When it appears | Whenever a task needs orchestration | Only at the moment delegation is chosen — one invocation per subagent |
| Context behaviour | Retains the plan and integrates returned results | Each invocation opens a new isolated context for the child and returns its result to the parent |
| Best for | Describing what structure a solution needs | Describing the specific step that creates a worker |
| When NOT to use | Don't call it a tool — it is a role | Don't treat it as a strategy — spawning is a step, not a plan |
Sequential execution vs Parallel Task calls
Both are ways to run multiple pieces of work; the difference is a dependency graph. Sequential execution means each step consumes the previous step's output, so they must be serialized — step 2 literally cannot start without step 1's result. Parallel Task calls means the subtasks are independent, so the coordinator can emit several Task invocations in a single turn and let them run concurrently, then gather the results. The deciding question is never speed for its own sake — it's whether the inputs of one step depend on the outputs of another.
| Dimension | Sequential execution | Parallel Task calls |
|---|---|---|
| Core condition | Steps are dependent — later needs earlier's output | Subtasks are independent — none needs another's result |
| Ordering | Strict order; each waits for the prior | No required order; they fan out at once |
| How it's expressed | One action per turn, feeding the next | Multiple Task calls issued together in the same turn |
| Who decides | The model, based on data flow between steps | The model, once it judges the subtasks share no state |
| Latency | Sum of all steps (slow but necessary) | Roughly the slowest single subtask (concurrent) |
| Best for | Pipelines: fetch → transform → validate → act | Fan-out: three independent lookups, per-file audits, breadth-first research |
| When NOT to use | Don't serialize truly independent work — you waste time | Don't parallelize dependent steps — a worker would run on missing or stale input |
Prompt chaining vs Dynamic decomposition
Both break a big job into smaller steps; the difference is who authors the steps and when. Prompt chaining is a fixed, pre-planned pipeline — you, the designer, wire step 1 → step 2 → step 3 ahead of time, and every run follows that same path. Dynamic decomposition is the agentic loop generating and revising subtasks at runtime — the agent looks at what it just learned and decides what to do next, so the shape of the work isn't known until it runs. Static structure you designed vs. structure the agent discovers.
| Dimension | Prompt chaining | Dynamic decomposition |
|---|---|---|
| Who plans the steps | The human designer, in advance | The agent, at runtime, as it learns |
| When steps are fixed | Before any run — the pipeline is hard-wired | Never fully — the plan adapts to findings |
| Path per run | Same every time | Varies with the inputs and intermediate results |
| Predictability | High — auditable, testable, repeatable | Lower — flexible but harder to fully predict |
| Adaptivity | None; unexpected inputs fall off the rails | High; can branch, add, or drop subtasks mid-task |
| Best for | Well-understood, stable workflows (extract → translate → format) | Open-ended tasks where the needed steps depend on what's found (debugging, research, exploration) |
| When NOT to use | When the required steps can't be known up front | When you need strict, repeatable, auditable behavior every run |
Hooks vs Tool use
This is the pair that most often decides a hard Domain 1 question, because it hinges on which actor is in control. Tool use is a capability the model chooses to invoke inside the loop — it may call a tool, or not, based on its judgment. A hook (e.g. PreToolUse, PostToolUse) is deterministic enforcement the harness runs around tool calls, entirely outside the model's discretion — it fires every time its event occurs, and a PreToolUse hook can block a tool call before it happens. Tool use is a choice; a hook is a guarantee.
| Dimension | Hooks | Tool use |
|---|---|---|
| Who decides / runs it | The harness — configured, deterministic, not up to the model | The model — it elects to call the tool |
| Discretion | None; fires on its event every time | Full; the model may skip or choose a different tool |
| When it runs | Automatically at a lifecycle point (before/after a tool call) | Whenever the model emits a tool call in its turn |
| Guarantee level | Deterministic — a PreToolUse hook can hard-block the action | Probabilistic — depends on the model deciding correctly |
| Purpose | Enforce policy: validate, log, redact, deny, or gate an action | Extend capability: fetch data, run code, act on the world |
| Best for | Rules that must hold every time regardless of the model ("never let a secret reach this tool") | Getting information or performing actions the model needs |
| When NOT to use | Don't use a hook to add optional capability the model should reason about | Don't rely on tool use / prompting to enforce a hard safety rule the model could skip |
Key takeaways
- 01Coordinator and subagent are two roles in one delegation: the coordinator plans, routes, and integrates; the subagent executes one isolated slice and returns a distilled result.
- 02Every subagent gets a fresh, isolated context window and hands back only a summary — that isolation is the entire reason to use one.
- 03A coordinator is a design role; the Task/Agent tool is the mechanism it calls to spawn a subagent. Role vs mechanism, noun vs verb.
- 04Sequential vs parallel is decided by dependencies, not by a wish for speed: output-feeds-input must serialize; truly independent subtasks fan out in one turn.
- 05Prompt chaining is a fixed pipeline the designer wires in advance; dynamic decomposition is the agent generating and revising steps at runtime as it learns.
- 06Tool use is model-chosen capability; a hook is harness-run, deterministic enforcement (PreToolUse/PostToolUse) that fires every time and can block an action.
- 07The recurring discriminator across Domain 1: identify the actor — is the model deciding, or is the harness enforcing?
- 08"Always / never / enforce / regardless of the model" signals a hook; "decide / when appropriate / if needed" signals tool use.
Common mistakes
Calling the coordinator a tool, or the Task tool a strategy.
Keep the layers straight: the coordinator is the orchestrating role, the Task/Agent tool is the concrete call that spawns a subagent. One is a responsibility, the other is an action.
Parallelizing subtasks because the stem says 'for efficiency,' even when one step needs another's output.
Check the dependency graph first. If output A feeds input B, they must run sequentially no matter how much faster parallel sounds. Only fan out genuinely independent work.
Labeling any multi-step agent 'dynamic decomposition' (or any decomposition 'prompt chaining') because both split work into steps.
Decide by authorship and timing: steps fixed by the designer before the run = prompt chaining; steps the agent generates and revises at runtime = dynamic decomposition.
Trusting a tool call or a system-prompt instruction to guarantee a 'never'/'always' safety rule.
Anything the model chooses can be skipped. For a hard guarantee, use a deterministic PreToolUse/PostToolUse hook the harness runs outside the model's discretion.
Assuming a subagent can see the parent's conversation, files already read, or prior decisions.
Subagents start with a fresh, isolated context. Put every path, error message, and decision the worker needs directly into the prompt you pass when spawning it.
Frequently asked
Is a coordinator just a subagent that happens to delegate?
No — they're distinct roles. The coordinator owns the overall plan and integrates results across the whole task; a subagent handles one isolated slice and returns a distilled answer. A coordinator can itself be a subagent of a higher-level agent, but within a given delegation the planner/integrator is the coordinator and the focused worker is the subagent.
If the Task tool is how you spawn a subagent, why distinguish it from the coordinator at all?
Because exam questions test the difference between a role and a mechanism. 'Use a coordinator' describes the architecture you want; 'call the Task tool' is the specific action that realizes it. A question asking for the mechanism wants the Task tool; one asking for the pattern wants the coordinator.
How do I tell in the moment whether steps should be sequential or parallel?
Trace the data. If any step reads a previous step's output, that link must be sequential. If you can give every subtask all its inputs up front and none depends on another, issue them as parallel Task calls in one turn. Speed is a consequence, not the deciding factor.
Isn't dynamic decomposition just prompt chaining with more steps?
No. Step count is irrelevant. Prompt chaining is a pipeline whose steps are fixed before the run and identical every time; dynamic decomposition is the agent inventing and revising steps at runtime based on what it discovers. A ten-step fixed pipeline is still chaining; a two-step adaptive plan is still decomposition.
Why can't I just prompt the model to 'always' do something instead of writing a hook?
Because a prompt or a tool the model chooses can be skipped, misjudged, or reasoned around — it's probabilistic. A hook is run deterministically by the harness at a lifecycle point (e.g. PreToolUse) and can block the action before it happens, so it delivers the every-time guarantee that safety and audit requirements demand.
Independent, unofficial study material. Not affiliated with, endorsed by, or authorized by Anthropic. Every example is original and written to teach the public exam objectives — no real exam questions are reproduced. Technical details reflect Claude, the Anthropic API, Claude Code, and MCP as of July 25, 2026; always confirm specifics against current official documentation.
Test yourself
Turn what you just read into answers you can check.