D1 · Agentic Architecture and Orchestration

This is the heaviest domain on the Architect exam – roughly 16 of 60 items – and it is where the ten anti-patterns bite hardest. It tests whether you can look at a described system and choose the simplest correct architecture: a single prompt, a fixed workflow, or a genuine agent; and if an agent, which orchestration pattern, how it terminates, how it escalates, and how it fails safely. Nearly every item is a trap between an over-engineered answer and a constraint-blind one.

Learning objectives

By the end of this page you should be able to:

1. Apply the workflow vs agent decision framework and justify it against constraints.
2. Select among the six orchestration patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, autonomous agent) and describe each one’s failure modes.
3. Implement the agentic loop and drive termination from stop_reason – not natural-language parsing (anti-pattern 1) or arbitrary iteration caps (anti-pattern 2).
4. Design coordinator/subagent hierarchies with explicit context passing, result aggregation and partial-failure handling.
5. Design escalation on explicit request (immediate) or capability (resolve first) – never sentiment or self-reported confidence (anti-patterns 4–5).
6. Choose hooks vs prompts for enforcement (anti-pattern 3) and Managed Agents vs Agent SDK/Tool Runner for hosting.
7. Propagate structured errors (category, retryable, partial results) with idempotency and retries (anti-patterns 6–7).
8. Decide between conversation, files, database and the memory tool for state, and model the cost and latency of multi-agent systems with per-agent observability.

1.1 Workflow vs agent: the first decision

An agent is a system where the model dynamically directs its own process and tool use, deciding what to do next in a loop until it judges the task complete. A workflow is a system where the code orchestrates the model through predefined paths – the control flow is written by you, not decided by the model.

The exam’s default posture, straight from Anthropic’s guidance, is: find the simplest solution and only increase complexity when it demonstrably improves outcomes. A single well-engineered prompt beats a workflow; a workflow beats an agent; an agent beats a multi-agent system. Add autonomy only when the task genuinely requires open-ended decision-making at runtime.

1.2 The six orchestration patterns

The exam expects fluency in all six. For each: what it is, an ASCII diagram, when to use it, and its failure modes.

Pattern 1 – Prompt chaining

Decompose a task into a fixed sequence of steps, each model call consuming the previous output. Add programmatic gates (“checks”) between steps.

Input ──► [Call 1] ──► gate ──► [Call 2] ──► gate ──► [Call 3] ──► Output
                        │                     │
                     fail→fix               fail→stop

Use when: the task cleanly splits into fixed subtasks and you trade a little latency for much higher accuracy per step (e.g., outline → draft → polish).

Failure modes: error compounding down the chain; a wrong early step poisons everything after; latency is the sum of all calls.

Pattern 2 – Routing

Classify the input, then dispatch to a specialised prompt/model/flow.

                 ┌─► [Billing prompt · Haiku]
Input ─► [Router]─┼─► [Technical prompt · Sonnet]
                 └─► [Escalation flow]

Use when: inputs fall into distinct classes best handled separately, and misclassification is cheaper than one-size-fits-all. Lets you send easy classes to cheaper models.

Failure modes: router misclassification cascades; too many classes make the router brittle; an unhandled class silently mishandled.

Pattern 3 – Parallelization (sectioning and voting)

Run independent subtasks concurrently (sectioning) or run the same task multiple times and aggregate (voting).

Sectioning                         Voting
        ┌─►[Worker A]─┐                    ┌─►[Run 1]─┐
Input ──┼─►[Worker B]─┼─►[Merge]   Input ──┼─►[Run 2]─┼─►[Vote]─► Output
        └─►[Worker C]─┘                    └─►[Run 3]─┘

Use when: subtasks are independent (sectioning) and latency matters, or when multiple attempts raise confidence (voting) – e.g., guardrail plus main answer, or majority-vote code review.

Failure modes: sectioning that assumes independence when tasks actually interact; voting that hides a systematic bias shared by all runs; cost multiplied by fan-out.

Pattern 4 – Orchestrator-workers

A central model (orchestrator) dynamically decomposes a task, spawns worker calls, and synthesises. Unlike parallelization, the subtasks are not predefined – the orchestrator decides them at runtime.

Input ─► [Orchestrator] ─┬─► [Worker: search docs]
             ▲           ├─► [Worker: read files]
             │           └─► [Worker: summarise]
             └────────────── synthesise ◄────────┘

Use when: you cannot predict the subtasks in advance (e.g., multi-file code changes, research where the sub-questions depend on findings).

Failure modes: the coordinator/subagent anti-patterns – relying on context auto-inheritance, no partial-failure handling, unbounded fan-out cost. See §1.5.

Pattern 5 – Evaluator-optimizer

One call generates, a second evaluates against explicit criteria and returns feedback, and the loop repeats until the criteria pass.

        ┌───────────────────────────┐
Input ─►[Generator]─► draft ─►[Evaluator]─► pass? ─► Output
        ▲                              │ fail
        └────────── feedback ◄─────────┘

Use when: you have clear, checkable success criteria and iteration measurably improves the result (translation quality, code that must pass tests, writing against a rubric).

Failure modes: the evaluator and generator share a session and therefore a bias (anti-pattern 9 – same-session self-review); no objective stopping criterion so it loops forever or stops arbitrarily; vague criteria produce useless feedback.

Pattern 6 – Autonomous agent

A single model runs an open-ended loop: it decides an action, calls a tool, observes the result, and repeats until it judges the task done or a stopping condition fires.

              ┌─────────────────────────────┐
User goal ─► [Claude] ─► tool_use ─► [Env] ──┘
                 ▲          result
                 └── loop while stop_reason == "tool_use"
                     stop when end_turn / gate / human

Use when: the task is genuinely open-ended, the environment gives reliable feedback, and errors are recoverable or gated by human approval for irreversible actions.

Failure modes: looping forever (bad termination); acting on stale or hallucinated state; taking irreversible actions without a gate; the two loop anti-patterns below.

1.3 The agentic loop and stop_reason-driven termination

Every agent is a loop. The only correct way to drive it is the API’s stop_reason field. The two most-tested anti-patterns live here.

stop_reason values: end_turn, tool_use, max_tokens, stop_sequence, pause_turn, refusal.

from anthropic import Anthropic

client = Anthropic()
messages = [{"role": "user", "content": "Investigate the failing test and fix it."}]

while True:
    resp = client.messages.create(
        model="claude-opus-5",
        max_tokens=4096,
        tools=TOOLS,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason == "tool_use":
        results = run_tools(resp.content)          # execute requested tools
        messages.append({"role": "user", "content": results})
        continue                                    # loop: model saw the results
    elif resp.stop_reason == "end_turn":
        break                                       # model is done
    elif resp.stop_reason == "max_tokens":
        raise OutputTruncated()                     # do NOT treat as completion
    elif resp.stop_reason == "pause_turn":
        continue                                    # long-running server tool; resume
    elif resp.stop_reason == "refusal":
        escalate_to_human(resp)                     # model declined; stop the loop
        break

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();
const messages: Anthropic.MessageParam[] = [
  { role: 'user', content: 'Investigate the failing test and fix it.' },
];

while (true) {
  const resp = await client.messages.create({
    model: 'claude-opus-5',
    max_tokens: 4096,
    tools: TOOLS,
    messages,
  });
  messages.push({ role: 'assistant', content: resp.content });

  if (resp.stop_reason === 'tool_use') {
    const results = await runTools(resp.content);
    messages.push({ role: 'user', content: results });
    continue;
  } else if (resp.stop_reason === 'end_turn') {
    break;
  } else if (resp.stop_reason === 'max_tokens') {
    throw new Error('Output truncated – not a completion signal');
  } else if (resp.stop_reason === 'refusal') {
    await escalateToHuman(resp);
    break;
  }
}

A correct termination design combines: stop_reason as the primary signal, an iteration/token/cost cap as a backstop, and explicit gates (human approval for irreversible actions).

1.4 Managed Agents vs Agent SDK / Tool Runner: the hosting decision

1.5 Coordinator/subagent hierarchies

When one agent cannot hold the whole task, a coordinator decomposes it and delegates to subagents, each with its own isolated context window. This is the orchestrator-workers pattern at system scale (the Multi-Agent Research System scenario).

                 ┌──────────────┐
   User goal ───►│ Coordinator  │  holds plan, aggregates, decides done
                 └──────┬───────┘
        explicit context│ (never rely on inheritance)
        ┌───────────────┼────────────────┐
   ┌────▼────┐     ┌────▼────┐      ┌────▼────┐
   │Subagent1│     │Subagent2│      │Subagent3│  isolated context each
   └────┬────┘     └────┬────┘      └────┬────┘
        └── structured result ──────────┘
                 aggregate + handle partial failure

Explicit context passing

Subagents have isolated context windows. They do not automatically inherit the coordinator’s conversation, files or findings. The coordinator must explicitly pass everything the subagent needs in its task prompt.

# CORRECT: the subagent gets exactly what it needs, explicitly.
subagent_task = {
    "role": "user",
    "content": (
        f"Objective: {objective}\n"
        f"Context you must use:\n{relevant_findings}\n"
        f"Constraints: {constraints}\n"
        f"Return: a JSON object {{'finding': str, 'sources': [str], 'confidence': str}}."
    ),
}

Result aggregation and partial-failure handling

Subagents fail independently. The coordinator must aggregate structured results and decide what to do when some fail.

results, failures = [], []
for sub in subagents:
    try:
        r = run_subagent(sub, timeout=SUB_TIMEOUT)
        if r.status == "ok":
            results.append(r)
        else:
            failures.append((sub, r.error))     # structured error, not swallowed
    except TimeoutError as e:
        failures.append((sub, {"category": "timeout", "retryable": True}))

# Decide: proceed with partial results, retry retryables, or escalate.
if len(results) >= MIN_QUORUM:
    answer = coordinator_synthesise(results, note_missing=failures)  # provenance of gaps
else:
    escalate("insufficient subagent results", partial=results, failures=failures)

The correct design surfaces partial failure to the coordinator with structured detail, then makes an explicit decision (proceed with a quorum and note the gap, retry retryables, or escalate). Silently dropping a failed subagent and presenting the rest as complete is anti-pattern 7.

1.6 Escalation design

Escalation is one of the most reliably tested topics because three of the ten anti-patterns are escalation traps. The rule set:

def should_escalate(turn) -> bool:
    if turn.user_explicitly_requested_human:
        return True                              # immediate
    if turn.requires_capability_agent_lacks and turn.resolution_attempts_exhausted:
        return True                              # capability-based, after trying
    # NOT: turn.sentiment == "angry"
    # NOT: turn.model_confidence < 0.7
    return False

1.7 Hooks vs prompts for enforcement

Some rules are critical – they must always hold (never delete production data, never commit secrets, always run tests before commit). Enforce these with deterministic code: Claude Code hooks or programmatic guards in your loop. Never enforce a critical rule with a prompt instruction.

1.8 Error propagation with structured context

Errors must carry enough structure for a caller (or the model) to decide what to do: category, retryable flag, and any partial results.

class AgentError(Exception):
    def __init__(self, category, message, retryable, partial=None):
        self.category = category        # e.g. "rate_limit", "validation", "timeout", "auth"
        self.message = message          # specific, diagnostic
        self.retryable = retryable      # drives backoff vs. escalate
        self.partial = partial          # data gathered before failure

# On the boundary, return structured error content the model can reason about:
tool_result = {
    "type": "tool_result",
    "tool_use_id": tu_id,
    "is_error": True,
    "content": json.dumps({
        "category": "rate_limit", "retryable": True, "retry_after": 12,
        "partial": partial_rows,
    }),
}

Idempotency and retries

Retry 429, 5xx and 529 with exponential backoff + jitter, and respect retry-after. But only safely retry operations that are idempotent – give write operations an idempotency key so a retried “create order” does not create two orders.

def with_retry(fn, *, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return fn()
        except RetryableError as e:
            if attempt == max_attempts - 1:
                raise
            sleep(min(2 ** attempt + random.random(), 30))   # backoff + jitter

1.9 State and memory vs conversation

Conversation history is not durable state. It is trimmed by context editing, summarised by compaction, and lost across sessions. Anything that must survive belongs in explicit state.

1.10 Cost and latency modelling of multi-agent systems

Every agent and subagent is model calls, and multi-agent fan-out multiplies both cost and token consumption. Model this before building.

• Cost ≈ Σ over calls of (input tokens × in-price + output tokens × out-price). Subagents each carry their own system prompt and tools as input – fan-out of 5 means ~5× the fixed overhead. Prompt caching (0.1× on cache reads) and cheaper models for simple subtasks (Haiku for classification) cut this sharply.
• Latency: chaining adds latencies serially; parallelization bounds latency by the slowest branch; deep coordinator/subagent trees add round-trips.
• The trade: a multi-agent research system can be 10–15× the token cost of a single call. Justify it only when the quality or breadth gain is real. If a workflow meets the bar, use the workflow.

Single agent:      1 system + N tool round-trips              (cheapest, serial)
Parallel workers:  1 orchestrator + K×(system+tools)          (fast, K× fixed cost)
Deep hierarchy:    coordinator + Σ subagents + aggregation    (most capable, most $$)

1.11 Observability

You cannot operate what you cannot see. A multi-agent system needs:

• Traces per agent – each agent/subagent emits a span with inputs, tool calls, stop_reason, tokens and cost.
• Correlation IDs – one request ID threaded through the coordinator and every subagent so you can reconstruct a single task end-to-end.
• Metrics – per-agent latency (p50/p95), error rate by category, retry counts, tokens and cost per task, cache-hit rate.
• Structured logs without secrets.

1.12 Orchestration variants and their failure modes

Beyond the six base patterns, item writers combine them into named variants. Recognising the variant tells you the failure mode to guard against.

Hierarchical (coordinator → sub-coordinators → workers)

                 [Root coordinator]
                  /            \
        [Sub-coord A]        [Sub-coord B]
         /       \             /       \
    [W1]        [W2]       [W3]        [W4]     isolated contexts throughout

Use when a task decomposes into large sub-domains that themselves need decomposition. Failure modes: context loss deepens with each tier (every level must pass context explicitly); cost and latency compound (each tier adds round-trips); a mid-tier failure can orphan a whole subtree.

Pipeline with feedback (chaining + evaluator-optimizer)

[Extract] ─► [Transform] ─► [Load] ─► [Evaluate]
    ▲                                    │ fail
    └──────────── targeted retry ◄───────┘

Use when a fixed pipeline needs a quality gate at the end that can send work back to a specific stage. Failure modes: feedback to the wrong stage; unbounded feedback loops without an objective stop; the evaluator sharing the generator’s session (#9).

Blackboard / shared-state coordination

   [Agent A] ─┐          ┌─► reads/writes
   [Agent B] ─┼─► [Shared state store] ◄─┼─ [Agent C]
   [Agent D] ─┘          └─► reads/writes

Use when several agents contribute to a common evolving artefact (a research doc, a plan). Failure modes: race conditions and lost updates on the shared store; no single owner of “done”; stale reads. Fix with transactional writes, versioning, and one coordinator that decides completion.

1.13 Cost and latency arithmetic you can be asked to do

The exam can give you token counts and prices and ask for the relative cost of two topologies. Use the September-2026 prices (input/output per million tokens): Opus 5 $5/$25, Sonnet 5 $2/$10, Haiku 4.5 $1/$5, Fable 5.1 $10/$50. Cache reads ≈ 0.1× input; Batch ≈ 0.5×.

Worked example — single agent vs 5-worker fan-out. Each call carries a 10k-token stable prefix (system + tools) and produces 1k output. On Opus 5:

Per call input  = 10,000 tokens × $5 / 1,000,000  = $0.050
Per call output =  1,000 tokens × $25 / 1,000,000 = $0.025
Per call total  = $0.075

Single agent, 4 tool round-trips  ≈ 4 × $0.075          = $0.300
5-worker fan-out (each 1 call) + 1 synthesis           = 6 × $0.075 = $0.450
   ...but each worker re-sends the 10k prefix, so the fixed overhead
   is paid 6× instead of being amortised — fan-out is ~1.5× here,
   and grows with prefix size and worker count.

Two levers that change the answer:

• Prompt caching. If the 10k prefix is cached, each read costs 10,000 × $0.50/1,000,000 = $0.005 instead of $0.050 — the fan-out’s fixed overhead collapses and the multi-agent penalty shrinks dramatically.
• Model mix. Route simple workers to Haiku ($1/$5) and reserve Opus for synthesis; a 5-worker Haiku + Opus-synthesis design can undercut an all-Opus single agent while adding breadth.

1.14 Human-in-the-loop gates as first-class architecture

Autonomy is a spectrum. The architect chooses where a human sits in the loop, and makes that gate deterministic, not a prompt request.

The gate is placed on irreversibility and blast radius, not on the model’s confidence or the user’s tone. A refund over a threshold, a production deploy, an outbound email to a customer list — these get a hard gate regardless of how sure the model claims to be.

Common misconceptions

Scenario walkthrough — a research system that keeps “losing the plot”

Situation. A team ships a market-research assistant. A coordinator breaks a question into sub-questions and dispatches subagents that each search and summarise. In production, two problems appear: (1) subagents sometimes contradict findings the coordinator already established, and (2) when one subagent’s search API times out, the final report is delivered as if complete, occasionally missing a whole competitor. Leadership also complains the system costs 12× a single Opus call and asks whether it should be simplified. The accuracy bar was met in testing by a two-step “plan → parallel-summarise → synthesise” design.

Expert reasoning trace.

1. Name the pattern. Sub-questions are decided at runtime from findings → this is orchestrator-workers, so expect the coordinator/subagent failure modes, not a routing or chaining fix.

2. Diagnose problem (1). Subagents “contradicting known findings” is the classic isolated-context symptom: the subagents never received the coordinator’s established facts. The fix is explicit context passing in each subagent’s task prompt with a fixed return shape — not a bigger window (a tempting but constraint-blind option) and not a better model.

3. Diagnose problem (2). Presenting a partial report as complete after a timeout is silent suppression (#7). The fix is a structured error (category:"timeout", retryable:true) surfaced to the coordinator, which then retries the retryable, proceeds with a quorum noting the gap, or escalates — never a silent drop and never a generic “research failed” (#6).

4. Address the cost/simplification question. The two-step design already met the accuracy bar. The deep, expensive topology is over-engineering. The correct call is to use the simpler design and add complexity only where it demonstrably improves outcomes — while caching the stable prefix and routing simple summaries to Haiku to cut the remaining cost. Rejecting “use a bigger model” and “add more subagents” is essential.

5. Make failures observable. Add per-agent trace spans + a correlation ID so the next timeout is attributable, rejecting “add more retries” as an observability fix.

Exam-correct decision: explicit context passing + structured partial-failure handling with a quorum + collapse to the two-step design + caching/model-mix for cost + per-agent traces. Every rejected option maps to a named anti-pattern (isolation-ignorance, #7, #6, over-engineering, confidence/sentiment escalation) — which is exactly how the distractors are built.

Exam traps in this domain

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• Prefer the simplest architecture that meets the requirement: single prompt < workflow < agent < multi-agent.
• Know all six patterns and their failure modes; match the pattern to whether you or the model decides control flow.
• Drive loop termination from stop_reason; use caps only as a backstop; treat max_tokens as truncation, pause_turn as resume, and refusal as stop-and-escalate.
• Pass context to subagents explicitly at every tier – isolated contexts never auto-inherit; specify the return shape for clean aggregation.
• Handle partial failure with structured errors and an explicit decision (quorum, retry, escalate) – never silent drops.
• Escalate on explicit request (now) or capability gap (after attempting); never on sentiment or self-reported confidence.
• Enforce critical rules and irreversible-action gates with deterministic hooks/permissions, keyed on blast radius, not prompt instructions.
• Persist anything durable in the memory tool or external state; retry only idempotent writes with backoff and jitter; and instrument every agent with traces and correlation IDs.
• Recognise orchestration variants (hierarchical, pipeline-with-feedback, blackboard) and the failure mode each introduces; add tiers only when breadth or quality demonstrably improves.
• Model cost/latency before building: caching the stable prefix and routing simple subtasks to cheaper models usually beats “bigger model” or “more agents”.
• Fan-out pays the fixed prefix overhead per worker; caching collapses it, which is why it is the exam-correct cost lever.