Configure subagent invocation, context passing, and spawning
What you should be able to do
- Spawn subagents with the Task tool, and know that a coordinator needs it in allowedTools to do so.
- Pass complete prior findings in the subagent's own prompt, because nothing is inherited between invocations.
- Keep source metadata structurally separate from content so attribution survives synthesis.
- Emit parallel Task calls in a single response, and use fork-based sessions to branch from a shared baseline.
Exam traps (6)
Configure the subagent definitions and expect the coordinator to start delegating.
Left out of allowedTools, the invocation falls through to the permission callback and is denied in a headless run — and Claude quietly does the work itself rather than reporting that it could not delegate.
Delegation is a tool permission before it is a prompt instruction: the spawn tool has to be in allowedTools.
Write the synthesis prompt as "summarise the findings above".
There is no "above" — the subagent has no shared memory with the agents that ran before it, so it invents a plausible summary of nothing.
Everything a subagent needs is in the prompt you hand it, in full.
Flatten findings into readable prose before passing them on.
URLs, document names and page numbers dissolve into the sentences, so the final report cannot cite what it drew on. The failure only shows up at the end.
Use a structured format that keeps content and its metadata in separate fields the whole way down the chain.
Delegate to each subagent in turn, waiting for each to return before starting the next.
Independent work is serialised for no reason, and the coordinator's own context grows with each round trip.
Emit multiple Task calls in one coordinator response to spawn them in parallel.
Write the coordinator prompt as a numbered procedure so the subagents behave predictably.
A procedure fixes the plan before any evidence exists, so subagents cannot adapt when a source turns out to be empty or a lead opens up.
State the goal and the quality bar; leave the route to the agent that can see what came back.
Restrict what a subagent can do by limiting the tools available in the coordinator's session.
A subagent's permitted tools come from its own agent definition — the description, system prompt and tool restrictions it is declared with. Scoping the parent does not scope the child, so the restriction reads as applied and is not.
Declare the restriction on the subagent's own definition. A subagent's blast radius should be a property of how it is defined, not of wherever it happened to be spawned.
Where the guide and the current docs differ (1)
the name of the spawn tool
Answer this: Subagents are spawned with the Task tool, which the coordinator needs in allowedTools.
The docs now say: The tool was renamed from Task to Agent in Claude Code v2.1.63, and allowedTools governs auto-approval rather than existence — omitted, the invocation falls through to the permission callback and is denied in a headless run. Read it
Primary sources
- Agent SDK — subagentschecked 2026-08-15
- Agent SDK — sessionschecked 2026-08-15
Know cold
- Task tool
- allowedTools
- Subagent
- fork_session
- Provenance
12 practice questions in the bank are tagged to this task statement.
Practise this task in context: open it inside the interactive study guide, which carries the concept cards, the mock quiz and the practice simulation.