1.3 — Subagent Invocation & Context Passing · Core
- The
Task tool spawns a subagent. The coordinator's allowedTools must include "Task" — without it, no delegation is possible. This is a hard requirement, not a convention.
AgentDefinition configures a subagent's identity: name, system prompt, description, and allowed tools. Each subagent type gets its own definition — e.g. a web_search agent whose definition pins allowed_tools to ["web_search"] only, with no Write or Bash — and scoping its tools to its role is what keeps it from misusing capabilities outside its specialisation.- Pass findings as structured data with provenance, not a vague summary — include source URLs, document names, page numbers, and publish dates alongside every claim so attribution survives synthesis.
fork_session branches an independent copy of the session from a shared baseline — use it to explore two approaches (e.g. two testing strategies) in parallel without either contaminating the other.- System prompts define persistent specialisation; dynamic content (changed files, the current PR diff, this turn's findings) is passed per invocation, not baked into the definition.
A coordinator configured with allowedTools = ["Read", "Grep"] cannot spawn any subagent — the list is simply missing "Task". This is a common trap: the orchestration design can be entirely correct on paper and delegation still silently fails because of one missing tool name.
1.4 — Multi-Step Workflow Enforcement & Handoff · Core
- A programmatic prerequisite is a code-level gate that blocks a tool until a required earlier step has completed, enforced deterministically by the system, not by the model.
- Prompt instructions have a non-zero failure rate — always. Production data shows agents skipping a mandated identity-verification step in 12% of cases even when explicitly told not to. When the consequence is financial or safety-critical, deterministic enforcement is the only reliable fix — not a more emphatic prompt, not few-shot examples, and not a routing classifier (that fixes tool availability, which is the wrong problem when the issue is tool ordering).
- Multi-concern requests ("I have a damaged item AND a billing issue") decompose into distinct items, investigate each in parallel using shared context, then synthesise a single unified response — replying to only the loudest concern and dropping the other is the failure mode this guards against.
- Escalation handoff goes to a human agent with no access to the conversation transcript — the handoff document is their only context. A complete handoff includes: customer ID, root-cause analysis, refund/transaction amounts, and a recommended next action. An incomplete handoff (raw output with no root cause or recommendation) forces the human to redo the investigation from scratch.
- Checkpoints save intermediate state to persistent storage; on restart the system resumes from the last completed checkpoint, never from the beginning — re-running a 40-step batch job from step 1 after a crash at step 35 is the anti-pattern the exam flags.
1.5 — Hooks: Pre vs Post ToolUse · Core
PreToolUse (tool-call interception) = block/gate BEFORE execution — e.g. verify identity before a refund, or block any refund over $500 and redirect straight to human escalation, with zero model discretion in the decision.PostToolUse = normalise/enrich results AFTER execution, before the model ever sees them.- Deterministic over probabilistic for financial / compliance / security — use hooks, not prompt instructions, whenever a business rule requires guaranteed compliance rather than likely compliance. The distinction the exam draws: a hook runs in code outside the model's control; a system-prompt instruction is a request the model can still fail to follow.
⚠ Often-missed — PostToolUse for Multi-Tool Normalisation · Gap
When multiple tools return different currencies / units / timestamp formats / status codes (one MCP tool returns Unix timestamps, another ISO 8601, another numeric codes), a PostToolUse hook normalises ALL of them to a common shape before Claude sees the results — so the model reasons over consistent data instead of silently misinterpreting one tool's format as another's.
1.6 — Task Decomposition Strategies · Core
Two decomposition styles, and the exam tests choosing correctly between them:
- Fixed sequential pipeline (prompt chaining) — use when the aspects are known in advance and predictable (standardised forms, fixed CI steps, repeatable report formats). For a large code review, the proven shape is per-file local passes + a separate cross-file integration pass.
- Dynamic / adaptive decomposition — use when the work is open-ended and subtasks depend on what's discovered along the way (multi-dimensional research, variable-structure documents, "add comprehensive tests to a legacy codebase"): map the structure first, identify high-impact areas, then build a plan that adapts as dependencies surface.
- Hybrid routing: classify the input at intake — e.g. tag an incoming document "standard invoice" (fixed pipeline: extract → validate → file) vs "unstructured contract" (dynamic: map structure, then decide what to extract) — fixed decomposition for standard templates, dynamic decomposition for free-form input.
- Recognise when no decomposition is needed at all — a single well-defined task handled directly beats an over-engineered multi-agent pipeline; not every request justifies a coordinator and subagents.
⚠ Often-missed — Attention Dilution in Single-Pass Review · Gap
A single pass across 14+ files gives inconsistent depth, misses obvious bugs, and can even contradict itself — flagging a pattern in one file while approving identical code in another. The root cause is attention dilution, not a capability gap, and a bigger context window does not fix it. The fix is splitting into per-file local passes plus one cross-file integration pass (see 1.6).
1.7 — Session Management · Core
--resume <session-name> — continue a specific named session across work sessions when the prior context is still mostly valid; naming the session (claude --resume refactor-auth-module) is what makes it findable later, instead of relying on the most-recent anonymous session.fork_session — branch independent copies from a shared baseline to compare two divergent strategies (e.g. JWT vs OAuth2) without cross-contamination; each branch explores its approach with the same starting context but neither sees the other's findings.- Resume vs. start fresh is the key judgment call:
- Resume when prior context is mostly still valid — after a small code change, tell the resumed session exactly which files changed so it re-analyses only those targets instead of re-exploring everything.
- Start fresh with an injected summary when prior tool results are stale (e.g. after 35 schema migrations) — a clean, structured summary of what's still valid beats resuming on top of out-of-date tool outputs the model may still trust.
- Be aware of
/compact risk — it can drop exact values during summarisation; protect critical facts with a persistent case-facts block (see Domain 5.1).
⚠ Often-missed — Structured State Persistence / Crash Recovery · Gap
Periodically export a JSON manifest: goal + processed files + remaining files + key entities. On recovery, start a fresh agent and inject the manifest — far more reliable than resuming a long, stale session that's dragging outdated tool results behind it.
Exam reflexes for Domain 1
- "Text-matching loop sometimes never stops" → branch on
stop_reason, not message text.
- "Narrow results from multi-agent" → fix the coordinator's decomposition, not the subagents.
- "Subagents passing results to each other directly" → route through the coordinator — direct hops break observability.
- "Parallel agents" → multiple
Task calls in ONE response.
- "Subagent can't be spawned" → check
allowedTools includes "Task".
- "Must guarantee a step happens" (refund/identity) → programmatic gate (PreToolUse), not a prompt.
- "Agent crash recovery" → periodic JSON manifest + inject on resume.
- "Escalation to a human" → handoff doc needs ID + root cause + amounts + recommended action.
- "14+ files reviewed inconsistently" → per-file passes + one integration pass, not a bigger context window.
- "Two approaches to compare in parallel" →
fork_session, not sequential --resume.
- "Large-scale changes since last session" → start fresh + inject a structured summary, don't resume.