What you will be able to do
- Decompose a multi-concern customer request into distinct items and investigate them in parallel subagents
- Pass shared context into each subagent explicitly, knowing that subagents start with a fresh conversation
- Use SubagentStop and Stop hooks to collect findings and confirm every concern is resolved before finishing
- Compile a self-contained handoff summary for a human agent who cannot see the transcript
1.Split the request, then investigate each concern in parallel
Customers rarely raise just one problem. "I was charged twice, and my shipping address is wrong" is two investigations with different tools and different data. If one agent works through both in a single thread, the evidence for each piles up in the same context.
Anthropic's agent-design guidance names the pattern for this. Sectioning means breaking a task into independent subtasks that run in parallel, and "For complex tasks with multiple considerations, LLMs generally perform better when each consideration is handled by a separate LLM call". When the concerns aren't known in advance, the orchestrator-workers variant has "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." Anthropic's multi-agent post describes the same three steps: decompose into independent facets, run subagents concurrently, synthesize.
async def research_topic(query: str) -> dict:
# Lead agent breaks query into research facets
facets = await lead_agent.decompose_query(query)
# Spawn subagents to research each facet in parallel
tasks = [
research_subagent(facet)
for facet in facets
]
results = await asyncio.gather(*tasks)
# Lead agent synthesizes findings
return await lead_agent.synthesize(results)Map this onto the support ticket. The facets are "billing: duplicate charge" and "account: address." Each one goes to its own subagent, which you can restrict to the tools it needs, because "subagents can be limited to specific tools, reducing the risk of unintended actions."
The phrase "using shared context" hides a practical point. Each subagent "runs in its own conversation, which starts fresh unless the subagent is a fork." A fresh subagent doesn't know the verified customer ID, the order number, or what the customer already said. The coordinator has to write those shared facts into every subagent's prompt. If it doesn't, each subagent repeats the lookup or guesses.
Know what parallelism costs. Independent subtasks finish in the time of the slowest one rather than the sum of all of them. But multi-agent systems typically use 3 to 10 times more tokens, and Anthropic says plainly: "The primary benefit of parallelization is thoroughness, not speed."
Checkpoint 1 of 5· Check yourself
A coordinator verifies a customer, then spawns a billing subagent with the prompt "Investigate the duplicate charge." The subagent's first action is to ask which customer this is. What is the right fix?
A non-fork subagent starts with a fresh conversation, so anything it needs from the coordinator's context has to be written into the prompt it receives.
“each subagent runs in its own conversation, which starts fresh unless the subagent is a fork”Source: code.claude.com
2.Collect every finding before writing one resolution
Synthesis can only work with what comes back. Intermediate tool calls stay inside each subagent, and "only its final message returns to the parent." So ask each subagent to end with a compact, structured finding: what it checked, what it concluded, and what it recommends.
The coordinator also needs to know when every subagent has actually finished. The SDK has lifecycle hooks for this. SubagentStart fires at subagent initialization, with "Track parallel task spawning" as its example use. SubagentStop fires on subagent completion, with the example use "Aggregate results from parallel tasks." Comparing the subagents that started with the ones that stopped tells you whether anything is still outstanding.
The last risk is finishing too early: one concern answered, the other forgotten. A Stop hook covers this, because for Stop and SubagentStop prompt hooks a blocking reason "is fed back to Claude as its next instruction and the turn continues". The docs' example evaluator checks that all requested tasks are complete:
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "prompt",
"prompt": "You are evaluating whether Claude should stop working. Context: $ARGUMENTS\n\nAnalyze the conversation and determine if:\n1. All user-requested tasks are complete\n2. Any errors need to be addressed\n3. Follow-up work is needed\n\nRespond with JSON: {\"ok\": true} to allow stopping, or {\"ok\": false, \"reason\": \"your explanation\"} to continue working.",
"timeout": 30
}
]
}
]
}
}Checkpoint 2 of 5· Exam question
A team registers three independent PreToolUse hooks for process_refund: one checks identity verification, one checks fraud score, and one logs the attempt for audit. On one ticket, the verification hook returns "deny" while the fraud-score hook returns "allow" and the logging hook returns an empty object. What happens to the tool call?
Correct answer: D — The call is blocked, because when multiple hooks disagree, a "deny" from any hook overrides "allow" results from the others
- A. Incorrect. Deny outranks ask in the priority order, so a mixed result does not fall back to a manual-approval prompt when one hook already denied it.
- B. Incorrect. All matching hooks' outputs are considered together; an empty object from one hook does not remove it from the resolution, and deny still overrides allow.
- C. Incorrect. Decisions are not resolved by majority vote; a single deny is sufficient to block the call regardless of how many other hooks allowed it.
- D. Correct. When several hooks fire for the same event, the most restrictive decision wins: deny takes priority over defer, which takes priority over ask, which takes priority over allow.
Checkpoint 3 of 5· Match them up
Match each hook event to its role in a multi-concern workflow
Tap a term, then the definition that fits it.
The SDK hooks table gives each event's trigger and example use. Gating, tracking, aggregating and the final completeness check each belong to a different point in the lifecycle.
“Subagent completion | Aggregate results from parallel tasks”Source: code.claude.com
3.Escalating mid-process: the structured handoff summary
Sometimes the investigation shows the agent shouldn't finish the case itself. It might need a policy exception, or the refund might exceed what the agent is authorized to approve. The case then goes to a human, and the human usually can't see the conversation transcript.
The sources don't define a schema for human handoffs. What they do document is the constraint that makes a schema necessary. Every boundary in a multi-agent system passes a summary, not a history. A subagent's intermediate work stays behind and "only its final message returns to the parent." A human taking over an escalated case is in the same position: the handoff message is all they get.
The exam guide therefore expects a structured summary that a stranger can act on without asking anything:
- Customer ID: the verified identity, so the human doesn't re-verify or open the wrong account. - Root cause: what the investigation found, such as "duplicate authorization captured twice," not just "customer reports double charge." - Refund amount: the specific figure in question. - Recommended action: what the agent suggests and why it couldn't do it itself, such as "approve refund; exceeds automated limit."
A summary that says "customer is upset about billing, see conversation" fails, because there is no conversation the human can see. On the delivery side, the SDK's Notification hook exists for exactly this kind of routing. Its listed use case is sending agent status updates to Slack or PagerDuty.
Checkpoint 4 of 5· Exam question
A support agent has two tools, get_customer and process_refund. The team's system prompt says "Always call get_customer and confirm the identity before calling process_refund." During testing, the agent occasionally calls process_refund first when a ticket is phrased as an urgent complaint. The architect wants this ordering to hold every time, not just most of the time. What should they implement?
Correct answer: B — A PreToolUse hook matched to process_refund that checks for a verified customer ID in session state and returns permissionDecision "deny" when none exists
- A. Incorrect. A larger context window helps retention of information but does not create a hard block on calling process_refund out of order.
- B. Correct. A PreToolUse hook is programmatic enforcement: it inspects state before the tool executes and can deny the call outright, so the ordering holds regardless of how the prompt is phrased.
- C. Incorrect. Rewording the same prompt-based instruction still leaves compliance dependent on the model following it; it does not close the non-zero failure rate the architect is trying to eliminate.
- D. Incorrect. An injected reminder is still a prompt-based nudge the model can override under unusual phrasing; it is not a gate on the tool call itself.
Checkpoint 5 of 5· Check yourself
An agent escalates a disputed charge to a human supervisor who cannot see the transcript. Which handoff is most useful?
Only the structured summary gives the recipient identity, cause, amount and next step in one self-contained message. Option A points to a transcript the human can't see, and option D carries no information.
“only its final message returns to the parent”Source: code.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Subagents spawned by a coordinator can already see the customer details established earlier in the parent conversation.Why is that wrong?
A non-fork subagent starts with a fresh conversation. Shared facts such as the verified customer ID have to be passed in the prompt the coordinator writes.
Covered in Split the request, then investigate each concern in parallel
2.The main reason to fan out a multi-concern request to parallel subagents is to make the whole job faster and cheaper.Why is that wrong?
Anthropic identifies thoroughness as the main benefit. Multi-agent systems typically use several times more tokens and can take longer overall.
Covered in Split the request, then investigate each concern in parallel
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/agent-sdk/subagentsOfficial docs
“each subagent runs in its own conversation, which starts fresh unless the subagent is a fork”
↩︎ Split the request, then investigate each concern in parallel“independent subtasks finish in the time of the slowest one rather than the sum of all of them”
↩︎ Split the request, then investigate each concern in parallel“subagents can be limited to specific tools, reducing the risk of unintended actions”
↩︎ Split the request, then investigate each concern in parallel“only its final message returns to the parent”
↩︎ Collect every finding before writing one resolution“intermediate tool calls and results stay inside the subagent; only its final message returns to the parent”
↩︎ Escalating mid-process: the structured handoff summary“each subagent runs in its own conversation, which starts fresh unless the subagent is a fork”
↩︎ Exam trap 1“only its final message returns to the parent”
↩︎ Checkpoint - 2.https://www.anthropic.com/engineering/building-effective-agentsSecondary source
“For complex tasks with multiple considerations, LLMs generally perform better when each consideration is handled by a separate LLM call”
↩︎ Split the request, then investigate each concern in parallel“a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.”
↩︎ Split the request, then investigate each concern in parallel - 3.
“Multi-agent systems typically consume 3 to 10 times more tokens than single-agent approaches for equivalent tasks.”
↩︎ Split the request, then investigate each concern in parallel“The primary benefit of parallelization is thoroughness, not speed.”
↩︎ Exam trap 2 - 4.https://code.claude.com/docs/en/agent-sdk/hooksOfficial docs
“Subagent completion | Aggregate results from parallel tasks”
↩︎ Collect every finding before writing one resolution“Subagent initialization | Track parallel task spawning”
↩︎ Collect every finding before writing one resolution“Send agent status updates to Slack or PagerDuty”
↩︎ Escalating mid-process: the structured handoff summary - 5.https://code.claude.com/docs/en/hooksOfficial docs
“is fed back to Claude as its next instruction and the turn continues”
↩︎ Collect every finding before writing one resolution