Send request → read stop_reason → if "tool_use", execute tools and append results, then repeat; if "end_turn", terminate. stop_reason is the only authoritative control signal — not prose.

Tool results must be appended to the conversation context so the model can incorporate the new information into its reasoning for the next action.

Model-driven: Claude reasons from conversation context to pick the next tool. Pre-configured: a fixed sequence or decision tree picks for it, regardless of what was just learned.

Three anti-patterns the exam guide names verbatim:

• Parsing natural language signals to determine loop termination
• Setting arbitrary iteration caps as the primary stopping mechanism
• Checking assistant text content as a completion indicator

All three are replaced by one rule: terminate when and only when stop_reason == "end_turn".

One coordinator owns all inter-subagent communication, routing, and error handling. Subagents never talk to each other directly — all traffic passes through the coordinator, giving full observability and consistent error handling.

No on both. Each subagent starts with isolated context — no inherited history, no shared memory. Pack every fact a subagent needs directly into its prompt.

Five things the coordinator owns:

• Analyze query complexity
• Dynamically select only the needed subagents
• Partition scope to minimize duplication
• Route all inter-subagent traffic
• Aggregate results and re-delegate on gaps

Always running the full pipeline ignores query complexity and wastes capacity.

Iterative refinement: identify the gaps → re-delegate targeted queries to search and analysis subagents → re-invoke synthesis. Repeat until coverage is sufficient.

The Task tool. The coordinator's allowedTools list must include "Task" — without it, the coordinator cannot invoke any subagents regardless of its prompt.

AgentDefinition sets the subagent's description, system prompt, and tool restrictions. Subagents inherit nothing — they begin each invocation with no prior context unless explicitly provided in the prompt.

Emit all three Task tool calls in a single coordinator response — not spread across separate turns. Multiple calls in one response trigger concurrent execution; separate turns make them sequential.

Include complete findings from prior agents with structured metadata (URLs, document names, page numbers) for attribution. Frame as research goals + quality criteria — not step-by-step procedure — to preserve subagent adaptability.

Gates block tool calls deterministically — they cannot be bypassed. Prompt instructions (and few-shot examples) describe desired order but have a non-zero failure rate. Gates are required when deterministic compliance is non-negotiable (e.g., identity verification before financial operations).

A programmatic prerequisite gate that blocks process_refund until get_customer has returned a verified customer ID. This is a code-level check — not a system-prompt instruction, which could be bypassed.

Decompose into distinct items → investigate each in parallel using shared context → synthesize a unified resolution. Never investigate independent issues serially when they can run concurrently.

Customer ID, root cause of the issue, refund amount (or relevant financial figures), and recommended action — everything the human needs to act without reading the conversation transcript.

It intercepts a tool's result before the model sees it, used to normalize heterogeneous data formats — e.g., converting Unix timestamps, ISO 8601, and numeric status codes from different MCP tools into one consistent format.

It blocks the model's outgoing tool call when it would violate a hard policy — e.g., blocking process_refund when amount > 500 and redirecting to escalate_to_human. The tool call never executes.

Use hooks when business rules require guaranteed (deterministic) compliance — prompts are probabilistic. PostToolUse runs after execution, so it cannot prevent a call. Use a PreToolUse / interception hook to block before the call runs.

Chaining: predictable multi-aspect work with known steps (e.g., code review). Wrong fit: open-ended investigation where next steps are unknown. Dynamic: open-ended work where subtasks emerge from discoveries. Wrong fit: routine reviews — adds variance with no gain.

Attention dilution: quality loss when a single pass must reason about too much at once. Prevention: split into per-file local analysis passes (bugs, logic) followed by a separate cross-file integration pass (data flow, interfaces).

Dynamic decomposition: map the codebase structure → identify high-impact areas → create a prioritized plan → adapt the plan as dependencies and gaps are discovered. Do not force a fixed sequence upfront.

• --resume <name> — continue when prior context is mostly valid (inform the session of any file changes).
• fork_session — parallel divergent exploration from a shared baseline (e.g., compare two refactoring strategies).
• Fresh + injected summary — when prior tool results are stale; a structured summary beats replaying outdated context.

Inform the resumed session about which specific files changed so it can do targeted re-analysis of only those areas — not a full re-exploration of the entire codebase.

Start fresh with a structured injected summary. Stale tool results mislead the model — cached outputs that no longer match current system state cause incorrect reasoning. A fresh, accurate summary is always more reliable.