Agentic Architecture & Orchestration

1.1 The agentic spectrum: workflow vs agent

The exam's first trap is definitional. Anthropic draws a hard line between two ways of using an LLM in a system, and several questions hinge on picking the right side of it:

The architect's rule the exam rewards: use the simplest pattern that solves the problem. If a fixed prompt chain hits the quality bar, an agent is the wrong answer — even though this is an "agents" certification. Distractors love to offer an impressive multi-agent design for a task a single prompt handles.

1.2 The agentic loop — the pattern behind every question

Every agent, from a support bot to Claude Code itself, runs the same four-beat loop: send request → check stop_reason → execute tool → return result → repeat. You must be able to read this loop in raw API terms.

Beat 1 — the request declares tools

POST /v1/messages
{
  "model": "claude-sonnet-5",
  "max_tokens": 4096,
  "tools": [{
    "name": "get_order_status",
    "description": "Look up the current status, carrier and ETA of a customer order by its order ID. Use when the customer asks where their order is.",
    "input_schema": {
      "type": "object",
      "properties": { "order_id": { "type": "string" } },
      "required": ["order_id"]
    }
  }],
  "messages": [
    { "role": "user", "content": "Where is my order ORD-8813?" }
  ]
}

Beat 2 — Claude answers with a tool call, not text

{
  "role": "assistant",
  "stop_reason": "tool_use",
  "content": [
    { "type": "text", "text": "I'll check that order for you." },
    { "type": "tool_use",
      "id": "toolu_01A9x",
      "name": "get_order_status",
      "input": { "order_id": "ORD-8813" } }
  ]
}

The stop_reasonfield is the loop's steering wheel. Memorise the values — the exam tests them directly:

This is the complete current list of seven values — the exam may test any of them, not just the four or five that show up in a first tutorial.

Beats 3+4 — execute, return, repeat, and always bound the loop

import anthropic
client = anthropic.Anthropic()

messages = [{"role": "user", "content": "Where is my order ORD-8813?"}]
MAX_ITERATIONS = 10   # an unbounded agent loop is a production incident

for _ in range(MAX_ITERATIONS):
    resp = client.messages.create(
        model="claude-sonnet-5", max_tokens=4096,
        tools=TOOLS, messages=messages)

    if resp.stop_reason == "tool_use":
        messages.append({"role": "assistant", "content": resp.content})
        results = []
        for block in resp.content:
            if block.type == "tool_use":
                results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,          # must match the tool_use id
                    "content": run_tool(block.name, block.input)})
        messages.append({"role": "user", "content": results})  # results go back as a USER turn
        continue
    break   # end_turn (or refusal / max_tokens) exits the loop

1.3 Executing tools correctly: parallel calls and error results

Two execution details separate passing candidates from failing ones.

Parallel tool use

Claude can emit multiple tool_useblocks in one assistant turn when calls are independent (e.g. "check the order status AND the refund policy"). Your loop must execute all of them and return all results in a single user turn, one tool_result block per tool_use_id. Returning them across separate turns breaks the correlation and is a recurring distractor.

Errors are data, not exceptions

When a tool fails, you do not crash the loop and you do not silently return an empty string. You return a structured error to the model so it can reason about recovery:

{
  "type": "tool_result",
  "tool_use_id": "toolu_01A9x",
  "is_error": true,
  "content": "Order lookup failed: ORDER_NOT_FOUND. The order ID may be
mistyped. Valid IDs look like ORD-#### . Ask the customer to re-check."
}

Note what that error contains: an error category, a hint about whether retrying makes sense, and a suggested next action. Claude reads error text like instructions — a good error message is self-healing behaviour for free.

1.4 Task decomposition: when to break work apart

Decomposition questions give you a big task and four ways to split it. The scoring logic behind the correct answers:

• Decompose when subtasks need different context. A research task over 40 documents cannot fit one context window; each reader gets its slice, a synthesiser gets the summaries.
• Decompose when subtasks need different tools or permissions. The agent that reads production logs should not be the agent that writes code — scoping is decomposition.
• Decompose when steps have different quality bars. A cheap model drafts, a strong model reviews (multi-pass beats one giant pass).
• Do NOT decompose when the task is sequential and shares one evolving state. Splitting a refactor across agents that each hold partial state creates merge conflicts and lost context — keep it in one session.

Output contracts make decomposition work: each subtask returns a structured summary (facts, decisions, open issues), never its raw transcript. The coordinator reasons over summaries; shipping full transcripts upward recreates the context problem you decomposed to escape.

1.5 Multi-agent topologies: hub-and-spoke wins

When one agent is not enough, the exam recognises exactly one blessed shape: a coordinator (hub) that owns the goal, delegates bounded subtasks to specialist subagents (spokes), and synthesises their results. Spokes never talk to each other.

Why flat (peer-to-peer) topologies are anti-pattern #7:

• No single owner of "done." Peers can ping-pong work forever; the hub decides completion.
• N² communication paths means N² places context gets corrupted or duplicated.
• Debugging dies. With a hub, every decision has one audit point; with peers, causality is spread across transcripts.
• Error propagation becomes untraceable — a hallucination introduced by one peer laundered through another looks like independent confirmation.

1.6 Subagents and context isolation

A subagent is a fresh context window with its own system prompt, its own restricted tool set, and a one-shot task. In Claude Code / the Agent SDK this is the Agent tool (renamed from Task in Claude Code v2.1.63 — Task(...) still works as a legacy alias, so both names appear in the wild): the parent spawns a subagent, the subagent works in isolation, and only its final report returns to the parent.

Three properties the exam tests:

1. Isolation is the feature.The subagent's exploration (50 file reads, dead ends, noise) never pollutes the parent's context. The parent pays only for the conclusion.
2. Tool scoping happens per subagent. A read-only research subagent gets Read/Grep/Glob and nothing else. Giving every agent every tool is anti-pattern #6 — it bloats reasoning and widens blast radius.
3. Communication is a contract.The parent's prompt to a subagent must be self-contained (the subagent has no memory of the conversation), and it should specify the shape of the report it wants back.

In Claude Code, custom subagents are Markdown files with frontmatter — this exact syntax appears in questions:

# .claude/agents/security-auditor.md
---
name: security-auditor
description: Reviews code changes for security issues. Use after any
  change that touches auth, input handling, or file access.
tools: Read, Grep, Glob        # read-only: an auditor never edits
---
You are a security auditor. Examine the changed files for injection,
authz bypass, and unsafe file handling. Report findings as a list of
{file, line, issue, severity}. If nothing is found, say so explicitly.

1.7 Session state management

The API is stateless: every request re-sends the whole conversation. "Session state" is therefore an architecture decision you make, and the exam asks where each kind of state belongs:

The recurring scenario: a support agent verified the customer's identity in turn 2; the conversation is compacted at turn 40; the agent asks the customer to verify again (bad) or worse, assumes verification (dangerous). The correct architecture extracted "identity verified, account #, case facts" into durable state at the moment it happened, and re-injects it every request.

1.8 Lifecycle hooks: rules that cannot be talked out of

Hooks are deterministic scripts that fire at fixed points of the agent lifecycle — PreToolUse (can block a tool call before it runs), PostToolUse (react to a result: format, lint, log), plus session-level events. The architectural point the exam hammers: a hook is enforcement; a prompt is a suggestion.

// .claude/settings.json - block edits to production config, always
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command",
                  "command": "python check_protected_paths.py" }]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": "npx prettier --write" }]
    }]
  }
}

If the requirement contains words like must never / always / compliance / policy, the answer is a hook (or permission rule), not a CLAUDE.md instruction. Prompts steer probability; hooks remove it. That is anti-pattern #1 in one sentence.