Agentic Architecture and Orchestration

What this domain tests

27% — the heaviest domain on CCA-F, roughly 16 of 60 questions. First-hand reports describe the Foundations exam as the most memorization-heavy of the four certifications: exact mechanics, parameter names, and lifecycle details, "you either know it or you don't." This domain is where that bites hardest, because it mixes two question species:

• Recall items: which stop_reason value continues the loop, which hook fires before a tool call, what must appear in allowedTools, what "--resume" and fork_session do.
• Judgment items: which decomposition strategy fits a scenario, when a hook beats a prompt instruction, when to resume versus start fresh.

Three of the six published exam scenarios lean on this domain: the Customer Support Resolution Agent (hooks, enforcement, escalation handoffs), the Multi-Agent Research System (coordinator-subagent mechanics, context passing), and Developer Productivity with Claude (decomposition, sessions). Expect questions framed inside those worlds.

Theory outline

1. The agentic loop (Task 1.1)

The lifecycle every Agent SDK and API-level agent runs on:

1. Send the request (system prompt, conversation history, tool definitions) to Claude.
2. Inspect stop_reason on the response.
3. If it is "tool_use": execute the requested tool(s), append the results to the conversation as tool_result blocks referencing each call's tool_use id, and send the updated conversation back.
4. If it is "end_turn": the task is complete — surface the result.
5. Repeat.

Two ideas the exam probes hard:

Tool results extend the conversation. Results are appended to history so the model can reason about them when deciding its next action. That is what makes the loop model-driven: Claude chooses the next tool based on context plus everything it has learned so far — as opposed to a pre-configured decision tree or fixed tool sequence, where code dictates the order regardless of findings.

Termination anti-patterns. The guide names three explicitly:

• Parsing natural-language signals ("Task completed!") to decide termination.
• Setting an arbitrary iteration cap (say, max_iterations = 5) as the primary stopping mechanism.
• Checking whether the assistant produced text content as a completion indicator.

The only reliable completion signal is stop_reason = "end_turn". An iteration cap is fine as a safety backstop against runaway loops — it is wrong as the thing that normally ends the loop, because it truncates legitimate multi-step work and masks the real signal.

2. Coordinator–subagent orchestration (Task 1.2)

Multi-agent systems on the Agent SDK use a hub-and-spoke topology: one coordinator, N specialized subagents, and all inter-subagent communication routed through the coordinator. Subagents never talk to each other directly. Routing through the hub buys observability, consistent error handling, and controlled information flow.

The coordinator owns:

• Task decomposition — splitting the query into subtasks.
• Dynamic selection — analyzing what the query actually needs and invoking only the relevant subagents, rather than always running the full pipeline. A simple factual query should not trigger web-search → document-analysis → synthesis → report every time.
• Delegation — spawning subagents with complete instructions.
• Result aggregation and validation — merging findings, checking coverage.
• Iterative refinement — evaluating synthesis output for gaps, re-delegating targeted queries to search/analysis subagents, and re-invoking synthesis until coverage is sufficient.

Two design risks the guide names:

• Overly narrow decomposition: the coordinator slices a broad research topic into slivers and the union misses whole regions of the topic. Decomposition must cover the question, not just partition it.
• Duplicated coverage: subagents researching overlapping ground waste tokens and produce conflicting summaries. Partition scope explicitly — distinct subtopics, distinct source types — per subagent.

Isolated context is the critical principle. Subagents do NOT automatically inherit the coordinator's conversation history, and they do not share memory between invocations. Every fact a subagent needs must be explicitly present in its prompt. This isolation is also the pattern's superpower: each subagent burns its own context window on raw material and returns condensed findings, so the coordinator's window holds summaries instead of source dumps.

3. Spawning subagents: the Task tool, AgentDefinition, context passing (Task 1.3)

Mechanics to memorize:

• Subagents are spawned via the Task tool. For a coordinator to invoke subagents at all, its allowedTools must include "Task". A coordinator whose allowedTools lists only business tools will never delegate — it can't.
• Each subagent type is configured with an AgentDefinition: its description (how the coordinator knows when to use it), its system prompt, and its tool restrictions — least privilege applies to agents just like it does to tools. A search subagent gets search tools, not the refund tool.
• Parallel spawning: a coordinator runs subagents concurrently by emitting multiple Task tool calls in a single response. Task calls spread across separate turns run sequentially — a classic exam distractor.

Context passing discipline:

• Include complete findings from prior agents directly in the subagent's prompt. The synthesis subagent needs the web-search results and document-analysis outputs pasted in — a reference like "use the earlier search results" points at context the subagent cannot see.
• Use structured data formats that separate content from metadata (source URLs, document names, page numbers) when passing context between agents. That is what preserves attribution through the pipeline, so the final report can cite sources.
• Write coordinator/delegation prompts that specify research goals and quality criteria rather than step-by-step procedural instructions. Goal-shaped prompts let subagents adapt their approach to what they find; scripts break the moment reality deviates.

Fork-based sessions (detailed in section 7) let you branch divergent approaches from a shared analysis baseline — e.g., explore two refactoring strategies from one expensive codebase investigation.

4. Enforcement and handoffs in multi-step workflows (Task 1.4)

The load-bearing distinction: programmatic enforcement versus prompt-based guidance.

Prompt instructions ("always verify identity before processing refunds") have a non-zero failure rate — high compliance, never guaranteed. When a business rule must hold — identity verification before financial operations, regulatory ordering constraints — you enforce it in code: hooks and prerequisite gates that block downstream tool calls until prerequisite steps have completed. The canonical example: block "process_refund" until "get_customer" has returned a verified customer ID. The gate lives outside the model, so no phrasing, injection, or bad day can bypass it.

Multi-concern requests: when a customer raises three issues in one message, decompose into distinct items, investigate each in parallel using shared context, then synthesize one unified resolution — rather than serially handling issue one while forgetting issues two and three.

Structured handoff protocols: when the agent escalates mid-process to a human who lacks access to the conversation transcript, it must compile a structured summary — customer ID, root cause analysis, refund amount, recommended action. Dumping the raw transcript (or handing off nothing) forces the human to re-investigate from zero and tanks resolution time. Handoffs carry decisions and analysis, not just history.

5. Hooks: interception and normalization (Task 1.5)

Agent SDK hooks intercept the agent lifecycle at defined points. The two the exam cares about:

Direction matters and is a favorite trap: PreToolUse guards actions (the call hasn't happened yet, so it can still be stopped); PostToolUse transforms results (the call already ran — too late to prevent anything, exactly right for cleaning up what came back).

The judgment layer repeats section 4's rule: choose hooks over prompt-based enforcement when business rules require guaranteed compliance. A prompt saying "never refund more than $500" fails occasionally; a PreToolUse hook checking the amount fails never. When the exam scenario mentions money, legal exposure, or safety, the deterministic option wins.

6. Task decomposition strategies (Task 1.6)

Two strategies, matched to how knowable the work is upfront:

Concrete patterns the guide tests:

• Large code reviews: analyze each file individually in per-file local passes, then run a separate cross-file integration pass. One giant all-files pass dilutes attention — local issues get caught, cross-file inconsistencies get missed.
• Open-ended tasks ("add comprehensive tests to a legacy codebase"): first map the structure, identify high-impact areas, then create a prioritized plan that adapts as dependencies are discovered. Neither a fixed pipeline (you don't know the steps yet) nor unplanned wandering (no prioritization) fits.
• Adaptive investigation plans generate subtasks from each step's discoveries — a debugging session where the stack trace determines which files to inspect next is the archetype.

7. Sessions: resume, fork, or start fresh (Task 1.7)

Three mechanisms, one decision rule.

• "--resume <session-name>" continues a specific named prior conversation — the tool for multi-day investigations ("claude --resume investigation-auth-bug").
• fork_session creates independent branches from a shared analysis baseline. Both forks inherit context up to the branch point, then diverge. Use it to explore divergent approaches — comparing two testing strategies or two refactoring approaches — without paying for the baseline analysis twice and without the branches contaminating each other.
• Fresh session with an injected structured summary — start clean and seed the new session with "here's what we established: …".

The decision rule:

Why fresh-plus-summary beats stale resume: a resumed session's old tool results (file reads, search output) look authoritative to the model even when the underlying files have changed — the agent reasons confidently from a world that no longer exists. A structured summary carries the conclusions forward without smuggling in the stale evidence.

Worked problems

Problem 1. A developer's agent loop runs: send request → if fewer than 10 iterations have elapsed, execute any requested tools and continue; at iteration 10, stop and return whatever text exists. In testing, complex tasks return half-finished answers. What should the control flow be?

A. Raise the cap to 25 iterations B. Continue while stop_reason is "tool_use" and terminate when it is "end_turn", keeping a generous cap only as a runaway backstop C. Stop as soon as the assistant produces any text content D. Have the model say "DONE" and regex for it

Approach: The symptom — legitimate multi-step work truncated at an arbitrary boundary — is exactly what the exam guide flags about iteration caps as the primary stop. The loop's real signal is stop_reason. A prepared candidate looks for the option that uses "tool_use"/"end_turn" as control flow and demotes the cap to a backstop.

Why the others fail: A keeps the anti-pattern, just later — a 26-step task still truncates. C is a named anti-pattern: assistant text often accompanies tool calls mid-task, so it fires early. D is the other named anti-pattern — parsing natural-language completion signals is brittle and the model may phrase it differently or say it prematurely.

Answer: B

Problem 2. A research coordinator delegates synthesis to a subagent with the prompt: "Synthesize the findings from the earlier searches into a report." The synthesis subagent returns a generic essay that ignores everything the search subagents found. Why?

A. The synthesis subagent's model is too small B. Subagents run with isolated context — the search findings were never in the synthesis subagent's prompt, so it couldn't use them C. The Task tool doesn't support synthesis workloads D. The coordinator should have raised temperature

Approach: "Earlier searches" exist in the coordinator's history. The first thing to check in any subagent-output-is-generic scenario is context isolation: subagents do not inherit the parent's conversation. The fix is to paste the complete search results and document analyses directly into the synthesis subagent's prompt, in a structured format that keeps source metadata attached.

Why the others fail: A invents a capability problem with no evidence — the output isn't low-quality, it's un-grounded. C is false; synthesis-via-Task is the standard pattern in the published Multi-Agent Research scenario. D is a sampling knob; no temperature makes invisible context visible.

Answer: B

Problem 3. A support agent must never execute "process_refund" unless "get_customer" has already returned a verified customer ID in this conversation. The current system prompt says so, and audits found three violations last month. What closes the gap?

A. Move the instruction to the top of the system prompt and bold it B. Add few-shot examples of correct verify-then-refund ordering C. A programmatic prerequisite gate — a PreToolUse hook that blocks process_refund unless the verified-customer precondition is satisfied D. A PostToolUse hook on process_refund that logs violations for weekly review

Approach: The stem says "must never" plus an audited failure rate — that phrase pattern means deterministic compliance is required, and the guide is explicit that prompt instructions alone have a non-zero failure rate. Only programmatic enforcement gives a guarantee, and it must act before execution.

Why the others fail: A and B are still prompt-based — they lower the failure rate, never to zero. D fires after the refund already executed; logging a violation is not preventing one. The Pre/Post direction is the buried trap here.

Answer: C

Problem 4. A coordinator needs results from a web-search subagent, a database subagent, and a news subagent, and latency matters. Traces show it invokes them one per turn, each waiting for the previous. What change makes them run concurrently?

A. Set parallel: true in each AgentDefinition B. Emit all three Task tool calls in a single coordinator response C. Spawn a fourth subagent to manage the other three D. Shorten each subagent's system prompt

Approach: Recall item dressed as an optimization problem. Parallelism in the Agent SDK's coordinator pattern comes from where the Task calls appear: multiple Task calls in one response run in parallel; calls across separate turns are sequential by construction.

Why the others fail: A invents a configuration field — AgentDefinition configures description, prompt, and tool restrictions, not a parallelism flag. C adds a hierarchy layer without changing the one-call-per-turn behavior that causes the serialization. D trims tokens, not turns.

Answer: B

Problem 5. A team uses Claude to review 40-file PRs in one pass. Local bugs get caught; cross-file inconsistencies (renamed function still called under the old name elsewhere) slip through. Which decomposition fixes the miss?

A. One pass with a larger context window B. Per-file local analysis passes, then a separate cross-file integration pass C. A fully autonomous agent that decides its own review order D. Review a random sample of 10 files deeply

Approach: This is the exam guide's own example under task 1.6. The failure is attention dilution — one pass over 40 files can't hold every cross-file relationship. The named fix is prompt chaining: local passes for depth, then one pass whose only job is integration-level consistency.

Why the others fail: A moves the wall, not the physics — "fits in context" is not "attended to," and dilution persists. C mismatches the strategy: a predictable multi-aspect review is the textbook case for a fixed pipeline, not dynamic decomposition. D trades the known miss for guaranteed blind spots.

Answer: B

Problem 6. On Monday an engineer ran a long Claude Code session analyzing an auth module. Over the week, a teammate refactored that module heavily. Friday, the engineer wants Claude's help continuing the auth work. Best move?

A. "claude --resume" the Monday session and continue where it left off B. fork_session from Monday's session into two branches C. Start a new session seeded with a structured summary of Monday's conclusions, letting Claude re-read the refactored files fresh D. Resume Monday's session and paste the diff of every commit since

Approach: The variable that decides resume-versus-fresh is staleness of prior tool results. Monday's session is full of file reads that no longer match reality, and a resumed model treats them as ground truth. The guide's stated preference: when prior tool results are stale, start fresh with an injected summary — conclusions survive, stale evidence doesn't.

Why the others fail: A is the trap — the agent reasons confidently from pre-refactor file contents. B forks the stale baseline into two stale branches; forking is for exploring alternatives from a valid shared analysis. D is better than A (informing the agent of changes is the right instinct for small deltas) but after a heavy refactor the summary-plus-fresh-read approach is more reliable than asking the model to mentally patch dozens of stale reads.

Answer: C

Exam traps

• Iteration caps as the primary stop condition. Caps are backstops. The loop's control signal is stop_reason — "tool_use" continues, "end_turn" terminates. Any option that terminates on text content or a parsed phrase is a named anti-pattern.
• Assuming subagents see the coordinator's history. They don't — no inheritance, no shared memory between invocations. Every "subagent output ignores prior findings" scenario resolves to missing explicit context in the Task prompt.
• Forgetting "Task" in allowedTools. A coordinator without "Task" in its allowedTools cannot spawn subagents, period. Watch for stems where delegation silently never happens.
• Parallel-across-turns. Multiple Task calls in ONE response run in parallel; one call per turn is sequential. Distractors offer fake config flags ("parallel: true") instead.
• PreToolUse vs PostToolUse direction. Pre guards outgoing calls (block/redirect — enforcement); Post transforms results (normalization). A PostToolUse "enforcement" option is too late — the tool already ran.
• Prompt instructions for guaranteed compliance. "Must never," dollar thresholds, regulatory ordering → hooks/prerequisite gates. Strengthening the prompt is always the seductive wrong answer.
• Raw-transcript handoffs. Escalation to a human without transcript access needs a structured summary (IDs, root cause, amounts, recommendation) — not a dump, not nothing.
• Resuming with stale tool results. Files changed → fresh session with a structured summary, or at minimum explicitly tell the resumed agent which files changed. Stale resumes look efficient and reason from a dead world.
• Full pipeline every time. Coordinators should dynamically select subagents per query. "Always run all four stages" wastes cost and is flagged in the guide as the thing to design away.
• Step-by-step delegation scripts. Coordinator prompts should carry goals and quality criteria; procedural scripts prevent subagent adaptation and are the wrong answer when both appear.