Solution Design & Architecture (17%)
What the exam tests: turning a business problem into the simplest Claude architecture that meets its outcome, SLA, and risk profile.
Official task statements: translate business problems into Claude solutions; design end-to-end architectures with input, processing, output, and feedback loops; choose between workflow, agentic, and augmented-LLM patterns; design multi-agent systems and orchestration; decompose complex problems; tie solutions to business value and performance SLAs.
From problem to architecture
Start every design with four questions, in this order.
What outcome moves, and by how much? For example, cut average support handle time from 9 to 6 minutes, or process 40,000 claims a month at under $0.40 each.
What does a correct output look like, and who checks it? This becomes your evaluation set and your human-review policy.
What are the constraints? Latency budget, data residency, regulated data, cost ceiling, existing cloud commitments. How open-ended is the task? This decides the pattern.
The three patterns
Figure 2. Choose the least autonomy that does the job
More autonomy, cost and blast radius
Pattern Use when Example Main risk
Augmented
Llm
Workflow sub-patterns to recognize by name: prompt chaining (fixed sequence with checks between steps), routing (classify then send to a specialized prompt or cheaper model), parallelization (sectioning independent subtasks, or voting across several runs), orchestrator-workers (a lead call splits work dynamically), and evaluator-optimizer (one call drafts, another critiques against criteria, loop until pass).
Designing the loop end to end
Every production design has four stages, and the exam expects all four.
Input: validation, PII detection or redaction, injection screening, size limits. Processing: model calls, tools, retrieval, and the orchestration code around them. Output: structured output against a schema, policy checks, citations, confidence or abstain signals.
Feedback: user ratings, reviewer corrections, and production traces flowing back into the evaluation set.
A design with no feedback stage is the most common wrong answer in this domain.
Multi-agent systems
Use multiple agents when work is genuinely parallel (research across many sources), when subtasks need isolated context (each subagent gets a clean window and returns a summary), or when roles need different tools and permissions. Do not use them to look sophisticated: they multiply tokens, latency, and failure points.
Orchestration rules of thumb:
A lead agent plans, delegates with explicit instructions (objective, output format, boundaries), and synthesizes. Subagents return compressed results, not full transcripts.
Give each agent only the tools its role needs.
Put hard stops on loops: max turns, max spend, and a timeout.
Make side-effecting steps idempotent so a retry cannot double-charge or double-send.
Platform and deployment choices
Claude is available through Anthropic's API and through major cloud platforms (Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry at the time of writing). Choose by constraint, not preference: existing cloud commitments and procurement, data residency and private networking needs, which features are available on that platform (new features often reach Anthropic's API first), and identity integration. For agent runtimes, decide between building on the Claude Agent SDK in your own infrastructure or using a hosted, managed agent service; the trade-off is control and data locality against operational effort.
Tying design to value
Put a number on value and on the SLA in the design document: target metric, baseline, cost per transaction, p95 latency, availability, and the human-review rate. Classify the value type too: efficiency (same work, less effort), productivity (more output per person), or transformation (work that was not possible before). Executives fund the first two quickly and the third with a pilot.
Deep dive: designing for reliability
LLM calls are slower, costlier, and less predictable than ordinary service calls. A professional design treats each call as an unreliable dependency and plans for failure at three levels: the call, the step, and the whole task.
At the call level.
Timeouts sized to the expected response length; streaming responses get a time-to-firsttoken timeout and a total timeout. Retries with exponential backoff and jitter for transient errors such as rate limiting or overload responses. Cap the number of retries. Idempotency for any side effect: a unique request key so a retried tool call cannot repeat a payment, email, or ticket.
Fallback to another region, another platform, or a smaller model when the primary is unavailable, if evaluations show the fallback is acceptable. Circuit breakers that stop sending traffic to a failing dependency for a short period, so a queue does not build up.
At the step level.
Validate every output before the next step uses it: schema, required fields, value ranges. On failure, retry once with the validation error in the prompt, then route to a human or a safe default.
Checkpoint long workflows so a failure at step 7 does not restart steps 1 to 6.
SOLUTION DESIGN & ARCHITECTURE (17%)
Keep deterministic work in code. Arithmetic, date logic, lookups, and business rules belong in code or tools, not in the model.
At the task level.
Budgets: maximum turns, tool calls, tokens, spend, and wall-clock time per task. Graceful degradation: a defined behavior when the budget is exhausted, for example "summarize progress and hand off to a person." Human fallback path: every customer-facing flow needs a route to a person that works when the AI path does not.
Minutes of work, or many steps Research reports, document review, code migrations
Batch Large volume, results needed in hours Nightly classification, backfills, evaluation runs
Event-driven Work triggered by system events New ticket triage, failed build diagnosis A common exam trap is forcing a long agentic task into a synchronous request with a tight timeout. The better answer is usually an asynchronous job with progress updates.
State and memory
Claude itself does not remember between requests; your application supplies all context each time. Design the memory you need explicitly.
Conversation state: stored by the application, trimmed or summarized as it grows. Task state: the plan, progress, and decisions of a long task, stored outside the context window (a database row or a progress file) and reloaded when needed. Long-term memory: user preferences or facts the assistant may reuse later. Treat it as personal data: get consent where required, let users see and delete it, and never let one user's memory leak into another user's session.
Organizational knowledge: belongs in retrieval systems with access control, not in prompts or memory.
Anti-patterns to recognize
Anti-pattern Why it fails Better
"God agent" with every tool Poor tool choice, huge attack surface, unpredictable cost
- Role-specific agents or workflows with
- narrow tools
- LLM doing arithmetic or date
- math
- Unreliable on exact computation A code tool or calculator
Anti-pattern Why it fails Better
Prompt as access control Can be talked around Authorization in tools and data layer Agent loop without limits Runaway cost and loops Turn, spend, and time budgets Shipping without an evalu‐
ation set
No way to know if changes help or hurt Evaluation set from day one Model upgrade as the first fix Often misses the root cause Diagnose first: retrieval, prompt, data, then model
One giant prompt for a multipart taskSkipped steps, mixed facts Prompt chaining with checks Multi-agent for a fixed pro‐
cess
More cost and failure points A workflow
Worked example 2.1: choosing the pattern for an accounts-payable team
Brief. A manufacturer's accounts-payable team processes 18,000 supplier invoices a month. About 70% arrive as PDFs in a standard layout from the top 200 suppliers; the rest come in hundreds of formats, sometimes as scanned images, sometimes with handwritten notes. Each invoice must be matched to a purchase order and a goods receipt (a "three-way match") before payment. Clerks spend an average of 11 minutes per invoice. The CFO wants that cut to under 4 minutes without increasing payment errors.
Step 1: outcome and baseline. Target: average handling under 4 minutes; payment error rate no worse than today's (assume the team measures 0.6%). Value: roughly 18,000 × 7 minutes saved ≈ 2,100 clerk hours a month.
Step 2: what correct looks like. Every extracted field (supplier, invoice number, date, line items, totals, tax, PO number) matches the document; the match result agrees with what a senior clerk would decide. That is an evaluation set: collect 400 historical invoices with their correct extractions and match outcomes, stratified by supplier type and format.
Step 3: constraints. Financial data, auditor scrutiny, ERP integration, a batch window overnight is acceptable for most invoices, but urgent invoices need same-day processing. Step 4: how open-ended is it? The steps are known: extract, validate, match, route. That is a workflow. Only the exceptions (mismatched quantities, missing POs) involve judgment, and even there the action is to explain and route to a clerk, not to decide.
Design.
Classify the document (standard layout, non-standard, scanned, not an invoice) with a fasttier call and structured output. Extract fields to a strict schema. Balanced tier for non-standard and scanned documents; fast tier may suffice for standard layouts if evaluations confirm.
Validate in code: totals add up, tax is consistent, dates parse, supplier exists in the master file.
SOLUTION DESIGN & ARCHITECTURE (17%)
Match in code against PO and receipt data pulled through a read-only ERP API. Explain exceptions: for any mismatch, a Claude call writes a two-sentence explanation citing the fields that disagree. Route: clean matches go to a clerk's one-click approval queue; exceptions go to a review queue with the explanation.
Feedback: clerk corrections are logged against the extraction and fed into the evaluation set weekly.
Why not an agent? An agent that "handles invoices" would decide its own steps, call the ERP, and perhaps approve payments. That adds cost and unpredictability to a process that does not need it, and it would put payment authority in an automated loop. The exam rewards recognizing this. Expected result to present. Clean matches (estimated 75 to 80% after tuning) need only a 1- minute confirmation; exceptions take about 8 minutes with the explanation. A blended average near 2.5 to 3.5 minutes meets the target. These are hypotheses to validate in the pilot, stated as such.
Worked example 2.2: when multi-agent is justified
Brief. A pharmaceutical company's competitive-intelligence team writes a weekly brief on 40 competitor programs, drawing on press releases, trial registries, conference abstracts, patent filings, and analyst notes. One analyst spends three days a week on it.
Analysis. The task is wide (40 independent programs), each needs several sources searched and read, and the sources overflow a single context window if gathered together. The subtasks are independent and parallel. This is a fair case for orchestrator-workers with subagents. Design.
A lead agent reads last week's brief and the program list, then creates one task per program with an explicit brief: what changed since a date, which sources to check, the output format (status, new events with dates and source links, confidence), and a word limit. Subagents (fast or balanced tier) each research one program with read-only search tools and return a compact structured summary, never their full transcripts.
The lead synthesizes the summaries into the brief, highlighting the five most significant changes.
An evaluator step checks every claim has a source link and flags claims whose source is older than the reporting window.
The analyst reviews and edits before distribution (medium-risk tier).
Controls. Max 40 subagents per run, each with a turn limit and a token budget; total spend cap per run; no write or outbound communication tools; sources restricted to an allowlist of sites and databases.
What would make this the wrong answer? If the brief covered three programs from one source, a single agent or even a workflow would be cheaper and more reliable.
Worked example 2.3: putting numbers on value and cost
Executives and the exam both expect a simple, honest model. Here is a template using illustrative prices (replace with current list prices from Anthropic or your cloud platform).
Line Assumption Monthly figure
Volume 50,000 support conversations 50,000
Tokens per conversation 6,000 input (of which 4,500 cached system prompt and policy), 600 output
n/a
Model cost per conversation Illustrative balanced-tier prices, cached reads at a fraction of input price
Human review 10% of conversations reviewed at 2 minutes, $40/hour loaded $6,700 Total run cost Sum about $14,000
Value 30% deflection × 50,000 × $6 cost per human-handled contact $90,000 Three lessons the exam tests: model tokens are often not the biggest cost line; human review is a real cost that falls as quality is proven; and value is stated against a measured baseline (here, cost per human-handled contact).
Scenario drills
Work each one in under two minutes, then check the answer.
Contract clause comparison. Legal wants each new supplier contract compared against a 40-clause playbook, with deviations flagged. Contracts are 20 to 80 pages. Pattern? IT helpdesk. 30% of tickets are password resets and access requests that follow a fixed procedure; 70% are varied troubleshooting. Pattern? Marketing copy. The brand team wants five headline variants per product, checked against brand guidelines. Pattern?
Due diligence. An M&A team must review a data room of 4,000 documents for 25 risk categories in a week. Pattern? Real-time fraud explanation. A card network needs a plain-language reason for each declined transaction within 300 milliseconds. Is Claude in the hot path? Internal policy chatbot. 2,000 employees, 120 pages of policy, updated quarterly. Pattern and retrieval?
SOLUTION DESIGN & ARCHITECTURE (17%)
Answers.
Workflow with sectioning: split the contract by clause, compare each against its playbook entry in parallel, aggregate. An evaluator-optimizer pass can check that every playbook clause was addressed.
Routing: classify first; the fixed-procedure tickets go to a deterministic workflow with tool calls (with identity verification), the rest to an agent with read-only diagnostic tools or to a human with a drafted summary.
Evaluator-optimizer: generate variants, a second call scores them against the brand rubric, regenerate the weakest. Human picks.
Parallelized workflow at scale with batch processing, or orchestrator-workers if the categories require following leads between documents. Human reviewers confirm every flagged risk.
Probably not in the 300 ms hot path. Generate the explanation asynchronously after the decision, or precompute explanation templates per reason code. Know when the SLA rules a pattern out.
Augmented LLM. 120 pages may fit in context with caching; if it does not, or if quality degrades, use RAG with structure-aware chunking. Re-ingest quarterly with versioning.
Common traps
Picking an agent for a task with fixed steps.
Adding agents to fix a quality problem that is really a prompt or retrieval problem. Designs with no feedback loop or no human-review path.
Ignoring the SLA: a five-hop agent cannot meet a 2-second p95.
Check yourself
A bank wants to triage 10,000 inbound emails a day into 12 queues with a 3-second budget. Which pattern?
When does orchestrator-workers beat parallelization?
Name three hard limits you would put on an autonomous agent.
A design shows input, model, and output only. What is missing and why does it matter? Answers: (1) Routing: a fast classifier call with structured output, possibly a small model, no agent. (2) When the subtasks cannot be known in advance and the lead must decide them from the input. (3) Max turns, max spend or tokens, wall-clock timeout (also tool allowlist). (4) The feedback loop; without it you cannot detect drift or improve the evaluation set.