Skip to content

Domain 1 — Mixed Scenario Quiz

Agentic Architecture & Orchestration — Exam Style

Each question has one best answer. The task statement each question targets (1.1–1.7) is noted in the heading and confirmed in the Answer Key. Use the collapsible block to self-test before revealing the rationale.

Question 1: The "let me check that" stall (1.1)

A coding assistant frequently replies "Sure, let me run the tests" and then stops without running anything. Logs show the response had stop_reason: "tool_use" with a leading text block, but the loop returned after inspecting response.content[0].type.

What is the correct fix?

A) Force tool_choice: "any" so Claude always calls a tool.
B) Drive loop control off stop_reason: continue on tool_use, terminate only on end_turn.
C) Raise max_tokens so the text block is never truncated.
D) Add a system-prompt line: "Always actually run the tool you mention."

Answer **B.** Claude can emit text and `tool_use` blocks in the same response. The authoritative loop signal is `stop_reason`, not the type of the first content block. This is the canonical premature-termination bug.

Question 2: Natural-language completion signal (1.1)

A workflow agent stops whenever Claude's text contains "I'm done" or "that completes the task," parsed by a regex. Occasionally Claude says "I'm done reviewing the first file" and the loop ends while real work remains.

What is the root problem?

A) The regex needs more completion phrases.
B) Natural-language phrasing is being used as the termination signal instead of stop_reason.
C) The model should be told never to use the word "done" mid-task.
D) The iteration cap is too high.

Answer **B.** Parsing natural language for completion is an anti-pattern because phrasing is ambiguous. Terminate on `end_turn`; do not infer completion from prose.

Question 3: The iteration cap as primary stop (1.1)

A team sets MAX_ITERATIONS = 8 and treats hitting the cap as the normal way the agent finishes. Complex multi-step tasks now return truncated answers because Claude was still productively calling tools at iteration 8.

What is the best critique?

A) The cap should be removed entirely.
B) The cap is only a runaway-loop safety net; primary termination must come from stop_reason (end_turn).
C) The cap should be lowered to 3 for safety.
D) Claude should be prompted to finish within 8 turns.

Answer **B.** Iteration caps guard against runaway loops but must not be the primary stop condition. Useful work is cut off when the cap, not `end_turn`, decides completion.

Question 4: Tool result never reaches Claude (1.1)

An agent calls get_invoice, the app executes it, but on the next request the app sends only the original user message plus the assistant's tool_use. Claude re-requests the same lookup every turn.

What is missing?

A) A larger context window.
B) A user message containing a tool_result block whose tool_use_id matches the original tool_use.id.
C) tool_choice: "none" on the follow-up call.
D) A retry with higher max_tokens.

Answer **B.** Claude can only reason over a tool's output if the matching `tool_result` is appended to history before the next call. Executing the tool without returning the result leaves Claude blind to it.

Question 5: max_tokens is not a transport failure (1.1)

A summarization service intermittently returns cut-off summaries. Logs show HTTP 200 with stop_reason: "max_tokens". An engineer is catching it in the same handler as 5xx errors.

What is the correct handling?

A) Treat it as a transport failure and retry the whole request as-is.
B) Treat the output as truncated-but-valid: tune max_tokens and add continuation/truncation handling.
C) Ignore the field; partial summaries are always acceptable.
D) Force tool_choice: "any".

Answer **B.** `max_tokens` means Claude hit the output cap, not that the API failed. Handle it as truncation, not as an HTTP exception.

Question 6: Server-side tool pause (1.1)

An agent using a server-side web-search tool returns stop_reason: "pause_turn". The client currently discards the assistant turn and re-sends the original prompt from scratch.

What should it do instead?

A) Convert pause_turn to end_turn and return the partial answer.
B) Send the assistant response back in the message history and continue the loop.
C) Disable the search tool permanently.
D) Treat it as a refusal.

Answer **B.** `pause_turn` signals that a server-side sampling loop needs continuation. Append the assistant response and continue; restarting from scratch loses progress.

Question 7: Refusal handling (1.1)

A response returns HTTP 200 with stop_reason: "refusal". The application only has an error path for non-200 responses, so it shows the user a blank screen.

What is the right design?

A) Treat refusal as a successful response state and route to a fallback or escalation path.
B) Retry the request in a tight loop until it does not refuse.
C) Assume the API is down and page on-call.
D) Suppress the response silently.

Answer **A.** `refusal` is a stop reason on a successful (200) response, not an exception. Handle it with a graceful fallback, not transport-level error handling.

Question 8: Ordered side effects in one turn (1.1)

Claude returns two tool_use blocks in a single turn: create_customer and create_invoice. The invoice needs the customer ID produced by the first call.

What is the safest execution strategy?

A) Run both in parallel for speed.
B) Avoid parallel execution here; sequence the operations so create_invoice uses the ID from create_customer.
C) Drop create_customer and ask the user for the ID.
D) Execute only the first block and end the loop.

Answer **B.** The API does not prescribe execution order, but parallelism is unsafe when one mutation depends on another's result. Sequence dependent side effects even when both calls arrive in one turn.

Question 9: When NOT to go multi-agent (1.2)

A team wants to summarize a single short support ticket and draft a reply. They propose a coordinator plus researcher, policy, tone, and reviewer subagents.

What is the best architecture?

A) Use all five agents because specialization always improves quality.
B) Use a single agent unless there is evidence the task needs decomposition.
C) Use parallel fan-out to cut latency.
D) Refuse; tickets cannot be summarized reliably.

Answer **B.** Multi-agent orchestration adds cost and coordination overhead. A small, low-ambiguity task should stay single-agent; orchestration is justified by complexity, specialization, isolation, or parallelism — not prestige.

Question 10: Narrow coordinator decomposition (1.2)

A research system is asked to survey "renewable energy technologies." The coordinator splits the work into only "solar" and "wind." The search agents do excellent work and the synthesizer combines it accurately, yet the final report omits geothermal, tidal, and biomass.

Where does the failure trace back to?

A) Weak search-agent performance.
B) Poor synthesis by the coordinator.
C) The coordinator decomposed the task too narrowly.
D) Too few sources were available.

Answer **C.** When the output is incomplete in *scope* despite good search and synthesis, the root cause is narrow decomposition at the coordinator. Naming the full scope in the goal guards against this.

Question 11: Concatenation vs synthesis (1.2)

Three research subagents return conflicting recommendations. The coordinator's final answer reads: "Agent A said X. Agent B said Y. Agent C said Z."

What should the coordinator do instead?

A) Pick the longest of the three outputs.
B) Reconcile the findings using evidence, resolve or flag conflicts, and produce one integrated recommendation with caveats.
C) Return all three verbatim and let the user decide.
D) Discard the conflicting findings.

Answer **B.** Synthesis is not concatenation. The coordinator must combine findings, reconcile disagreements on evidence, fill gaps, and map back to the original goal.

Question 12: Direct subagent-to-subagent chatter (1.2)

To "save a round trip," an engineer proposes letting the research subagent send its findings directly to the synthesis subagent, bypassing the coordinator.

Why is this discouraged?

A) It is faster and therefore always preferred.
B) All inter-agent communication should flow through the coordinator for observability, consistent error handling, and controlled context flow.
C) Subagents are physically unable to produce output.
D) It violates the model's token budget.

Answer **B.** Coordinator-mediated routing centralizes logging, recovery policy, and exactly-what-context-each-agent-sees. Direct subagent-to-subagent communication is an exam trap even when it sounds efficient.

Question 13: Specialize by capability, not by fragment (1.2)

A team assigns one agent to write paragraph 1 of a memo, another for paragraph 2, and another for paragraph 3.

What is wrong with this specialization?

A) Nothing; finer fragmentation always helps.
B) Agent boundaries should reflect capability or independence, not arbitrary surface structure like paragraph order.
C) Each paragraph needs its own model.
D) The coordinator should write all paragraphs itself.

Answer **B.** Specialize by capability boundary (research, security, docs) or by independent work units — not by arbitrary slices of one cohesive artifact.

Question 14: Evaluator without criteria (1.2)

A critic agent reviews generated code and replies "looks good to me," yet the merged code later fails a security requirement.

What was missing from the evaluator design?

A) A larger model.
B) An explicit rubric / acceptance criteria (tests, security requirements, source evidence) for the evaluator to check against.
C) A higher iteration cap.
D) More prose in the critic's prompt.

Answer **B.** "Ask another agent if it looks good" is weak. Evaluator agents need explicit, checkable criteria; otherwise the generator-evaluator loop provides little assurance.

Question 15: Coordinator cannot delegate (1.3)

A coordinator is supposed to call specialized subagents but the logs show it never invokes any of them and tries to do all the work itself. The subagent definitions look fine.

What is the most likely cause?

A) The subagents have weak system prompts.
B) The coordinator's allowedTools does not include Task (a.k.a. Agent).
C) The subagents lack fork_session.
D) The coordinator's max_tokens is too low.

Answer **B.** Delegation happens through the `Task`/`Agent` tool. If it is not in `allowedTools`, the capability literally does not exist and the coordinator falls back to doing the work itself. Adding more subagent definitions changes nothing.

Question 16: Subagent context is not inherited (1.3)

A coordinator runs a search subagent, then spawns a synthesis subagent with the prompt "Now synthesize the findings." The synthesis agent produces a vague, uncited answer.

What is the first thing to check?

A) Whether the synthesis agent's model is large enough.
B) Whether the coordinator actually passed the prior agents' findings into the synthesis prompt.
C) Whether fork_session was enabled.
D) Whether the synthesis agent has web-search tools.

Answer **B.** Subagents inherit no history, system prompt, or other agents' results. The prompt is the only channel. Thin output usually means the coordinator under-packaged the context — suspect context passing before blaming the subagent.

Question 17: Parallel spawning mechanics (1.3)

You want three independent search subagents to run concurrently for speed.

How should the coordinator invoke them?

A) Emit one Task call, await its result, then emit the next, across three turns.
B) Emit three Task tool calls in a single coordinator response.
C) Call fork_session three times.
D) Set disable_parallel_tool_use: true.

Answer **B.** Parallel subagents are launched by batching multiple `Task` calls into one response, just like parallel tool use. Spreading them across turns serializes them.

Question 18: Preserving attribution across handoff (1.3)

The synthesis agent's report loses all source citations even though the upstream search agents found good sources.

What design change fixes this?

A) Tell the synthesis agent to "remember to cite."
B) Pass findings as structured data that separates content (claims) from metadata (URLs, doc names, pages, dates).
C) Give the synthesis agent its own web-search tool to refind sources.
D) Increase the synthesis agent's max_tokens.

Answer **B.** Attribution is lost when findings are flattened to prose. Structured content-plus-metadata carries the citations through the handoff so the synthesis agent can attribute each claim.

Question 19: Goals vs procedures in delegation prompts (1.3)

Which delegation prompt produces the most adaptable, highest-quality subagent behavior?

A) "Run query A, then query B, then summarize the first three results."
B) "Call the search tool exactly twice and stop."
C) "Find authoritative, recent evidence covering all major subtopics; cite every claim; flag gaps. You decide the queries."
D) "Do your best."

Answer **C.** Delegation prompts should specify goals and quality criteria, not step-by-step procedures. Over-prescription (A, B) caps quality at what the author anticipated; D under-specifies.

Question 20: Re-invoking the same subagent (1.3)

A coordinator calls the web_search subagent a second time and expects it to remember what it found on the first call.

What actually happens?

A) The second call automatically has the first call's context.
B) The second Task spawn is independent and knows nothing of the first unless the coordinator re-injects that information.
C) The subagent shares memory across invocations by default.
D) The second call inherits the coordinator's full history.

Answer **B.** A fresh `Task` spawn carries no memory of prior invocations. To build on earlier work, the coordinator must pass the relevant prior output into the new prompt.

Question 21: The 12% skip problem (1.4)

Production data shows that in 12% of cases the agent skips get_customer and calls lookup_order with only the customer's stated name, occasionally misidentifying accounts and issuing incorrect refunds.

What most effectively addresses this reliability issue?

A) Add a programmatic prerequisite that blocks lookup_order and process_refund until get_customer returns a verified customer ID.
B) Strengthen the system prompt to make verification mandatory.
C) Add 5–8 few-shot examples of correct ordering.
D) Add a routing classifier that enables only the right tool subset.

Answer **A.** Critical ordering with financial consequences requires deterministic enforcement. A prerequisite gate guarantees the sequence that prompts (B, C) only make more likely; routing (D) addresses tool *availability*, not *ordering*.

Question 22: Wrong hook to block an action (1.4 / 1.5)

A team implements refund blocking using a PostToolUse hook that inspects the refund and rejects oversized ones.

What is the flaw?

A) PostToolUse cannot read tool arguments.
B) PostToolUse fires after the tool executes, so the refund has already happened.
C) PostToolUse only works for subagents.
D) There is no flaw.

Answer **B.** Prevention must happen pre-execution. `PostToolUse` runs after the tool ran and is suited to transforming or auditing results, not blocking actions. Use `PreToolUse`.

Question 23: Where verification state lives (1.4)

An agent must verify identity before refunds. Where should the "customer verified" fact be stored so a gate can enforce it?

A) As a sentence in Claude's conversation history.
B) In explicit workflow/application state (code/DB) that the prerequisite gate reads.
C) In a closing summary paragraph.
D) In a Markdown formatting rule.

Answer **B.** Authoritative business state must be machine-checkable and durable. A natural-language sentence the model wrote is not reliably checkable and can be hallucinated or lost to compaction.

Question 24: The weak handoff (1.4)

A support agent escalates to a human with the message: "Customer has a billing problem." The human cannot see the chat.

Why is this inadequate, and what is required?

A) It is too technical; simplify it.
B) It is not self-contained — the human lacks the transcript, so the handoff must carry customer ID, summary, root cause, amount, actions taken, and a recommended action.
C) It should be written in XML.
D) It should include the model's full chain of thought.

Answer **B.** The receiving human has no access to the conversation. A strong handoff is self-contained and decision-ready, turning the escalation into an approve/deny decision rather than a fresh investigation.

Question 25: Multi-concern request on shared context (1.4)

A customer says: "Return my order, update my shipping address, and check my loyalty points."

What is the correct workflow?

A) Answer only the first concern.
B) Open three separate, unrelated conversations, one per concern.
C) Decompose into distinct concerns, investigate the independent items in parallel on the shared (same verified customer) context, then synthesize one unified response.
D) Escalate the whole thing to a human immediately.

Answer **C.** Identity and account context are gathered once and reused across the sibling concerns; the independent items are investigated in parallel and synthesized into a single reply, with any unresolved item escalated via a structured handoff.

Question 26: Block .env writes (1.5)

A developer puts "never edit .env files" in the system prompt. Claude later attempts to edit .env.

What is the best fix?

A) Make the prompt more emphatic.
B) Add a PreToolUse hook or a deny rule that blocks .env edits before execution.
C) Use PostToolUse to complain after the edit.
D) Increase the model size.

Answer **B.** Sensitive-file protection must be enforced before execution. Prompts guide probabilistically; a `PreToolUse` hook or deny rule enforces deterministically.

Question 27: Hook allow does not override deny (1.5)

A PreToolUse hook returns allow for a tool call, but a configured deny rule also matches that call.

What is the result?

A) The tool runs because hooks are evaluated first.
B) The tool is denied, because hook allow does not skip later deny (or ask) rules.
C) The user is always prompted.
D) The hook is ignored entirely.

Answer **B.** A hook can deny outright, but a hook returning `allow` does not bypass deny/ask rules; the overall priority favors deny. Do not assume one allow setting overrides all other controls.

Question 28: bypassPermissions and allowed_tools (1.5)

An engineer sets allowed_tools=["Read"] together with permission_mode="bypassPermissions", expecting only Read to be usable.

What is wrong?

A) allowed_tools does not constrain bypassPermissions; unlisted tools can still run unless deny rules or hooks block them.
B) Read cannot be allowed.
C) bypassPermissions disables Claude entirely.
D) Hooks cannot run in bypass mode.

Answer **A.** In bypass mode, the allow-list is not a restriction. To actually lock the agent down, use scoped deny rules / hooks (or a mode like `dontAsk`). `bypassPermissions` belongs only in isolated, controlled environments.

Question 29: Stop hook for completion criteria (1.5)

A coding workflow requires implementation complete, tests passing, and docs updated. Claude tries to finish after implementation only.

Which control enforces "do not finish until all criteria are met"?

A) A Stop hook that validates the completion checklist and continues work if criteria are unmet.
B) A PostToolUse hook only.
C) A friendlier system prompt.
D) Removing the tests.

Answer **A.** A `Stop` hook intercepts lifecycle completion and can prevent stopping until criteria pass (distinct from the API's `stop_reason`). It is the right place for finish-criteria enforcement.

Question 30: Async hook for mandatory approval (1.5)

A security team configures an async hook intended to approve or deny each Bash command before it runs.

Why is this design wrong?

A) Async hooks cannot run shell commands.
B) Async hooks cannot block or control the current operation — Claude proceeds immediately, so they are only for side effects like logging or metrics.
C) Async hooks only fire on SessionStart.
D) Async hooks disable Claude.

Answer **B.** Async hooks run without blocking, so their decisions have no effect on the triggering action. Mandatory enforcement requires a synchronous `PreToolUse` hook or a permission rule.

Question 31: Fixed pipeline vs dynamic decomposition (1.6)

A legal agent must extract contract parties, identify governing law, validate required fields, then produce a risk summary. The steps are always the same.

Which decomposition strategy fits best?

A) Dynamic adaptive decomposition.
B) Prompt chaining (fixed sequential pipeline) with validation gates between steps.
C) Consensus voting across full passes.
D) A fully autonomous open-ended agent.

Answer **B.** The steps are known and fixed, so a prompt chain with programmatic gates is the simplest, most reliable, most debuggable fit. Dynamic decomposition would add needless unpredictability.

Question 32: Unknown scope demands adaptivity (1.6)

A request reads: "Investigate why intermittent timeouts started last week; the root cause is unknown." Subtasks cannot be listed up front and depend on what each step uncovers.

Which pattern is most appropriate?

A) Prompt chaining with fixed steps.
B) Dynamic adaptive decomposition (orchestrator-workers), where subtasks are generated from discoveries.
C) Routing into predefined categories.
D) A single large prompt.

Answer **B.** "Root cause unknown" and "scope evolves" signal open-ended investigation where the plan adapts as evidence accumulates — the orchestrator-workers / dynamic pattern, not a fixed pipeline.

Question 33: Attention dilution on a large review (1.6)

A PR modifies 14 files. A single-pass review gives detailed feedback for some files, superficial comments for others, misses obvious bugs, and flags a pattern in one file while approving identical code in another.

How should the review be restructured?

A) Require developers to split large PRs into 3–4 files before review.
B) Switch to a higher-tier model with a larger context window.
C) Run three full-PR passes and only flag issues found in at least two runs.
D) Split into per-file local passes, then a separate cross-file integration pass.

Answer **D.** The symptoms are classic attention dilution. Per-file passes give consistent depth; a dedicated integration pass catches cross-file issues. A bigger context window does not improve attention quality, consensus voting suppresses intermittently-caught bugs, and pre-splitting shifts the burden without fixing the architecture.

Question 34: Batching without an integration pass (1.6)

A review system splits 40 files into 4 batches of 10, reviews each batch, and concatenates the results. It still misses cross-file data-flow bugs.

What is missing?

A) A larger model.
B) A dedicated cross-file integration pass.
C) More natural-language instructions.
D) tool_choice: "any".

Answer **B.** Batching reduces local attention load but never examines relationships across batches. Only an explicit integration pass catches cross-file data flow.

Question 35: Fork does not fix stale context (1.7)

A developer analyzed a 50-file codebase yesterday, modified 3 files today, and wants to continue without reasoning from outdated file contents. A teammate suggests fork_session.

What is the best approach, and why is fork wrong here?

A) Fork the session; it gives a clean baseline.
B) Start a fresh session, inject a structured summary of prior findings, and re-analyze only the 3 changed files — fork would copy the stale history forward.
C) Resume the old session and tell Claude to ignore old results.
D) Re-analyze all 50 files from scratch.

Answer **B.** Fork branches from existing history, so it copies stale tool results too. The stale-context cure is a fresh session plus an injected summary and targeted re-analysis of only the changed files.

Question 36: Resume vs fork vs memory (1.7)

Claude has finished an architecture analysis. The team wants to compare a queue-based design and an event-sourcing design without losing the original analysis. The codebase has not changed.

What should they use?

A) Resume the original session for both.
B) Fork the session (fork_session / --fork-session) into two divergent branches from the shared baseline.
C) A fresh session with no context.
D) A memory store write.

Answer **B.** Forking is exactly for exploring divergent approaches from a shared, still-valid baseline — each branch reasons from the same groundwork without redoing it and without polluting the other.

Question 37: requires_action is not completion (1.7)

A managed session goes idle with stop_reason: requires_action because a tool needs confirmation. A developer logs this as a successfully completed task.

What does the state actually mean?

A) The task is complete.
B) The workflow is paused until the application sends the required result or confirmation, then it resumes.
C) Claude has failed permanently.
D) The session should be deleted.

Answer **B.** `requires_action` is a pause point awaiting external input (a tool result or allow/deny). Treating a paused workflow as finished is an anti-pattern.

Question 38: Session state vs durable memory (1.7)

An agent should remember a user's preferred report format across all future sessions, while the current debugging hypothesis should not persist beyond this task.

Where does each belong?

A) Both in current session history.
B) Preferred format in a cross-session memory store; current hypothesis in session state.
C) Both in a memory store.
D) Both in external workflow/database state.

Answer **B.** Durable cross-session knowledge belongs in memory; transient task reasoning belongs in session state. (Authoritative business state, e.g., AML-passed, belongs in external systems — a separate category.)

Answer Key

1.  B   (1.1)   premature termination — use stop_reason
2.  B   (1.1)   no natural-language completion parsing
3.  B   (1.1)   iteration cap is a safety net, not primary stop
4.  B   (1.1)   append tool_result with matching tool_use_id
5.  B   (1.1)   max_tokens = truncation, not transport failure
6.  B   (1.1)   pause_turn — continue, don't restart
7.  A   (1.1)   refusal is a successful stop reason
8.  B   (1.1)   sequence dependent side effects
9.  B   (1.2)   single agent unless decomposition justified
10. C   (1.2)   narrow coordinator decomposition
11. B   (1.2)   synthesize, don't concatenate
12. B   (1.2)   route all comms through coordinator
13. B   (1.2)   specialize by capability, not fragment
14. B   (1.2)   evaluator needs explicit criteria
15. B   (1.3)   Task/Agent must be in allowedTools
16. B   (1.3)   subagent context not inherited
17. B   (1.3)   parallel = many Task calls in one response
18. B   (1.3)   structured content+metadata preserves attribution
19. C   (1.3)   goals + criteria, not procedures
20. B   (1.3)   repeated invocations are independent
21. A   (1.4)   prerequisite gate for critical ordering
22. B   (1.4)   PostToolUse fires too late to block
23. B   (1.4)   workflow state in code/DB
24. B   (1.4)   self-contained structured handoff
25. C   (1.4)   decompose, parallel on shared context, synthesize
26. B   (1.5)   PreToolUse / deny rule for .env
27. B   (1.5)   hook allow doesn't override deny
28. A   (1.5)   allowed_tools doesn't constrain bypassPermissions
29. A   (1.5)   Stop hook for completion criteria
30. B   (1.5)   async hooks can't block
31. B   (1.6)   fixed steps → prompt chaining
32. B   (1.6)   unknown scope → dynamic decomposition
33. D   (1.6)   per-file passes + integration pass
34. B   (1.6)   missing cross-file integration pass
35. B   (1.7)   fresh start + summary, not fork
36. B   (1.7)   fork for divergent exploration
37. B   (1.7)   requires_action = paused, not done
38. B   (1.7)   memory vs session state

Scoring Guide

34–38 correct: Strong Domain 1 readiness.
29–33 correct: Good readiness; review the missed task statements.
23–28 correct: Solid basics, but the architecture tradeoffs need more practice.
Below 23: Revisit D1.1–D1.7 before moving on, prioritizing 1.1, 1.2, and 1.4.

Highest-Yield Domain 1 Traps

1.  Premature loop termination because Claude produced text — drive the loop off stop_reason, not content[0].type.
2.  Parsing natural language ("I'm done") for completion — ambiguous; terminate on end_turn.
3.  Treating an iteration cap as the primary stop condition — it is only a runaway-loop safety net.
4.  Executing a tool but not appending the tool_result (with matching tool_use_id) to history.
5.  Treating max_tokens / refusal as transport failures — they are valid stop reasons on a 200 response.
6.  Restarting from scratch on pause_turn instead of continuing the server-side loop.
7.  Parallelizing tool calls or subtasks that are actually dependent (one mutation needs another's result).
8.  Reaching for multi-agent orchestration when a single agent would do — prestige, not need.
9.  Narrow coordinator decomposition — incomplete-in-scope output traces back to the coordinator, not the workers.
10. Concatenating subagent outputs instead of synthesizing, reconciling, and verifying.
11. Letting subagents communicate directly instead of routing everything through the coordinator.
12. Forgetting that subagent context is NOT inherited — the prompt is the only channel; thin output usually means bad context passing.
13. Missing Task/Agent from the coordinator's allowedTools (then "fixing" it by adding more subagent definitions).
14. Serializing parallel work by emitting one Task call per turn instead of batching calls in one response.
15. Flattening findings to prose and losing attribution — pass structured content + metadata.
16. Prompt-based "enforcement" of critical ordering — prompts have a non-zero failure rate; use a programmatic prerequisite gate.
17. Using PostToolUse to block an action — it fires after execution; blocking requires PreToolUse.
18. Storing high-stakes business state (verified/approved/AML) only in conversation text instead of code/DB.
19. Weak, non-self-contained human handoffs — the human has no transcript; carry ID, summary, root cause, amount, actions taken, recommended action.
20. Assuming a hook's allow overrides deny rules, or that allowed_tools constrains bypassPermissions.
21. Using an async hook for a mandatory security check — async cannot block.
22. Picking a fixed pipeline for open-ended/unknown-scope work, or a dynamic agent for fixed known steps.
23. "Bigger model / larger context window" as the fix for attention dilution — the cure is structural multi-pass decomposition (per-file + integration).
24. Batching files for review but skipping the cross-file integration pass.
25. Forking to escape stale context — fork copies the stale history; use fresh start + injected summary + targeted re-analysis.
26. Treating requires_action as task completion — it is a pause awaiting external input.
27. Confusing session state, durable memory, and external workflow state.