Domain 1 · Agentic Architecture & Orchestration (27%)

This is the heaviest domain, and the one that quietly decides pass or fail. What it's really checking is whether you can choose and justify an architecture — not just recite the name of one.

At a glance

The agentic loop — the exam's core object

🧭 Your seat at the table: the loop runs Claude's thinking, but everything it thinks with is your construction. Before any model call, you assembled the context (the messages array and its roles), chose the objective (the system prompt), curated what it can do (the tool catalog, from your tool registry), and set the rules (gates, budgets, guardrails). The exam calls this "architecture"; day to day, it's just being a good host to a brilliant guest.

flowchart TD
  S[Start: task + context] --> B[Build prompt: system + messages + tool definitions]
  B --> M[🧠 Claude call]
  M --> SR{stop_reason?}
  SR -->|tool_use| X[Harness executes the tool]
  X --> A[Append tool_result to messages]
  A --> G{Gates: budgets · guardrails · HITL}
  G -->|ok| B
  G -->|violation| E[Escalate / halt]
  SR -->|end_turn| R[Final response]
  SR -->|max_tokens| T[Truncated — handle!]
  R --> V[Verify: evals, schema checks]

Every Anthropic doc keeps coming back to the same three phases: gather context → take action → verify results. Here's the part worth internalizing — the model never actually does anything. It only requests actions, by emitting tool_use blocks; your deterministic harness is what runs them and hands back the tool_result blocks.

{
  "system": "You are a support agent for Acme Store. Resolve delivery issues. Never promise refunds — replacements only, per policy P-12.",
  "tools": [
    {
      "name": "get_order",
      "description": "Fetch one order by id. Read-only. Returns status, value, and replacement eligibility. Use when the customer references a specific order.",
      "input_schema": {
        "type": "object",
        "required": ["order_id"],
        "properties": { "order_id": { "type": "string" } },
        "additionalProperties": false
      }
    },
    {
      "name": "create_replacement",
      "description": "Ship a replacement for a lost or damaged order. SIDE EFFECT: creates a real shipment.",
      "input_schema": { "…": "same three-part shape as get_order — elided here for brevity" }
    }
  ],
  "messages": [{ "role": "user", "content": "My order #4531 never arrived. Can you send a replacement?" }]
}

{
  "stop_reason": "tool_use",
  "content": [
    {"type": "text", "text": "Let me look up that order first."},
    {"type": "tool_use", "id": "toolu_01A", "name": "get_order", "input": {"order_id": "4531"}}
  ]
}

{"order_id": "4531", "status": "lost_in_transit", "value_cents": 8900, "replacement_eligible": true}

{
  "stop_reason": "tool_use",
  "content": [{"type": "tool_use", "id": "toolu_02B", "name": "create_replacement",
               "input": {"order_id": "4531", "reason": "lost_in_transit"}}]
}

{
  "stop_reason": "end_turn",
  "content": [{"type": "text", "text": "I'm sorry your order was lost in transit. I've created replacement R-7821 — it should arrive within 3 days."}]
}

The messages array — how the loop physically grows

The messages field puzzles everyone at first: why an array of objects? And when the loop runs, does the new stuff get prepended or appended — and where does the tool result go?

Why an array: here's the thing that reframes everything — the Claude API is stateless. It remembers no conversation between calls (the same fact sitting behind the tool registry: nothing lives on Anthropic's side). So if you want it to know what happened earlier, the entire conversation history has to ride along inside every request — and messages is that history: an ordered array, oldest first, each element one turn carrying a role (user or assistant, alternating) and its content. The model doesn't "remember" turn 1. It re-reads it, every single call, because you re-sent it.

The growth rule: every new turn gets appended at the end — never prepended. That's two appends per loop iteration, and here's the bit nobody tells you up front: the model's own response goes right back into the array too. Watch it grow across the support-agent run from above:

# ── Call 1: one element
messages = [
  {"role": "user", "content": "My order #4531 never arrived. Can you send a replacement?"}
]
resp = client.messages.create(model=MODEL, system=SYSTEM, tools=TOOLS, messages=messages)
# → stop_reason "tool_use": wants get_order

# ── Append #1: the assistant's response — VERBATIM, tool_use block and all
messages.append({"role": "assistant", "content": resp.content})

# ── Append #2: your tool result — inside a USER-role message
messages.append({"role": "user", "content": [
  {"type": "tool_result", "tool_use_id": "toolu_01A",
   "content": '{"status": "lost_in_transit", "value_cents": 8900}'}
]})

# ── Call 2: the SAME array, now 3 elements, resent IN FULL
resp = client.messages.create(model=MODEL, system=SYSTEM, tools=TOOLS, messages=messages)
# → another tool_use → two more appends → Call 3 sends 5 elements → end_turn

So here's how the array looks across the three calls of the walkthrough:

Three details that quietly make or break a real harness:

• The assistant turn must be echoed back exactly — if you append only the tool_result without the assistant's tool_use message before it, the Claude API rejects the request: a tool_result must answer a tool_use that exists in the history.
• The tool_result rides in a user-role message. There is no "tool" role — from the model's perspective, tool results are things the outside world (you) reports back, and everything from the outside world arrives as user.
• system and tools are NOT in the array — they're separate request fields, re-sent alongside it each call. That's what makes them a byte-identical stable prefix while messages grows — exactly the split prompt caching exploits (Domain 5).

And now you can see why context management even exists: a 40-turn conversation means a 40-turn array resent on every single call, growing without any natural ceiling. The messages array is the context-window budget Domain 5 spends its time managing — compaction swaps old elements out for a summary, but that append-at-the-end rule never changes underneath it.

input (system 2.1K + tools 3.4K + messages array) + max_tokens (4K reserved) ≤ 200K

Stop reasons — memorize this table

Where does this list come from? stop_reason is a field the Claude API sets on every response — a closed, standard set defined by Anthropic, and that's the whole point. Your harness never invents these values and can't add to them; it plays the other side of the contract: read the value and branch on it. (The webhook that delivered the task and the tool backends the harness calls don't get a say in this field.)

🪤 Trap: a question shows JSON parsing failures "sometimes." The hidden cause is often max_tokens truncation being parsed as if complete. The architect answer: check stop_reason before parsing, and set max_tokens generously for structured output.

Workflows vs agents — Anthropic's decision rule

From Anthropic's engineering guide Building Effective Agents↗ (the most-quoted source in this domain):

• Workflow: LLM calls orchestrated through predefined code paths (chains, routing, parallelization). Predictable, testable, cheaper.
• Agent: the model dynamically directs its own process and tool usage. Flexible, expensive, harder to bound.

The rule the exam keeps rewarding: reach for the simplest thing that works — workflows for well-defined tasks, and agents only for the open-ended problems where you genuinely can't hardcode the path in advance. Any time a scenario hands you a known, repeatable sequence, a workflow pattern beats "give it tools and let it figure it out."

The five workflow patterns (parallelization comes in two flavors)

Anthropic's Building Effective Agents names five patterns — the two Parallelization rows below are the two flavors of one pattern (sectioning and voting), which is why five categories fill six rows. Count patterns as five; memorize both flavors.

flowchart LR
  subgraph Orchestrator-workers
    O[Coordinator: plans + decomposes] --> W1[Worker: search]
    O --> W2[Worker: analyze]
    O --> W3[Worker: code]
    W1 --> SYN[Synthesize]
    W2 --> SYN
    W3 --> SYN
  end

{"competitor": "Bolt", "model": "per-seat", "tiers": [{"name": "Pro", "usd_mo": 29}],
 "notable": "free tier removed in June; annual-only enterprise"}

Multi-agent design judgments (scenario 3 territory)

• Context isolation is the main reason to spawn subagents: each worker gets a clean, scoped context instead of one bloated window. The coordinator holds the plan; workers hold details.
• Parallelize reads, serialize writes: research/search/read subagents can fan out; anything mutating shared state needs sequencing or isolation (git worktrees — separate working copies of the repo so parallel agents don't clobber each other's files — or queues).
• Subagent results should return compressed summaries, not full transcripts, to protect the coordinator's context budget.
• Hub-and-spoke beats free-for-all agent-to-agent chatter: coordination flows through the coordinator; workers don't talk to each other.
• Know when NOT to multi-agent: added latency, token cost multiplication, and coordination failure modes mean a single well-tooled loop wins for bounded tasks.

Model portability — the "what if we swap models?" question

Companies ask this early: "if we build on one vendor's SDK, are we locked in?" The industry's answer has three layers, and knowing which layer solves which problem is the architect skill:

The trade nobody puts on the landing page: abstraction has a tax. A lowest-common-denominator model interface forfeits provider-native strengths — prompt caching semantics, native structured outputs, extended thinking — and frameworks lag new provider features. Anthropic's own guidance in Building Effective Agents is to use frameworks judiciously and keep the calling layer simple enough to understand. The Claude Agent SDK sits at the opposite pole: maximum harness quality, Claude-shaped by design (it does run against Bedrock/Vertex-served Claude — cloud portability without model portability).

What the adapter actually translates — the dialect problem. Every major provider converged on the same concepts: a model id, an ordered conversation, optional tool definitions, a token budget. That convergence is why gateways and adapters are feasible at all. But the dialects differ exactly where a hand-rolled integration breaks:

Same music, different notation — an adapter is ~200 lines because it's transposing these six rows, not reinventing anything.

And the Agent SDK doesn't take this input shape at all — by design. You don't hand it messages + tools; you hand it a prompt and options (allowed tools, max turns, system additions, MCP servers), and it owns building and growing the messages array internally. That's the abstraction level shift in one sentence: the Claude API's input is a conversation you manage; the Agent SDK's input is an intent plus a policy.

And the truth that makes this whole table honest: model-agnostic is NOT prompt-agnostic. Swapping frontier models is never a config flip in practice — prompts are tuned to a model's behaviors, tool-selection patterns differ, guardrail phrasings land differently. The gateway makes a swap possible; only your eval suite (golden set + negative controls, run side-by-side) makes it safe. Teams that "swapped in an afternoon" had evals; teams that swapped by config discovered their refund agent's tone and tool habits changed in production.

🎯 Exam lens: portability questions reward the layered answer — deterministic controls in the harness (they survive any swap), tools behind MCP (capability investments outlive model choices), model access behind a gateway, and an eval gate on every model change. "Rewrite on the other vendor's SDK" and "the framework handles it" are both trap answers.

Harness controls — what makes an agent production-grade

Where these controls physically live — the container, the queue, the approval UI — is the Deployment & Operations page's subject.

🎯 Exam lens: when a scenario asks "how do you prevent the agent from X," the correct answer is almost always a deterministic harness control, not "add instructions to the prompt." Prompts steer; harnesses enforce.

The harness as real files — annotated, clickable

💡 Budgets, gates and ledgers stop being vocabulary when you see them as config and code. Cookbook chips are public; the local chips open the tracecraft harness that runs on this machine.

// usecase config — BUDGETS: hard ceilings whose breach is a TERMINAL state, not a warning
{
  "budgets": { "max_model_calls": 6, "max_tool_calls": 8, "max_turns": 3 },
  "confidence_floor": 0.75            // below this, the classify gate routes to review
}

# a GATE — plain arithmetic the model cannot talk its way past
def action_allowed(category, action, cfg):
    allowed = cfg["actions"].get(category, [])
    if action not in allowed:                       # allowlist: absence IS the policy
        return False, f"{action} not allowed for {category}"
    return True, None

// EFFECTS LEDGER entry — a retry replays the RECORD, never the side effect
{
  "idempotency_key": "refund:A-1042:2026-08-30",   // same key → same outcome, no double refund
  "effect": "refund_issued", "amount_cents": 2500,
  "status": "applied", "at": "2026-08-30T17:12:03Z"
}

Specimens in the wild: cookbook:patterns/agents/basic_workflows.ipynb — the workflow patterns · cookbook:patterns/agents/orchestrator_workers.ipynb · cookbook:patterns/agents/evaluator_optimizer.ipynb · cookbook:tool_use/memory_demo/demo_helpers.py — a real loop with tool dispatch.

Escalation design (scenario 1 territory)

A support agent needs to escalate the moment any of these shows up: confidence drops below a floor, the category falls outside its charter, a tool dependency goes down, the user flat-out asks for a human, or a gate blocks the action it wanted to take. Treat escalation as a first-class terminal path — ticket + context handoff + an honest message to the user — not some afterthought exception. And design the handoff packet (conversation summary, evidence gathered, actions attempted) as part of the architecture from the start, not bolted on later.

Evaluation of agents (bleeds into Domain 5)

• Golden sets: fixed scenario suites with deterministic assertions on behavior (tools called, gates fired, terminal state) — not on prose wording.
• Negative controls: a config change that must flip a passing test red; green that can't be made red proves nothing.
• Trajectory evaluation: judge the path (did it follow the runbook — the documented step-by-step procedure it's supposed to follow — avoid forbidden tools) not just the final answer.
• LLM-as-judge: for higher independence, prefer a separately validated judge (often a different model/family); calibrate against human-labeled examples — judge agreement is a signal, not proof.

Sessions, forking, and spawning — the mechanics the exam names

The Task tool — how subagents are actually born

Subagents are spawned through the Task tool — and the exam tests the plumbing precisely:

• A coordinator can only spawn subagents if its allowedTools includes "Task". No Task tool, no delegation — a coordinator prompt that says "delegate to your research agents" with no Task tool silently becomes a monolith.
• Subagents inherit nothing. A subagent starts with an isolated context — it does not see the coordinator's conversation history or sibling results. Everything it needs (prior findings, web results, document extracts) must be passed explicitly in its prompt.
• Parallel spawning = multiple Task calls in a single response. A coordinator that emits three Task tool calls in one turn runs three subagents concurrently; emitting them across separate turns serializes them. This one line is the difference between a 3× latency win and none.
• Each subagent type is configured via an AgentDefinition — description (how the coordinator decides when to use it), system prompt, and tool restrictions.
• When passing context between agents, use structured data that separates content from metadata (source URLs, document names, page numbers) so attribution survives the handoff.

🪤 Trap: "the coordinator should share its memory with subagents" — it can't. Context passing is explicit, by prompt, every time. Questions that assume automatic context inheritance are describing the wrong system.

Session management — --resume, fork_session, and when to start fresh

• --resume <session-name> continues a named prior conversation — the investigation you parked on Friday.
• fork_session creates independent branches from a shared baseline: analyze the codebase once, then fork twice to compare two refactoring strategies without either polluting the other.
• The staleness rule: resume when prior context is still mostly valid; start a fresh session with an injected structured summary when the old tool results have gone stale (files changed, data moved). Resuming into stale tool results is worse than starting over — the model trusts them.
• If you resume after code changes, tell the session which files changed so it re-reads only those, instead of trusting stale reads or re-exploring everything.

🎯 "Two testing strategies from one shared analysis" → fork_session. "Continue yesterday's migration" → --resume + a note about what changed. "Tool results are three days old" → fresh session + summary injection.

Practice this domain

🎯 Done with Domain 1? Prove it: Agentic Architecture (Q1–Q8) — commit to an answer before revealing. Locally, your picks are captured with timestamps and scored per section, so weak spots surface on the practice page's comfort tiles.