Solution design and architecture
Six objectives, 17% of the marks, and one idea underneath all of them: a solution is not a model with a prompt — it is a system that turns an input the business has into an output the business values, and keeps doing so after the demo. This page covers the translation from business problem to design, the end-to-end shape the exam expects you to reason about, the pattern choice between augmented LLMs, workflows and agents, multi-agent orchestration and decomposition, and the value pillars that anchor “why this design” to something a stakeholder can audit.
Start with the move the whole domain tests: translation. The business arrives with a noun — “an AI assistant for support” — and the architect’s job is to find the verb underneath it: what will a person or a system do differently because this exists, on what input, with what tolerance for being wrong, at what cost, and measured how. Every objective in this domain is a facet of that translation. The exam’s scenarios are translation failures waiting to be diagnosed: a system designed for the demo instead of the failure mode, an agent where a workflow belonged, a multi-agent design that tripled cost to solve a problem decomposition made worse.
01From business problem to AI solution
Not every problem is an AI problem, and the exam rewards candidates who can say so. The qualifying questions the exam expects you to run — mentally, in ninety seconds — are these. What changes for the user if this ships? (If the honest answer is “a human reads the same document slightly faster”, the ROI conversation matters more than the design.) Does the task require judgment over unstructured language — classification with fuzzy edges, drafting, extraction from messy text, synthesis across sources? That is where LLMs earn their place; deterministic logic, keyword filters and a database lookup are still the right answer for anything rule-expressible. What is the cost of wrongness — an embarrassing draft a human catches, or a refund nobody authorised? That number decides how much scaffolding the design needs. And is the data actually there — the documents, the examples, the feedback that will tell you whether it works?
02End-to-end architecture: input → processing → output → feedback
The exam guide names the shape explicitly: input, processing, output, feedback loops. It is worth internalising because scenario questions describe systems by their pieces and ask what is missing — and the missing piece is usually the feedback loop, the part that makes a system rather than a pipeline.
Where the material enters: user messages, documents, tickets, tool results. Design questions: validation, PII handling, size limits, and whether input arrives whole or is retrieved on demand (the RAG decision, Domain 3).
The Claude call or calls: system prompt, model choice, tools, retrieval results assembled into context, structured output schemas. This is where prompting (Domain 2) and integration (Domain 3) live.
What the world sees: an answer with citations, a structured record, a drafted email, a tool action. Design questions: schema validation, confidence surfacing, and what happens when output fails validation — retry, degrade, or escalate.
What comes back: user corrections, thumbs-down, human-review outcomes from sampled outputs, cost and latency telemetry, eval scores on live traffic. This loop — back into prompts, retrieval, eval sets and model choice — is what separates a production system from a demo, and it is the piece scenarios most often leave out.
Two design cautions the exam draws from this shape. First, the feedback loop has to be designed, not hoped for: logged outputs sampled for review, user signals captured where they naturally occur, and a route from those signals back into the evaluation set. Second, degradation is an architecture property: what the system does when the model is uncertain, retrieval comes back thin, or a tool fails is a design decision made now — surface uncertainty, fall back to a cheaper path, or stop and escalate — not an incident discovered later.
03Pattern selection: augmented LLM, workflow, agent
The exam guide names three architectural patterns, and they come straight from Anthropic’s own engineering guidance on building effective agents. Learn the taxonomy once; every pattern-selection question is then a lookup.
One model call, enhanced: retrieval results in context, a tool or two, a schema on the output. The work happens inside a single call. Right for extract, classify, summarise, transform — the majority of production workloads.
A sequence you author in code: model calls and deterministic steps in a fixed arrangement — prompt chains, routing, parallel fan-out and join, evaluator–optimizer loops. The path is known in advance; the model executes steps, your code chooses the order.
A model in a loop with tools: it decides, step by step, what happens next given what it has seen, until some stop condition. Right when the number and order of steps depends on what the work reveals.
The selection question underneath every variant: how predictable is the path, and what does unpredictability cost? If the steps are known — summarise, classify, format, send — author them; the workflow is cheaper, testable and debuggable, and saying so is a mark-earning answer, not a timid one. If the path depends on the material — “find the bug and fix it”, “reconcile these three sources” — something has to look at each result and decide what follows; that something is the agent. The escalation ladder is the heuristic the exam rewards: start at augmented LLM, move to workflow when one call cannot carry the task, move to agent only when no fixed sequence can.
04Multi-agent systems and orchestration
Multi-agent designs earn their complexity in three situations. Context isolation: each subagent works in its own context window, so a long task does not drown the coordinator — research across many sources, review across many files. Parallelism: independent subtasks run at once, trading token cost for wall-clock time. Distinct roles: different system prompts, tools and permission sets per agent — the analyst who reads, the writer who drafts, the checker with a red pen and no editing tools.
Orchestration strategies the exam expects you to compare: a coordinator that decomposes and delegates to workers (the common pattern — the orchestrator holds the plan and the boundary, workers hold narrow contexts and report back); pipelines where agents hand off along a fixed route (workflow in spirit, agents in the steps); and peer-to-peer or dynamic delegation, where agents route work among themselves — powerful, and the hardest to evaluate and debug, which is itself an exam answer. The design rules that travel: the coordinator owns the user-facing result and must see failures as failures (structured error returns, not “done, with caveats”); each subagent gets a contract — brief, inputs, definition of done — and a bounded tool set (least privilege, Domain 3); and the report back carries confidence and provenance, so the coordinator’s answer is built on known ground.
05Decomposition techniques
Decomposition is how a problem too big for one context or one prompt becomes a set of tasks small enough to be excellent at. The cuts the exam recognises: by stage (research → draft → review → revise, the pipeline cut), by domain or content type (one agent per system of record, each with its own tools and vocabulary), by blast radius (read-only work separated from anything that writes or acts), and by difficulty (route the easy 80% to a cheap fast path, escalate the hard 20% — the router pattern that also appears in Domain 2’s model selection and Domain 4’s cost optimization).
And when decomposition makes things worse, because the exam will offer you that scenario too: tasks that lean on one shared mental model — a negotiation, a tightly coupled edit — split badly, because each cut adds a handoff and every handoff is a place where context, accountability or both get lost. The symptom phrases map directly: “each agent did its part and the result was incoherent” = over-decomposition; “the coordinator could not answer questions about the workers’ findings” = handoffs without contracts; “cost tripled” = decomposition bought isolation at the price of duplicated context.
06Business value pillars
The exam guide names its value pillars explicitly: efficiency, transformation, productivity, cost, performance SLAs. The architect’s job is that each design decision traces to one of them — and the exam’s version of this is a scenario where a technically elegant design serves a pillar nobody asked for. The mapping worth memorising:
| Pillar | The design response | The metric that proves it |
|---|---|---|
| Efficiency | Same output, fewer resources: caching, batching, model routing to smaller models on easy traffic, tighter prompts. | Cost per task, tokens per resolved case, time per unit of work. |
| Transformation | New capability, not a cheaper old one: an offering that was impossible without language understanding at scale. | Adoption of the new capability; revenue or reach attributable to it. |
| Productivity | Humans spend their hours on the judgment-heavy remainder: drafting, summarising, first-pass review at the elbow. | Hours per task, throughput per person, share of work AI-assisted vs AI-completed. |
| Cost | The bill is a designed number: prompt caching on stable prefixes, batch for asynchronous work, output caps, retrieval depth budgets. | Spend per thousand requests; cache-hit rate; cost trend at constant volume. |
| Performance SLAs | Latency and quality commitments the design can actually hold: streaming for perceived latency, p95 not average, degradation paths under load. | p95/p99 latency, accuracy band on live samples, error budget consumed. |
07The traps
- —“Agent is the advanced answer.” It is the expensive answer. The exam rewards the simplest pattern that meets the requirement, and offers you agent-flavoured wrong answers that sound senior.
- —“Build the demo, harden later.” A design without failure paths, degradation behaviour and a feedback loop is not an MVP — it is a liability with a demo. Missing-loop questions are this domain’s signature trap.
- —“RAG by default.” Retrieval is a design decision with alternatives — long context for small corpora, tools for live data, structured lookup for exact facts (Domain 3 has the full decision table).
- —“Decomposition is a virtue.” Every cut adds handoffs; decompose for isolation, parallelism or blast radius — not because the diagram looks more architectural.
- —“Value is implied.” If the design does not trace to a pillar and a metric, the exam’s right answer is usually to stop and define the measure, not to pick a technology.
A team must process inbound loan documents: extract fifteen named fields, validate them against rules, and route to one of six queues. The rules are stable and published. Volume is 40,000 documents a month. Which pattern fits best?
- AA workflow: one or more augmented-LLM extraction steps, deterministic rule validation in code, deterministic routing
- BA single agent with tools for extraction, validation and routing, free to choose its own steps per document
- CA multi-agent system with one agent per queue deciding whether each document belongs to it
- DOne large prompt with the full rulebook, letting the model extract, validate and route in a single call
→Check your answer
The path is known in advance and the validation logic is rule-expressible — so it belongs in code, not in the model. An augmented LLM per extraction step, deterministic validation and routing around it: cheapest, testable, auditable. Free-running agents (B) and per-queue agents (C) buy unpredictability where the requirements offer none; one giant call (D) welds rules into prose that updates with the rulebook and is far harder to audit than the published rules themselves.
A support-analytics pilot delights executives. Six weeks after launch, accuracy quietly drifts down. The team never built anything to notice. Which part of the end-to-end shape was missing?
- AInput validation on the tickets being summarised
- BOutput schema enforcement on the summaries
- CThe feedback loop — sampled outputs scored against a live evaluation set, with drift alerts
- DA larger model for the summarisation step
→Check your answer
Every other stage worked; what failed was the loop that watches production and routes what it sees back into evaluation and prompts. Input validation (A) and schema enforcement (B) are real but would not catch quality drift in fluent, well-formed summaries — and a bigger model (D) is a guess, not a diagnosis.
Which requirement most strongly justifies a multi-agent design over a single well-prompted workflow?
- AThe output must follow a strict JSON schema
- BThe workflow has four sequential steps
- CThe marketing team wants to show “multiple AIs” in the architecture diagram
- DSubtasks need isolated context windows — long research across many sources that would overflow one window
→Check your answer
Context isolation is the structural reason multi-agent exists: each worker holds a narrow window and reports a compact result upward. Schemas (A) and sequential steps (B) are served by simpler patterns, and diagram aesthetics (C) is the trap answer — complexity must be bought with capability, not appearance.
An executive sponsor asks for “95% accuracy, and transformational impact”. The eval on real traffic says 87%, held steady for a month. What is the architect’s professional move?
- AReport the measured band, tie the 87% to the value metric it already delivers, and reframe the gap as a scoped improvement with options and costs
- BPromise 95% after the next model release and continue the pilot quietly
- CTurn up temperature and few-shot density until the number improves
- DSwitch the metric to a friendlier one the executives will not question
→Check your answer
This is value-pillar thinking meeting stakeholder communication (Domain 6): honest numbers tied to business value, gaps converted into scoped options. Promising the roadmap (B) and metric shopping (D) are the two faces of over-promising; prompt tweaks (C) are not a strategy for an eight-point gap with a defined evaluation.
In the pattern taxonomy the exam guide uses, what distinguishes an agent from a workflow?
- AAgents use tools; workflows do not
- BAgents use larger models; workflows use smaller ones
- CIn a workflow, code authored in advance chooses the steps; in an agent, the model chooses the next step at run time
- DWorkflows are for prototypes; agents are for production
→Check your answer
The discriminator is who decides the path: your code (workflow) or the model in a loop (agent). Tools are available to both (A), model size is orthogonal (B), and production-worthiness is earned by scaffolding, not pattern choice (D).
A proposed design routes 80% of tickets to a Haiku-class fast path and escalates the hard 20% to a larger model. Which decomposition cut — and which value pillar — does this represent?
- ACut by stage; transformation
- BCut by difficulty; efficiency and cost
- CCut by blast radius; governance
- DCut by domain; productivity
→Check your answer
Difficulty-based routing with escalation is the classic efficiency play: same outcomes on the easy majority at a fraction of the cost, expensive capacity reserved for the hard minority. Stage cuts sequence work (A), blast-radius cuts separate read from write (C), and domain cuts split by system of record (D).