- In short
- The Task tool is the mechanism a coordinator uses to spawn a subagent in Claude Code, and an AgentDefinition declares that subagent description, system prompt, and tool restrictions. A coordinator can only spawn a subagent when the spawning tool is listed in its allowed tools, so configuration is the gate that makes delegation possible.
What the Claude Code Task tool actually does
The Claude Code Task tool is the one verb in a multi-agent design: it is how a coordinator hands a focused job to a fresh subagent. When the coordinator decides a side task would otherwise flood its own context with logs, search results, or file contents it will never reuse, it emits a Task tool call naming a subagent. That subagent spins up in its own context window, does the work, and returns a single summary message to the coordinator. Everything else about orchestration is built from this one move repeated.
Crucially, the Task tool does not contain the subagent's instructions. It only names which subagent to run and supplies a prompt for that run. The standing configuration of the subagent, what it is for and what it may touch, lives in a separate object called an AgentDefinition. Keeping the two ideas apart, the call that spawns versus the definition that configures, is what this knowledge point is really testing.
- Task tool and AgentDefinition
- The Task tool is the call a coordinator emits to spawn a subagent; the AgentDefinition is the declaration that gives that subagent its description, system prompt, and allowed tools. The call selects a worker, the definition configures it.
How an AgentDefinition is structured
An AgentDefinition is a small record with two required fields and several optional ones. The required fields are description, a natural-language statement of when this subagent should be used, and prompt, the system prompt that defines the subagent role and behaviour. Both carry real weight: the description is how Claude decides whether a task matches this worker, and the prompt is the only standing instruction the subagent carries into its fresh context.
The optional fields tune the subagent further. tools is an allow-list of tool names; omit it and the subagent inherits every tool the coordinator can use, supply it and the subagent is sandboxed to just those tools. There is a matching disallowedTools to subtract specific tools, a model override so a cheap worker can run on a smaller model, and a skills list to preload domain knowledge. For the foundations exam you mainly need the first three: a subagent is a description, a prompt, and a tool boundary.
Why the spawning tool must be in the coordinator allowed tools
Here is the trap that catches more candidates than any other on this knowledge point. Defining a subagent is necessary but not sufficient. The coordinator can only spawn anything if the spawning tool itself is present in the coordinator's own allowed-tools list. Leave it out and the AgentDefinition sits there, perfectly valid, while every attempt to delegate is silently never approved. The system looks broken even though each piece is individually correct.
The mental model to carry into the exam is a two-key lock. Key one is the AgentDefinition, which says a worker of this kind exists and here is when to use it. Key two is the coordinator's permission to call the spawning tool at all. Both keys must turn. This is also why the hub-and-spoke pattern you met in hub-and-spoke architecture only works once the hub is actually permitted to dispatch its spokes.
The Task and Agent naming nuance
There is a versioning detail worth knowing so a question cannot trip you on vocabulary. In Anthropic's documentation the spawning tool was historically called the Task tool, and newer Claude Code releases renamed it the Agent tool. The two names refer to the same mechanism, and current tooling still surfaces the older name in some places, such as the initial tools list, while emitting the newer name in tool-use blocks. For the exam, treat "include Task in the allowed tools" and "include Agent in the allowed tools" as the same instruction: the coordinator must be permitted to spawn.
What never changes is the contract. The spawning tool selects a subagent and passes it a prompt string; the subagent runs in isolation; the coordinator gets back one message. The label on the verb moved, but the request-response shape underneath it, the same one you studied in the Messages API request-response cycle, did not.
Sizing the tool boundary for a subagent
The optional tools field is where most of the design judgement lives, and the exam likes candidates who understand it. Omitting the field entirely means the subagent inherits every tool the coordinator can use, which is convenient but rarely what you want for a focused worker. Supplying an explicit allow-list sandboxes the subagent to exactly those tools, so a documentation reviewer gets Read, Grep, and Glob and can never accidentally write a file. When you want almost everything but need to subtract a few capabilities, disallowedTools removes named tools from whatever the subagent would otherwise inherit.
Two further levers round out the boundary. The model field lets a cheap, high-volume worker run on a smaller model such as Haiku while the coordinator stays on a stronger one, which controls cost without rewriting the design. And there is a rule that catches the unwary: a subagent cannot spawn its own subagents, so you must not place the spawning tool in a subagent's own tool list. A worker is a leaf in the tree, not another branching coordinator. Knowing that the tool boundary both enables and constrains a subagent, and that it has these specific knobs, is exactly the recall this knowledge point rewards.
A spawn-readiness checklist
Before a coordinator can delegate reliably, four things have to line up, and walking them mentally is a fast way to debug a stuck design. First, the spawning tool is present in the coordinator's allowed tools, so the call can be approved at all. Second, the target subagent has an AgentDefinition with a description specific enough that Claude can recognise when the task matches it. Third, the prompt the subagent will run under is self-contained, because the worker sees nothing of the parent conversation. Fourth, the subagent's tool list is scoped to what the job actually needs and excludes the spawning tool itself.
Miss any one of these and the failure mode is quiet rather than loud. A missing spawning tool means nothing delegates; a vague description means Claude does the work itself; a thin prompt means the subagent flounders for lack of context; an over-broad tool list means a worker can take actions it should not. Running this checklist turns a mysterious "my subagents do not work" into a precise diagnosis, which is the practical literacy the foundations exam is checking you have.
How this is tested on the exam
Domain 1 weighs agentic orchestration heavily, and this knowledge point is the gateway to every other subagent topic in task statement 1.3. Questions tend to be diagnostic rather than definitional. A scenario describes a coordinator that defines three subagents but nothing ever gets delegated, and you must name the cause. Or a scenario gives a subagent a brilliant prompt but a useless one-word description and asks why Claude keeps doing the work itself. The correct answers trace back to the two ideas here: the spawning tool must be allowed, and the description is what Claude matches against.
Because this is a remember-level knowledge point, you are expected to recall the structure precisely rather than reason about a novel design. Know that a subagent is spawned by the Task tool, configured by an AgentDefinition, and that the description and the allowed-tools gate are the two pieces people most often get wrong.
Worked example
An engineer builds a coordinator that should delegate code review to a read-only reviewer subagent, but no review ever happens and the coordinator does the review inline.
The engineer writes a clean AgentDefinition for a code-reviewer subagent: a description that says it is a security and quality review specialist, a focused prompt, and a tools list of Read, Grep, and Glob so the reviewer can inspect but never modify files. On paper this is exactly right.
Yet every run ends with the coordinator reading and critiquing the code itself, never spawning the reviewer. The reviewer subagent is never invoked, so its careful read-only sandbox is irrelevant. Nothing errors; the work just lands in the wrong place.
The fix is one line of configuration. The coordinator allowed-tools list omitted the spawning tool, so the coordinator was never permitted to delegate at all. Adding the spawning tool (Task, or Agent in newer releases) to the coordinator allowed tools turns the second key in the lock. Now the description matches the review task, the spawn is approved, and the reviewer runs in isolation and returns a summary. The lesson the exam wants: a valid AgentDefinition does nothing until the coordinator can actually call the spawning tool.
Common misreadings to avoid
Misconception
Once I write an AgentDefinition for a subagent, the coordinator can spawn it.
What's actually true
Misconception
The AgentDefinition description is just documentation, so anything readable will do.
What's actually true
From definition to delegation
Once you can spawn a subagent reliably, the rest of task statement 1.3 builds directly on top. What you put in the spawn prompt becomes structured context passing; how you phrase the goal becomes goal-based versus step-based prompts; emitting several Task calls at once becomes parallel subagent spawning. Each of those assumes you already know that a subagent is a Task call plus an AgentDefinition, which is exactly the foundation this page lays.
It is worth knowing one escape hatch that sits beside all this configuration. Even without writing any AgentDefinition at all, a coordinator can delegate to a built-in general-purpose subagent, provided the spawning tool is in its allowed tools. That built-in worker is handy for one-off research or exploration where defining a bespoke specialist would be overkill. The lesson reinforces the same theme: the gating permission to call the spawning tool is what unlocks delegation, while the AgentDefinition is what specialises it. Recall both halves and you can explain any stuck or surprising delegation behaviour the exam puts in front of you, from a coordinator that never spawns to one that spawns the wrong kind of worker.
A developer defines a well-written 'data-migration' subagent with a clear description, a detailed prompt, and a restricted tools list. When they run the coordinator, the migration work is always done by the coordinator itself and the subagent is never spawned. What is the most likely cause?
People also ask
How do you spawn a subagent in Claude Code?
What fields does an AgentDefinition have?
Why is my coordinator not spawning subagents?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Creating a subagent
Why watch: Walks through configuring an AgentDefinition with description, prompt, and tool restrictions spawned via the Task tool.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.