Subagent Invocation, Context Passing, and Spawning

Subagent Invocation, Context Passing, and Spawning is the single most architecture-dense task statement in the Claude Certified Architect — Foundations (CCA-F) exam. Task 1.3 lives inside Domain 1 (Agentic Architecture and Orchestration, 27% weight, the heaviest on the exam) and decides whether a candidate can actually design the Multi-Agent Research System scenario and the Developer Productivity with Claude scenario — the two scenarios that most directly depend on correctly reasoning about how one agent spawns another, what context travels across that boundary, and which tools the child inherits or is denied.

This study note walks through Subagent Invocation, Context Passing, and Spawning at the depth CCA-F expects: the Task tool as the concrete spawning mechanism, the AgentDefinition shape that declares a subagent, the allowedTools allowlist that scopes what the child can do, the hard rule that subagents do NOT automatically inherit coordinator context, the fork_session semantics for divergent exploration, parallel Task invocations inside a single coordinator response, and the structured metadata-separation patterns that keep multi-agent systems debuggable. Every section is anchored to Anthropic official documentation and to the six scenario clusters the exam draws from. The plain-English analogies at the end bind all of it together for recall under the 120-minute, 60-question pressure of the actual exam.

What Is Subagent Invocation? The Mechanics of Spawning a Child Agent

Subagent Invocation, Context Passing, and Spawning names three distinct but tightly coupled responsibilities. Invocation is the act of asking a running agent to hand off a piece of work to a new agent instance. Context passing is the discipline of deciding which information travels with that handoff. Spawning is the runtime event that creates the child agent with its own isolated conversation history, its own tool allowlist, and its own loop.

In the Claude Agent SDK, the primary invocation surface is the Task tool. When a coordinator agent calls Task, the SDK instantiates a brand-new agent session seeded with the prompt the coordinator supplied, attached to a specific AgentDefinition (which declares the subagent's system prompt, tool allowlist, and optional model override), and runs its own independent agentic loop until it produces a final result. That result is returned as a tool_result message into the coordinator's loop, and the coordinator resumes with that result folded into its context window.

This Subagent Invocation, Context Passing, and Spawning model is fundamentally different from a plain prompt chain: the coordinator does not simply concatenate a follow-up user message and continue its own conversation. It forks execution into a separate context window owned by the child agent. Everything the child knows, it must have been told explicitly via the Task prompt or through a pre-registered AgentDefinition system prompt.

Why Architects Need This Vocabulary

Community exam reports and the CCA-F exam guide both flag subagent context isolation as a top-three misconception. Candidates who assume context flows downward through a hierarchy — the way stack frames inherit variables in a language runtime — design broken multi-agent systems and pick the wrong answer on scenario questions that probe "what does the subagent know when it starts?" The answer is: only what the AgentDefinition system prompt declares plus what the Task tool's prompt parameter explicitly passes. Nothing more.

The Task Tool as the Primary Spawning Mechanism

The Task tool is the concrete verb that turns the coordinator-subagent architecture from a diagram into a runtime. CCA-F candidates must recognize its role as the spawning mechanism — not a generic utility tool, not a custom MCP tool — and must recognize the implications of that role.

Shape of a Task Tool Call

A canonical Task tool invocation from a coordinator carries three key parameters:

• subagent_type — a string identifier that resolves to a registered AgentDefinition. Common values seen in Claude Code agent teams include researcher, critic, planner, coder, or any custom name registered under .claude/agents/.
• description — a short, human-readable label used in logs, traces, and UI surfaces. Not consumed by the subagent itself.
• prompt — the complete instruction payload the subagent will receive as its opening user message. Everything the subagent needs to know about the current task must live here or in the subagent's system prompt.

Under the hood, the SDK takes those three inputs, constructs a fresh session seeded by the matching AgentDefinition, feeds the prompt as the first user message, and runs the child's agentic loop. When the child reaches stop_reason: end_turn, its final message content is captured and returned as the tool_result for the Task call in the coordinator's message history.

Task Must Be Explicitly Allowed

The Task tool is itself an SDK-provided tool that lives on the same allowedTools plane as Read, Write, Edit, Bash, Grep, and custom MCP tools. If an AgentDefinition's allowedTools list does not include "Task", that agent cannot spawn subagents at all. This is a frequent exam trap: candidates assume coordinators inherently have subagent-spawning power, when in fact spawning capability is granted through the same explicit allowlist mechanism as every other tool.

Task Tool vs MCP Tools vs Built-In File Tools

Three distinct tool categories can appear together in a single agent's allowedTools, and CCA-F will test your ability to separate them:

• Task tool — spawns a subagent; provided by the Agent SDK runtime. Not user-authored.
• Built-in tools — Read, Write, Edit, Bash, Grep, Glob. Provided by Claude Code; operate on the local workspace.
• MCP tools — user-registered tools exposed via Model Context Protocol servers. Operate on whatever external capability the server wraps (GitHub, Slack, databases, etc.).

The Task tool is not a custom MCP tool, cannot be re-implemented by an MCP server, and cannot be renamed. Answer choices that conflate Task with "a custom tool you write" are wrong.

AgentDefinition — The Declarative Shape of a Subagent

Every subagent that the Task tool can spawn must be declared as an AgentDefinition. This is the second core artifact CCA-F tests. The exam expects recognition of the AgentDefinition fields and the ability to reason about how those fields shape the subagent's behavior.

AgentDefinition Fields

An AgentDefinition in the Agent SDK or as a Claude Code subagent file (.claude/agents/<name>.md) carries:

• description — a natural-language statement of what the subagent is for. Claude uses this description to decide whether to route a Task call to this particular subagent type when multiple subagents are registered. Treat description like a tool description: it is a routing signal.
• system prompt — the full behavioral charter of the subagent. Declares voice, constraints, preferred output shape, forbidden actions, and any domain knowledge the subagent needs regardless of what any individual Task call passes in.
• tools (allowedTools) — the explicit allowlist of tools the subagent may call. If the parent has Bash but the child AgentDefinition does not list Bash, the child cannot execute Bash. Restrictive by default.
• model — optional model override. A cheap subagent task (bulk summarization) might run on a smaller model while the coordinator runs on a larger one. When omitted, the subagent inherits the session's default model.

Why description Matters for Routing

When a coordinator holds multiple registered subagent types (a researcher, a critic, a summarizer), the coordinator Claude decides which subagent_type to pass to the Task tool based on the natural-language descriptions. Sloppy or overlapping descriptions produce ambiguous routing, the same way sloppy tool descriptions produce ambiguous tool selection. This is the single most common authoring mistake with AgentDefinitions: writing description: "helpful agent" instead of description: "Reads and synthesizes academic papers from arXiv; returns structured bibliographic summaries with page-level citations."

Where AgentDefinitions Live

In Claude Code, AgentDefinitions are stored as markdown files under .claude/agents/<name>.md (project scope) or ~/.claude/agents/<name>.md (user scope). In the Agent SDK (Python or TypeScript), they are passed programmatically as objects to the session constructor. Either form produces the same runtime behavior.

allowedTools — Scoping What the Subagent Can Actually Do

The allowedTools field on an AgentDefinition is the most exam-relevant single parameter in Subagent Invocation, Context Passing, and Spawning. Understanding its semantics prevents a whole class of wrong answers.

allowedTools Is a Strict Allowlist

Whatever is on the list is callable. Whatever is not on the list is not callable — there is no implicit inheritance of the parent's capabilities. A subagent with allowedTools: ["Read", "Grep"] cannot call Write even if its parent coordinator can. This is by design: subagent specialization is enforced at the tool boundary, not hoped for at the prompt boundary.

allowedTools Restricts, Never Expands

A second critical rule: an AgentDefinition cannot grant its subagent more permission than the session's overall configuration allows. If the session is launched in a permission profile that forbids Bash, a subagent that lists Bash in its allowedTools still cannot execute Bash. Allowlists restrict the already-permitted surface; they do not override the session's security envelope.

Common Specialization Patterns

Exam scenarios usually reward specialization:

• A researcher subagent: ["Read", "Grep", "Glob", "WebSearch"] — can explore and read but not modify.
• A critic subagent: [] (no tools) — pure reasoning, cannot touch the filesystem or shell.
• A coder subagent: ["Read", "Edit", "Write", "Bash", "Grep"] — can modify source but may not be allowed to spawn further subagents (no Task).
• A coordinator: ["Task", "Read"] — its job is to orchestrate, not execute, so it holds Task and enough read-only access to see inputs.

Context Isolation — The Rule That Trips Candidates

If there is one Subagent Invocation, Context Passing, and Spawning rule the CCA-F exam hammers, it is this: subagents run with isolated context and do NOT automatically inherit the coordinator's conversation history.

What Isolated Context Actually Means

When the Task tool spawns a subagent, the SDK creates a new session whose message history contains only:

1. The subagent's system prompt (from its AgentDefinition).
2. The prompt string the coordinator supplied in the Task tool call as the first user message.

That is the entire opening state. The coordinator's prior messages, the prior tool_result entries, the prior thinking blocks, the prior user instructions — none of it is visible to the subagent. The subagent does not know what the coordinator has done, what documents it has loaded, or what tools it has called, unless the coordinator packaged that information into the Task prompt.

Why This Design

Context isolation exists for three reasons:

• Context window hygiene — the coordinator's context window might already be 50K tokens deep. Copying that into every subagent would waste the subagent's available tokens and the API bill.
• Specialization fidelity — a focused subagent prompt outperforms a diluted general-purpose conversation dump.
• Security and auditability — a subagent that never saw sensitive upstream data cannot accidentally leak it through its tool calls or its final output.

The Explicit Passing Obligation

Because context does not flow automatically, coordinators that need the subagent to know something must explicitly pass that something in the Task tool's prompt parameter. This is the "must explicit-pass" rule from the exam outline. It looks like:

Task(
  subagent_type="summarizer",
  description="Summarize support ticket thread",
  prompt="""
Summarize the following customer support ticket thread into
a 3-sentence incident description. Thread:
<thread>
  {full_ticket_thread_here}
</thread>
Return only the 3-sentence summary, no preamble.
"""
)

The coordinator is responsible for packaging the thread inside the prompt. If the coordinator relies on the subagent "already knowing" what to summarize, the subagent will hallucinate or refuse.

Context Passing Strategies — Full, Summary, or Structured

Given that coordinators must explicitly package context, the question becomes how. CCA-F recognizes three archetypes. Architects pick one based on the volume of data and the subagent's information needs.

Full History Pass-Through

The coordinator concatenates the relevant conversation or tool outputs verbatim into the Task prompt. Simple, lossless, but expensive in tokens. Useful when the subagent is doing deep reasoning over the same material the coordinator already saw.

Summarized Pass-Through

The coordinator compresses prior context into a short briefing — a few sentences or bullet points — before spawning. Cheaper, but lossy: the subagent cannot recover detail the coordinator dropped. Appropriate when the subagent's task is narrow and only needs an abstract.

Structured Payload Pass-Through

The coordinator packages context as structured data — JSON, XML tags, or a markdown-fenced block — that cleanly separates metadata from the natural-language task instruction. This is the production-grade pattern and the one CCA-F expects architects to recommend for Multi-Agent Research System scenarios.

A structured payload looks like:

<task>
  <goal>Identify any factual inconsistencies</goal>
  <context>
    <source_1 id="arxiv:2301.04567">
      {paper_1_summary}
    </source_1>
    <source_2 id="arxiv:2302.11234">
      {paper_2_summary}
    </source_2>
  </context>
  <instruction>
    Return a JSON array of {claim, source, conflicts_with} objects.
  </instruction>
</task>

The XML-tag separation gives the subagent a clean mental model: goal, then context (with source provenance preserved), then the output instruction. It also makes the subagent's output easier to audit back at the coordinator.

fork_session — Divergent Exploration Without Losing the Trunk

The fork_session mechanism is the third CCA-F pillar of Subagent Invocation, Context Passing, and Spawning. It solves a different problem from Task: not "spawn a child that does a bounded piece of work" but "explore an alternative path from the current session while keeping the original session intact."

What Forking Gives You

A fork creates a copy of the current session's state — message history, tool call history, whatever the SDK persists — as a new session with its own session_id. Actions taken in the fork do not affect the trunk. You can run experiments, roll back mistakes, or explore hypothetical branches.

fork_session vs Task

The two mechanisms are distinct and CCA-F will test the distinction:

• Task creates a fresh, context-isolated subagent seeded only by an AgentDefinition and a prompt. Used for delegating a bounded unit of work.
• fork_session duplicates an existing session's full state into a new branch. Used for divergent exploration, A/B testing tool strategies, or rollback-safe experimentation.

If a scenario asks "how do you let a researcher agent try two different database queries without losing the original context?", the answer is fork_session — spawn two forks, run a query in each, compare results, discard the losing fork.

Forking Does Not Duplicate Permissions or Tool Grants Beyond the Session

A frequently-tested subtlety: forking inherits message history but does not magically grant the fork additional tool permissions or elevate the session's security profile. If the trunk couldn't call Bash, neither can the fork. Fork is a memory operation, not a permission operation.

Parallel Task Calls — Fan-Out in a Single Coordinator Response

The Agent SDK allows the coordinator Claude to emit multiple tool_use blocks in a single assistant response, including multiple Task calls. The SDK runs those subagents in parallel and returns their tool_result messages together once all have completed.

Why Parallel Spawning Matters

For the Multi-Agent Research scenario, a coordinator that needs three perspectives on the same question can spawn three specialist subagents concurrently rather than sequentially:

• researcher_arxiv — searches arXiv and returns findings.
• researcher_github — searches GitHub and returns findings.
• researcher_web — searches web and returns findings.

All three run in parallel; the coordinator sees all three tool_result messages at once; it synthesizes the combined evidence. Sequential spawning would multiply latency by 3 and delay every downstream step.

When NOT to Fan Out

Parallelism is wrong when the subtasks are dependent — when subagent B needs subagent A's output as input. Fanning out dependent subtasks produces either failures (B doesn't have A's data) or wasted work (B proceeds with stale assumptions). Dependent subtasks should be chained sequentially; independent subtasks should be fanned out.

Spawning Depth Limits and Recursive Subagents

Subagents can themselves spawn further subagents if their AgentDefinition includes "Task" in allowedTools. This produces a tree of agents. Without depth limits, a buggy or runaway planning agent could recurse until budget explodes.

Practical Depth Ceilings

CCA-F does not test a specific numeric depth limit, but it does test the recognition that:

• Depth is bounded in practice by whether intermediate AgentDefinitions include Task in their allowedTools.
• Common hygiene: only the outermost coordinator holds Task; leaf specialists do not.
• Tree shape is a design decision, not a runtime accident.

Preventing Runaway Trees

The safest default is shallow hierarchies: one coordinator at the root, one tier of specialist leaves, no further recursion. If deeper hierarchies are truly needed, each intermediate tier's allowedTools should carry Task explicitly and its AgentDefinition system prompt should enforce a budget ("you may spawn at most two children").

Synchronous vs Asynchronous Invocation

From the coordinator's perspective, a Task call is synchronous within the coordinator's own loop: the coordinator issues the tool_use, waits for the tool_result, resumes. The SDK runs the subagent to completion before returning. There is no "fire and forget" primitive exposed at the Task tool layer.

What Parallel Calls Do NOT Do

Parallel Task calls in a single assistant response do run concurrently with each other, but the coordinator still waits for all of them to complete before continuing. There is no callback, event stream, or promise object exposed through the Task tool interface. CCA-F will test scenarios where candidates might wrongly propose "fire the Task call and proceed" — the correct answer is that the coordinator's loop will always block on tool_result for any Task it emits.

Implications for Latency-Sensitive Scenarios

For Customer Support Resolution Agent scenarios where the end user is waiting, the architect must think carefully about spawning depth and fan-out width. Three parallel subagents each taking 8 seconds will block the coordinator for 8 seconds (the slowest one), not 24. But a sequential chain of three 8-second subagents will block for 24 seconds. Fan-out is the latency tool.

Return Value Handling in the Coordinator Loop

When a subagent ends its loop with stop_reason: end_turn, its final assistant message content becomes the tool_result body for the originating Task call. The coordinator Claude reads that tool_result as part of its next turn's input.

What the Coordinator Actually Sees

The coordinator sees:

• A tool_use block the coordinator itself emitted.
• A tool_result block with the subagent's final text as content.

The coordinator does NOT see the subagent's intermediate tool_use and tool_result messages, its thinking blocks, or its step-by-step reasoning — only the final output. This is why well-designed subagents produce crisp, structured final outputs; everything a downstream coordinator needs must be in that last message.

Output Shaping Patterns

Two common patterns for structuring subagent final output:

• Free-form summary — for exploratory tasks where the coordinator will reason over qualitative findings.
• Structured JSON or XML block — for tasks whose output is machine-consumed by the coordinator (e.g. the coordinator will parse the subagent's JSON and feed fields into the next step). This pairs cleanly with the Structured Data Extraction scenario.

Permission Inheritance vs Restriction — Recap

Pulling the permission threads together into a single mental model:

• Parent session permission envelope — the outer bound; nothing inside can exceed this.
• Coordinator allowedTools — restricts coordinator to a subset of the envelope. Must include Task to spawn.
• Subagent AgentDefinition allowedTools — restricts the subagent to its own subset, bounded by the envelope (not by the coordinator's list). Must include Task if the subagent is itself allowed to spawn.

Each layer is a restriction. None is an expansion. The exam tests this at the scenario level: "the coordinator has Bash, the researcher subagent does not list Bash — can the researcher call Bash?" Answer: no.

Plain-Language Explanation: Subagent Invocation, Context Passing, and Spawning

Abstract ideas become portable when anchored to physical systems. Three analogies cover the full surface of Subagent Invocation, Context Passing, and Spawning.

Analogy 1: The Delegating Manager and the New Hire

A project manager gets a large cross-functional task. They cannot do all the work themselves. Instead, they write up a brief — a self-contained document that explains the goal, the context, the constraints, the expected output format — and they hand that brief to a specialist contractor the company hired for exactly this kind of work. The contractor walks into the meeting room with only that brief. The contractor did not sit in on the manager's morning planning meetings, did not read the manager's email thread, did not overhear the customer call. If the brief is incomplete, the contractor will either guess or come back and ask.

This is exactly how Subagent Invocation, Context Passing, and Spawning works. The coordinator Claude is the manager. The AgentDefinition is the contractor's job description (what they specialize in, what tools they bring). The Task tool is the act of handing over the brief. The prompt parameter is the brief itself. The subagent walks in with only the brief plus its own specialization — nothing more. If the coordinator forgets to put the customer's ticket text in the brief, the summarizer subagent cannot summarize what it never saw.

This analogy maps every core term:

• Coordinator = the manager delegating.
• AgentDefinition = the contractor's role description and licensed toolkit.
• Task tool call = the act of handing over a brief.
• prompt parameter = the brief's contents.
• allowedTools = the contractor's permitted tools (no welding allowed if they didn't bring a welding license).
• Isolated context = the contractor has not been at your previous meetings.

Analogy 2: The Open-Book Exam with Pre-Prepared Cheat Sheet

Consider a student taking an open-book exam. They can bring one pre-prepared cheat sheet, nothing else. The student's knowledge during the exam consists of: the cheat sheet they prepared, plus whatever they already knew before walking in (their training, their coursework). The exam proctor sitting outside the room has detailed personal notes from every lecture — but those notes are inaccessible to the student during the exam.

The subagent is the student. The cheat sheet is the Task prompt. The student's pre-existing knowledge is the AgentDefinition system prompt. The proctor is the coordinator, with rich context the student cannot see. If the proctor wants the student to know something, the proctor must write it on the cheat sheet before the student enters the exam room. The moment the exam starts, the door is closed. The student cannot phone home for more context.

This analogy pins down why explicit context passing is non-negotiable and why summarized or structured passing trades token cost for legibility. The cheat sheet has limited space; what goes on it matters.

Analogy 3: The Kitchen Brigade with Isolated Prep Stations

A head chef in a busy restaurant runs the pass. Orders come in; the head chef reads the full ticket and decides who cooks what. The head chef delegates the sauce to the sauce cook, the protein to the grill cook, the garnish to the garde manger. Each specialist stands at their own prep station with their own tools — the sauce cook has whisks and pans, the grill cook has tongs and a live flame, the garde manger has tweezers and chilled bowls. The sauce cook cannot reach the grill; the grill cook cannot reach the chilled herbs. The head chef, on the expediting line, holds the full ticket and a clearboard marker — their tool is coordination, not direct cooking.

When the head chef delegates "plate the sauce," the sauce cook gets a precise instruction ("hollandaise, 2oz, warm plate") but does not get the full dinner reservation note, the server's gossip about the VIP table, or the wine pairing decisions. Each specialist works with exactly what they need and no more.

This is Subagent Invocation, Context Passing, and Spawning from the top-down:

• Head chef = coordinator with Task tool.
• Prep stations = subagent runtime instances.
• Each cook's tool rack = allowedTools per AgentDefinition.
• Delegated instruction = Task prompt.
• Finished dish returned to the pass = tool_result returned to coordinator.
• Fan-out across the brigade = parallel Task calls in one coordinator response.
• Forking a station to try two different sauce reductions = fork_session for divergent exploration.

Which Analogy to Use on Exam Day

• Questions about why the subagent doesn't know what the coordinator knows → open-book-exam analogy.
• Questions about who can use which tool → kitchen brigade analogy.
• Questions about the delegation contract and what belongs in the prompt → delegating manager analogy.

Multi-Agent Research System Scenario Mapping

The Multi-Agent Research System scenario is the single tightest fit for Subagent Invocation, Context Passing, and Spawning on the CCA-F exam. A canonical exam setup:

"A team builds a research system where a coordinator agent dispatches three specialized researchers — one for arXiv, one for GitHub, one for web. The researchers must work in parallel, must not see each other's intermediate findings, and must return structured citations."

The correct architecture uses:

• Three AgentDefinitions (one per source), each with a narrow tool allowlist and a system prompt that enforces citation format.
• A coordinator AgentDefinition with "Task" in allowedTools plus minimal other tools.
• Parallel Task calls emitted in a single coordinator response, each with a structured XML payload identifying the research question and the expected citation schema.
• tool_result aggregation in the coordinator, which then synthesizes across the three returned JSON blocks.
• Optional fork_session if the coordinator wants to explore two alternative synthesis strategies before committing to one.

Wrong answers on this scenario typically:

• Merge all three researchers into a single subagent (loses parallelism, conflates specializations).
• Rely on context inheritance instead of explicit structured payloads (subagents will hallucinate).
• Give every subagent the "Task" tool (invites runaway recursion).
• Use fork_session where Task is appropriate (forks inherit history — wasteful for independent research streams).

Developer Productivity with Claude Scenario Mapping

The Developer Productivity with Claude scenario layers Subagent Invocation, Context Passing, and Spawning on top of Claude Code's built-in file tools. A canonical exam setup:

"An engineer wants Claude Code to review a pull request by running three specialist passes: a type-safety pass, a test-coverage pass, and a security pass. Each should have its own tool allowlist. The engineer wants the three passes to run in parallel where possible."

The correct architecture:

• Register three AgentDefinitions as subagent markdown files under .claude/agents/: type-check-reviewer, test-coverage-reviewer, security-reviewer.
• Each with a narrow allowedTools set: Read and Grep only for type-check and security, plus Bash (scoped) for test-coverage so it can invoke the test runner.
• A top-level Claude Code session acts as coordinator, holds Task in its allowedTools.
• The coordinator spawns all three reviewers in parallel via a single assistant turn with three Task tool_uses.
• Each reviewer returns a structured findings block; the coordinator synthesizes and presents a unified review.

This scenario rewards candidates who recognize that AgentDefinitions can be file-backed, that parallel Task fan-out is the right latency play, and that minimal per-subagent allowedTools is a security feature, not a limitation.

Common Exam Traps — Subagent Invocation, Context Passing, and Spawning

Five traps recur across CCA-F questions on Subagent Invocation, Context Passing, and Spawning. Memorize each.

Trap 1: Task Tool Treated as a Custom Tool

Answer choices may describe "writing a custom Task tool via MCP." Wrong. The Task tool is an Agent SDK built-in, not something you implement. Reject any answer that suggests authoring Task as a user-defined tool.

Trap 2: Context Flowing Down Automatically

The single most punished misconception. Subagents start with empty message history save for their system prompt and the Task prompt. Any answer implying "the subagent has access to the coordinator's conversation" is wrong unless the coordinator explicitly passed that conversation in the prompt.

Trap 3: allowedTools Inheritance

Candidates assume the subagent inherits the coordinator's tool list. It does not. An AgentDefinition's allowedTools is the definitive, standalone allowlist. Omit a tool and it cannot be called.

Trap 4: allowedTools as Permission Grant Beyond the Session Envelope

allowedTools can only restrict the already-allowed surface. Listing Bash on a subagent definition in a session where Bash is disabled at the security profile does not enable Bash. Restrict, never expand.

Trap 5: Conflating Task with fork_session

Task spawns a fresh, context-isolated subagent. fork_session duplicates the current session's history into a new branch. Scenarios where the goal is "continue reasoning with full prior context on an alternate branch" need fork_session; scenarios where the goal is "delegate a bounded unit of work to a specialist" need Task. Picking the wrong mechanism costs questions.

Practice Anchors — Task 1.3 Scenario Question Templates

CCA-F practice questions on Subagent Invocation, Context Passing, and Spawning cluster into five recurring shapes. The detailed question bank lives in the ExamHub CCA-F practice exam; the template shapes are:

Template A: Spawning Mechanism Identification

"An architect wants a coordinator agent to delegate a summarization task to a specialist. Which SDK-provided tool should the coordinator invoke?" Correct answer: Task. Distractors: "a custom MCP tool named 'delegate'", "Read", "any tool on the allowedTools list."

Template B: allowedTools Reasoning

"A subagent's AgentDefinition lists [Read, Grep]. The coordinator's allowedTools lists [Read, Grep, Bash, Task]. Can the subagent execute Bash?" Correct answer: No. allowedTools does not inherit from the coordinator.

Template C: Context Isolation Question

"A coordinator agent has been processing a multi-turn customer conversation. It spawns a summarizer subagent with Task. What does the summarizer see at startup?" Correct answer: Its AgentDefinition system prompt plus whatever the coordinator supplied in the Task prompt parameter. Distractors: "the coordinator's full message history", "the last assistant message of the coordinator", "everything the coordinator has read via Read."

Template D: Task vs fork_session Selection

"A researcher agent wants to try two database query strategies while preserving the ability to roll back to its current state. Which mechanism should it use?" Correct answer: fork_session. Distractor: Task (wrong because Task doesn't preserve full history in the branch, and the goal is exploration, not delegation).

Template E: Parallel Fan-Out Recognition

"A coordinator must research the same question across three independent sources and synthesize findings. Which pattern minimizes latency?" Correct answer: Emit multiple Task tool_use blocks in a single coordinator response so the SDK runs subagents in parallel. Distractor: "Chain three sequential Task calls" (correct but inferior; exam typically marks parallel as best).

Subagent Invocation, Context Passing, and Spawning Frequently Asked Questions (FAQ)

What is the Task tool and why is it specific to the Agent SDK?

The Task tool is the Agent SDK's built-in spawning mechanism. Calling Task with a subagent_type, description, and prompt creates a fresh subagent session bound to the corresponding registered AgentDefinition. The SDK runs the subagent's agentic loop in an isolated context window and returns the final output as a tool_result back to the coordinator. It is specific to the Agent SDK because spawning is a runtime primitive, not something a user-authored tool can implement faithfully — the SDK must wire the child session, serialize the AgentDefinition, run the subagent's loop, and route the result back into the parent's message history.

Do subagents inherit the coordinator's conversation history?

No. This is the most frequently tested misconception on CCA-F. Subagents run with isolated context. When the Task tool spawns a subagent, the subagent's opening message history contains only its AgentDefinition's system prompt and the prompt string the coordinator passed into the Task call. The coordinator's prior messages, tool_results, and reasoning are not visible to the subagent. If the coordinator needs the subagent to know something, the coordinator must explicitly package that information inside the Task prompt parameter.

What is in an AgentDefinition and why does description matter?

An AgentDefinition is the declarative spec of a subagent. It carries a description (routing signal used by the parent Claude to pick which subagent_type to spawn), a system prompt (the subagent's behavioral charter), an allowedTools list (the subagent's tool allowlist), and an optional model override. The description matters because, when a coordinator holds multiple registered subagent types, the parent Claude selects among them by reading descriptions — vague or overlapping descriptions produce ambiguous routing. Treat description like a tool description: specific, verb-shaped, and bounded in scope.

How does allowedTools interact with the coordinator's tool permissions?

allowedTools is a strict allowlist that can only restrict, never expand. A subagent can only call tools listed in its own AgentDefinition's allowedTools. The subagent does not inherit the coordinator's tools, and it cannot exceed the session's overall permission envelope. If the session is launched under a profile that disables Bash, listing Bash in the subagent's allowedTools will not enable it. Conversely, a coordinator must include the Task tool in its own allowedTools for spawning to be possible — spawning capability is governed by the same allowlist mechanism as every other tool.

When should I use fork_session instead of the Task tool?

Use Task when you want to delegate a bounded piece of work to a specialist subagent that does not need to see the full coordinator history. Use fork_session when you want to continue reasoning from the current session's exact state along an alternate branch — hypothesis testing, A/B tool-strategy exploration, or rollback-safe experimentation. Forks inherit the full message history at the moment of forking; Task subagents start from empty history seeded only by their AgentDefinition. The rule of thumb: Task is delegation, fork is exploration.

Can a coordinator spawn multiple subagents in parallel?

Yes. The Agent SDK allows a coordinator to emit multiple tool_use blocks — including multiple Task calls — in a single assistant response. The SDK runs those subagents concurrently and returns all their tool_result messages once each has completed. This parallel fan-out is the correct pattern for independent subtasks (e.g. three research streams on different sources) because latency is bounded by the slowest subagent, not by the sum of subagent durations. Parallel fan-out is wrong when subtasks are dependent — chain those sequentially so downstream subagents can consume upstream outputs.

Can subagents themselves spawn further subagents?

Yes, if their AgentDefinition includes "Task" in allowedTools. This produces a multi-tier tree. In practice, CCA-F rewards shallow hierarchies: one coordinator at the root holding Task, one tier of specialist leaves that do not hold Task. Deeper trees are possible but introduce recursion risk, debugging complexity, and budget explosion if an intermediate tier enters a spawn loop. When designing, default to shallow; justify depth explicitly.

Further Reading

• Claude Certified Architect — Foundations Exam Guide v0.1: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Session management — Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Tool use overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags

Related ExamHub topics: Multi-Agent Orchestration with Coordinator-Subagent Patterns, Agentic Loops for Autonomous Task Execution, Agent SDK Hooks for Tool Call Interception, Session State, Resumption, and Forking.