1.3 Subagent Invocation & Context Passing

Lesson 1.2 left us with a striking fact: a subagent starts completely blank. It inherits none of the coordinator's history, sees none of its peers' work, and remembers nothing between invocations. That isolation keeps each context clean — but it creates an obvious practical problem. If a worker remembers nothing, how do you actually get useful work out of them?

The answer is the whole subject of this lesson, and it comes down to one channel. Imagine sending a brand-new contractor into a locked room to do a job. You can't shout instructions through the wall, and there's no shared filing cabinet inside. The ONLY thing you can do is slide a single sheet of paper under the door before they start. Whatever is on that sheet is everything they'll have. If you forget to write down the customer's name, they'll never know it.

For a subagent, that sheet of paper is the prompt string you pass when you spawn it. It is the one and only channel from coordinator to subagent. Master what goes on that sheet — and what the subagent already has versus what it's missing — and you've mastered Task Statement 1.3.

Before we fill in the brief, how does a coordinator spawn a subagent at all? Through a special tool called the Agent tool. (You may see it called the Task tool — that was its name until Claude Code v2.1.63 renamed it to Agent; the old name still works, and the exam guide still says 'Task'. Treat them as the same thing.) Spawning a subagent is, mechanically, just the coordinator calling this tool — the same tool_use mechanism from Lesson 1.1, where the 'tool' happens to be 'start a subagent and give it this brief.'

There's one gate you must not forget: for a coordinator to use the Agent tool, its list of allowed tools must INCLUDE the Agent (or Task) tool. This is a simple on/off switch. Leave it out and the coordinator literally cannot spawn anyone — and the frustrating part is it fails silently: the coordinator just does the work itself or gives up, with no error telling you the door was locked. If a coordinator mysteriously refuses to delegate, this is the first thing to check.

One more rule that surprises people: a subagent cannot spawn its own subagents. The hierarchy is exactly one level deep — coordinator at the top, workers below, full stop. So you never put the Agent tool in a subagent's own tool list. This is a deliberate guard against runaway nesting where agents spawn agents spawn agents.

"Starts blank" is the headline, but the precise truth is a little richer and worth getting exactly right, because the exam probes it. A subagent's context isn't literally empty — it just doesn't contain the PARENT's conversation. Let's lay out exactly what it does and doesn't receive.

And what comes BACK? Only the subagent's final message. All the intermediate work — every tool call it made, every file it read, every dead end it explored — stays sealed inside the subagent's own context and never reaches the coordinator. This is precisely the point of subagents: a research subagent can read fifty files, and the coordinator receives only the tidy two-paragraph summary, not fifty files' worth of clutter. That's how subagents protect the coordinator's context from overflowing — the very benefit from Lesson 1.2, now you can see the mechanism.

Now the craft: what makes a GOOD brief? This matters most when you chain subagents — search feeds analysis feeds synthesis — because that's where information gets lost in transit. The exam tests the consequence directly, so let's understand it through a failure first.

Suppose your synthesis subagent produces a beautiful report, but none of its claims are cited. Your instinct says "the synthesis agent is broken." Almost always, it isn't. Remember: synthesis only knows what was written on its brief. If the coordinator passed it the raw claims but stripped away WHERE each came from — the source URL, the document name, the page — then synthesis literally has no citations to include. It's not a synthesis bug; it's a context-passing bug. You handed the contractor the conclusions but not the references.

Three rules prevent this. First, pass COMPLETE prior findings into the brief — don't make the subagent re-derive what an earlier stage already found. Second, use STRUCTURED data that keeps content and its metadata together, so the source travels alongside every claim through every hop. Third, write the brief around the GOAL and quality bar, not a rigid step-by-step procedure — that preserves the subagent's ability to adapt while still constraining the outcome.

Two practical mechanics round out the picture. First, parallelism — the source of the speed-up from Lesson 1.2. If the coordinator emits SEVERAL Agent tool calls in a single response, those subagents run at the same time. If instead it spawns one, waits, then spawns the next on a later turn, they run sequentially and you lose the whole benefit. So for independent work, fire all the delegations in one response. (For coordinating dozens or hundreds of agents, there's a heavier-duty Workflow tool that moves orchestration into a script — but for a handful of subagents, parallel Agent calls are the tool.)

Second, how you actually DEFINE a subagent in code: the AgentDefinition. Two fields are required — description (a plain-language note on WHEN to use this subagent, which is what lets the coordinator auto-decide to delegate to it) and prompt (its system prompt — its role and instructions). Everything else is optional but useful: tools (omit and it inherits all; specify and it's restricted — least privilege), model (pick 'haiku' for cheap/fast, 'opus' for hard reasoning, or 'inherit'), and more.

Every 1.3 trap grows from one of two misconceptions: that context is somehow inherited, or that a downstream agent is to blame for data the coordinator never actually passed it. Once you internalise 'the brief is the only channel,' these become easy to spot.

• •Assuming inheritance. ✗ Believing a subagent can see the parent's history or another subagent's results. ✓ It can't — only what's in its brief; pass everything explicitly.
• •Blaming the synthesizer. ✗ Concluding the synthesis agent is broken when its report lacks citations. ✓ The coordinator stripped the source metadata in transit — fix the context passing, not the synthesizer.
• •Spawning sequentially. ✗ Delegating independent tasks across separate turns, one at a time. ✓ Emit multiple Agent calls in one response so they run in parallel.
• •Over-specifying the brief. ✗ Writing a rigid step-by-step procedure that kills the subagent's adaptability. ✓ Specify the goal and quality criteria; let the subagent choose how.

You now know how spawning works (the Agent tool and its gate), exactly what crosses the boundary, how to write a brief that preserves attribution, how to parallelise, and the AgentDefinition shape. The exercise makes the citation failure vivid — once you've watched citations vanish and reappear, you'll never strip metadata again.

This lesson completes the 'how' of multi-agent systems. Next, Lesson 1.4 shifts from coordinating agents to GUARANTEEING behaviour — using your code's control over the loop to make certain steps happen every single time, no matter how the model is prompted.