Augmented LLM
A single model call enhanced with retrieval, tools, and memory. The basic building block of Anthropic's architectural taxonomy, and for most business problems enough on its own.
Exam context: The default tier. Escalation to workflows or agents must be justified by a requirement the augmented LLM cannot meet.
See also: 1.3 Selecting Architectural Patterns
Workflow
A system where LLMs and tools are orchestrated through predefined code paths. The developer decides the steps; the model executes within them. Predictable, testable, and auditable.
Exam context: The correct choice when steps are known in advance. Named patterns: prompt chaining, routing, parallelisation, orchestrator-workers, evaluator-optimizer.
See also: 1.3 Selecting Architectural Patterns
Agent
A system where the model dynamically directs its own processes and tool usage, looping on environment feedback until the goal is met. Flexible, at the price of cost, latency, more ways to fail, and a harder audit.
Exam context: Is worth its cost only when the path genuinely cannot be scripted. The impressive-sounding agent for a fixed pipeline is the over-engineered wrong option that the exam offers most often.
See also: 1.3 Selecting Architectural Patterns
The Fit Test
The design question of whether a task belongs with a model at all. Language understanding, synthesis, and judgement over unstructured input justify Claude; fully rule-specified tasks belong in deterministic code.
Exam context: Recognising where NOT to use a model is scored as highly as recognising where to use one.
See also: 1.1 Translating Business Problems
Success Criterion
A metric with a baseline and a target, defined before the build, that makes a solution's value measurable and falsifiable. Without one, nobody can measure whether a solution delivers value.
Exam context: The professional sequence is problem → constraints → success criterion → solution shape. Options that start a build with no baseline are wrong answers.
See also: 1.1 Translating Business Problems
Six-Stage Pipeline
The standard structure for a production system: input, context assembly, processing, output, delivery, feedback loops. Every production Claude system has all six, whether or not the design diagram shows them.
Exam context: Gap-analysis questions describe an architecture with a stage missing. The two most commonly missing are output validation and the feedback loop.
See also: 1.2 End-to-End Architectures
Output Validation
Schema checks plus business-rule checks applied to model output before downstream systems consume it. Model output is untrusted input until validated; output that matches the schema can still break business rules.
Exam context: The control that stops bad model output corrupting downstream state. Prompt instructions are guidance, not a guarantee, and never substitute for it.
See also: 1.2 End-to-End Architectures
Feedback Loop
The pipeline stage that captures quality signals: user feedback, sampled evaluations and monitoring. It uses them to improve the prompt, the retrieval and the design. Production systems have this stage, and demos do not.
Exam context: "Quality is inconsistent and nobody can say why" is the sign of a missing feedback loop. Upgrading the model is the tempting wrong answer.
See also: 1.2 End-to-End Architectures
Blast Radius
The downstream consequence of a wrong model output. Determines how much validation and human review an architecture needs, and drives the delivery choice (auto-send vs draft-for-review).
Exam context: High blast radius (money, compliance, customer trust) demands prevention before delivery, not detection after it.
See also: 1.2 End-to-End Architectures
Orchestrator-Worker Architecture
A multi-agent design in which a lead agent (the coordinator) splits a goal into parts and starts specialised subagents. The subagents work in parallel, each with its own context window. The lead agent then combines their results. Communication flows through the coordinator.
Exam context: Delegation quality determines system quality. Duplication plus gaps in the output is caused by how the coordinator split the task, not by what the subagents can do.
See also: 1.4 Multi-Agent Systems
Context Isolation
The design fact that a non-fork subagent starts with a fresh context: it gets no coordinator conversation and no view of other subagents' findings. Every piece of context it needs must be passed explicitly in its brief (the instructions that it receives). Current Claude Code docs (October 2026) note two exceptions: a fork inherits the parent conversation, and a subagent with the SendMessage tool can message other named agents.
Exam context: Wrong options assume that agents share knowledge that nobody passed to them. Designs that rely on it fail because of how they are designed.
See also: 1.4 Multi-Agent Systems
Token Multiplier
The measured cost of agentic architectures: agents run at roughly 4× chat token usage, multi-agent systems at roughly 15×. A task's business value must be larger than this cost.
Exam context: A multi-agent proposal with no value case is an incomplete answer. The exam tests whether you avoid designs that are more complex than the task needs.
See also: 1.4 Multi-Agent Systems
Attention Dilution
The failure mode where one model pass over too much material produces inconsistent depth: thorough on some units, with no attention on others, contradictory on identical patterns. Fixed structurally with per-unit local passes plus a cross-unit integration pass.
Exam context: The most important decomposition failure. A larger context window is the tempting wrong answer — it lets the material fit in the window, but it does not fix the attention problem.
See also: 1.5 Decomposition Techniques
Decomposition Axes
The four ways to split a complex task: by stage (sequential phases), by section (independent units), by perspective (different points of view on the same input), by specialism (different tools, prompts, or models per subtask).
Exam context: Choosing the axis is the design decision; the workflow pattern follows from it.
See also: 1.5 Decomposition Techniques
Acceptance Gate
A programmatic check between pipeline stages that stops bad intermediate output propagating. Checkable in code without a model call, with a defined rejection path.
Exam context: Errors compound across stages if unchecked. Gate-free pipelines offered as complete are under-engineered.
See also: 1.5 Decomposition Techniques
Business Value Pillars
The five ways a Claude solution creates value, per the CCAR-P guide: efficiency, transformation, productivity, cost, and performance SLAs. Every major design decision should name the pillar it serves and how that will be measured.
Exam context: Questions that ask which pillar applies offer similar pillars as wrong options. To tell them apart: automating an existing process is efficiency; a newly possible capability is transformation.
See also: 1.6 Business Value Pillars
Prompt Caching
Reusing a static prompt prefix (system prompt, policy documents, tools) across requests. It cuts cache-read cost by at least 90% and reduces time to first token. Checked 13 November 2026: reads cost 0.1× the base input price on most models. They cost 0.05× on Opus 5.5 and Sonnet 5.5, and 0.025× on Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1. Static content goes first, dynamic content after.
Exam context: The cost-saving method that serves two pillars: cost and the latency SLA on the request path. Wrong options confuse it with batch processing.
See also: 1.6 Business Value Pillars
Batch Processing
Submitting large volumes of requests for asynchronous processing via the Message Batches API at roughly half the cost. Serves the cost pillar for work that tolerates deferred completion.
Exam context: The cost-saving method for work outside the request path. Offering it for an interactive use case with a latency SLA is the classic wrong option that confuses the two cost-saving methods.
See also: 1.6 Business Value Pillars
SLA Engineering
Translating contractual latency, availability, and quality targets into architecture. A p95 budget is divided into a budget for each stage. Availability targets force designed fallbacks. Minimum quality targets require evaluation tools.
Exam context: You design the system to meet an SLA. You do not assume that the system meets it. A chain whose stage times, added together, cannot fit inside the latency target must be redesigned.
See also: 1.6 Business Value Pillars