Domain 1: Agentic Architecture & Orchestration (27%)

Domain 1 is the largest single slice of the CCA-Foundations exam — just over a quarter of every question. It tests whether you can design reliable agentic systems on Claude, not just call the Messages API. Expect scenario questions that hand you a goal, a set of tools, and a reliability constraint, then ask you to pick the right control structure. The wrong answers almost always confuse "the model decides" with "my code decides."

The agentic loop is the foundation

An agent is not a single prompt — it is a loop. You give Claude a goal and a set of tools, and it repeats a cycle: gather context → take action → verify work → repeat until the task is done. This is the exact loop that powers Claude Code and the Claude Agent SDK.

Each iteration is one round-trip to the Messages API:

1. You send the conversation (system prompt, user goal, prior tool_use and tool_result blocks).
2. Claude responds. If it wants to act, it emits one or more tool_use blocks and stops with stop_reason: "tool_use".
3. Your application code executes the tool and appends the output as a tool_result block inside a new user message.
4. You call the API again. Claude either calls another tool or produces a final answer with stop_reason: "end_turn".

The single most-tested fact in this domain: the model never executes tools — it only requests them. The loop, the tool execution, and the termination check are your responsibility.

stop_reason drives control flow

You must branch on stop_reason every turn. Know these values:

• tool_use — Claude requested a tool. Execute it, append tool_result, loop again.
• end_turn — Claude finished naturally. The loop is done.
• max_tokens — the response was truncated by the token cap. Continue or raise the limit; do not treat it as a complete answer.
• stop_sequence — a custom stop sequence was hit.
• pause_turn — a long-running server tool turn was paused; pass the response back to continue.
• refusal — the model declined for safety reasons (with a stop_details policy category on newer models).

A classic trap: assuming the agent will stop on its own. It won't — always bound the loop with a turn cap (max_turns) or a token/cost budget.

Model-driven vs. hard-coded control

This is the heart of the domain. The exam wants you to choose the least powerful structure that solves the problem:

• Hard-coded / workflow (deterministic): you write the control flow — prompt chaining, routing, fixed sequences. Use when steps are known in advance, latency and cost must be predictable, and you want auditability. A single LLM call with retrieval is not an agent; it is a workflow.
• Model-driven (agentic): Claude decides which tools to call and in what order. Use only when the path is open-ended and cannot be predetermined — exploration, debugging, research.

Agentic flexibility costs tokens, latency, and predictability. If a fixed pipeline works, use it. "Make everything an agent" is almost always a wrong answer.

Multi-agent topologies

When one agent's context window or responsibilities get overloaded, decompose into multiple agents:

• Hub-and-spoke (orchestrator–worker): a lead/coordinator agent breaks the task down and delegates to specialized subagents, then synthesizes their results. This is the dominant pattern.
• Parallel subagents: independent subtasks (e.g., researching several sources) run concurrently to cut wall-clock latency. Use when subtasks don't depend on each other.
• Context isolation: the decisive reason to use subagents. Each subagent runs in its own clean context window and returns only a condensed summary to the coordinator. This keeps the orchestrator's context lean and prevents one task's noise from polluting another. Anthropic's multi-agent research system used this to handle work no single context could hold — at the cost of many more tokens.

Trade-off the exam tests: multi-agent systems multiply token usage (often 4x+ a chat). Reach for them when the task is broad and parallelizable enough to justify the cost — not for narrow, sequential work.

The Claude Agent SDK

The Agent SDK runs the production-grade version of the loop above (the same engine as Claude Code). Key building blocks:

• AgentDefinition — declares a subagent: its name, description, system prompt, model, and the specific tools it may use.
• Per-agent tool scoping — grant each agent the minimum tools it needs. A read-only research agent should never hold write/delete tools. This is least-privilege as a reliability and safety control.
• Hooks vs. prompts — hooks are deterministic code that fire at lifecycle points (before a tool runs, after a response) to enforce rules you cannot trust a prompt to follow — input validation, permission gates, logging. Use a hook for hard guarantees; use the prompt for guidance and preferences.

Sessions, decomposition, and human-in-the-loop

• Session management — persist conversation state so long or resumable tasks keep their context across turns; compact or summarize when the window fills.
• Prompt chaining vs. task decomposition — chaining feeds one call's output into the next in a fixed sequence; decomposition lets an agent dynamically split a goal into subtasks. Chaining = deterministic, decomposition = adaptive.
• Human-in-the-loop (HITL) escalation — for irreversible or high-stakes actions (sending money, deleting data, emailing customers), the agent should pause and request approval rather than act autonomously. Design explicit checkpoints; never let an unattended loop perform unbounded irreversible actions.

Master the loop, stop_reason, the model-vs-hard-coded decision, context isolation, and least-privilege tool scoping, and you have the spine of 27% of the exam.