Part 1 — Domain 1: Solution Design & Architecture (17%)
Prep-course lesson: Claude Platform & Solution Design. Official tasks: translate business problems · end-to-end architectures · pattern selection (workflow / agentic / augmented LLM) · multi-agent and orchestration · decomposition · business value pillars.
Topics: 1.1 Business problem → Claude solution · 1.2 Pattern selection · 1.3 Decomposition and multi-agent design · 1.4 End-to-end architecture, PoC→production, and ADRs
1.1 Translating a business problem into a Claude solution
1. Learning objectives. Turn an ambiguous request into a scoped problem statement with measurable success criteria; decide whether an LLM is the right tool; map the problem to a business value pillar (efficiency, transformation, productivity, cost, performance SLA).
2. Prerequisites. Basic LLM capabilities/limits (AI Capabilities and Limitations course); Messages API concepts.
3. Beginner explanation. Stakeholders say "we want an AI assistant." Your job is to ask what decision or task gets better, for whom, how we'd measure it, and what happens when it's wrong. Claude is strong at language-heavy, variable-input work (summarize, classify, extract, draft, reason over documents). It is a poor substitute for exact arithmetic, deterministic rules, or anything needing guaranteed-correct output with no review.
4. Advanced explanation. Frame each candidate task on four axes: input variability (high favors LLM), error tolerance / reversibility (low tolerance demands controls or human review), volume × latency (drives model tier, caching, batch), and data sensitivity (drives integration and governance). Some questions on the exam test when not to use Claude — e.g., a fixed-schema lookup or a rule that regulators require to be deterministic should be code. Value pillars let you justify the project in the sponsor's language: efficiency (cost per case), transformation (new capability), productivity (hours saved), cost, performance SLA (time-to-resolution).
5. Step-by-step. 1. Write the problem as: "For [user], reduce [pain] from [baseline] to [target] by [date], without [constraint]." 2. List candidate tasks; score each on the four axes. 3. Choose the thinnest slice that proves value (one workflow, one user group). 4. Define success criteria (accuracy, latency, cost/case, safety) before design — these become eval acceptance criteria (D4). 5. Identify the data, systems, and approvers involved. 6. Record assumptions and open questions.
6. Diagram.
flowchart LR
A[Business request] --> B[Discovery: user, pain, baseline]
B --> C{LLM-suited?<br/>variable input, tolerable error}
C -- No --> D[Deterministic code / rules]
C -- Yes --> E[Success criteria + value pillar]
E --> F[Thin-slice scope]
F --> G[Architecture options → ADR]
7. Scenario. An insurer says "automate claims." Discovery reveals 70% of handling time is reading adjuster notes and policy PDFs to draft a coverage summary; payout decisions must stay human. Scope: draft coverage summaries for adjusters (productivity pillar), not "automate claims."
8. Recommended design & alternatives. Recommend a single augmented-LLM call with retrieval over the policy (see 1.2). Alternatives: full agent (unneeded autonomy); rules engine (can't read free-text notes); manual process with templates (no productivity gain). Change the decision if notes are structured enough for rules, or if accuracy targets can't be met in the pilot eval.
9. Security/governance. Classify data (PII/PHI), identify approvers (legal, security) early; keep humans on irreversible decisions (payout).
10. Performance/cost/reliability. Estimate tokens per case × volume × price; decide sync vs. batch from the SLA; plan for fallback when the API is unavailable.
11. Common mistakes. Building before defining success; scoping to the whole process; treating a demo as evidence; ignoring baseline measurements; skipping "what if it's wrong?".
12. Scenario question (practice). A sponsor wants "an AI to approve refunds." Refunds under $50 are policy-defined; above are judgment calls. Best first step? → Separate the deterministic policy path (code) from the judgment path; use Claude to draft recommendations for human approval on the latter. (Principle: use LLMs where variability exists; keep deterministic rules deterministic.)
13. Quick revision. Problem statement → LLM-suitability on four axes → thin slice → success criteria first → value pillar → document assumptions.
14. Official docs. Prep course Lesson 1; Exam Guide §6 D1; https://platform.claude.com/docs/en/test-and-evaluate/define-success (define success criteria).
1.2 Selecting the architectural pattern: augmented LLM, workflow, or agent
1. Learning objectives. Choose among a single augmented LLM call, a predefined workflow, and an agent; justify with predictability, flexibility, latency, cost, and error-compounding.
2. Prerequisites. Tool use basics; MCP overview.
3. Beginner explanation. Anthropic distinguishes workflows (LLMs and tools orchestrated through predefined code paths) from agents (LLMs dynamically direct their own process and tool use). The basic building block is the augmented LLM — an LLM with retrieval, tools, and memory. Start with the simplest thing that works.
4. Advanced explanation. Anthropic's "Building effective agents" describes workflow patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — and recommends adding complexity only when it demonstrably improves outcomes. Trade-offs: workflows give predictability and consistency for well-defined tasks; agents suit open-ended problems where steps can't be hardcoded but progress can be verified. Agents cost more latency and tokens and compound errors across steps; they need stopping conditions, budgets, and strong evals.
| Pattern | Use when | Cost of choosing it |
|---|---|---|
| Single augmented call | One-shot Q&A, classify, extract, draft | Lowest latency/cost; limited multi-step reasoning |
| Prompt chaining | Task decomposes into fixed sequential steps | Added latency per step; easy to debug |
| Routing | Distinct input categories need distinct handling | Router accuracy becomes a failure point |
| Parallelization | Independent subtasks or voting for confidence | More tokens; aggregation logic |
| Orchestrator-workers | Subtasks unknown in advance | Higher cost; harder to evaluate |
| Evaluator-optimizer | Clear quality criteria, iterative refinement helps | Loop cost; needs a reliable evaluator |
| Agent | Open-ended, tool-heavy, verifiable progress | Highest cost/variance; strongest controls needed |
5. Step-by-step. (1) Try a single call with good prompt + context. (2) If failures cluster in distinct sub-steps, add a chain or router. (3) If subtasks are independent, parallelize. (4) Only if the path can't be predefined, use an agent with budgets (max steps, tokens, time), tool allow-list, and human gates. (5) Compare each step up using your evals, not intuition.
6. Diagram.
flowchart TD
S[Task] --> Q1{One call with<br/>retrieval/tools enough?}
Q1 -- Yes --> A[Augmented LLM]
Q1 -- No --> Q2{Steps known in advance?}
Q2 -- Yes --> W[Workflow: chain / route / parallel]
Q2 -- No --> Q3{Progress verifiable +<br/>budget bounded?}
Q3 -- Yes --> AG[Agent with guardrails]
Q3 -- No --> H[Human-in-loop / rethink scope]
7. Scenario. IT help desk: 80% of tickets are password/VPN/access requests with known fixes; 20% are novel. Design: router classifies; known categories run deterministic workflows calling the ITSM API; novel tickets go to an agent with read-only diagnostics and human escalation.
8. Recommended design & alternatives. Hybrid: route-then-workflow, agent only for the long tail. Alternatives: one giant agent for everything (cost, variance, harder security story); pure rules (can't handle novel). Change if router accuracy is poor (merge categories) or the long tail grows (invest in the agent).
9. Security. Autonomy widens the blast radius. Give each path the minimum tools; keep write actions behind approval; treat tool results as untrusted (D5).
10. Cost/latency/reliability. Per-step latency adds; agent token use is variable — enforce budgets; workflows are easiest to give SLAs.
11. Mistakes. Agent-by-default; no step budget; evaluating only final answers; framework complexity obscuring prompts; one prompt doing five jobs.
12. Scenario question. A nightly job extracts 12 fields from invoices in 4 known formats. Which pattern? → Routing (by format) + single extraction calls, run through batch for cost; not an agent.
13. Revision. Simple → chain/route/parallel → agent only when needed; add complexity only when evals prove value.
14. Docs. https://www.anthropic.com/research/building-effective-agents · Prep Lesson 1.
1.3 Decomposition and multi-agent orchestration
1. Objectives. Decompose complex problems; decide when multi-agent beats single-agent; design orchestration, context isolation, and result aggregation.
2. Prerequisites. 1.2; context windows (D2).
3. Beginner. Break a big task into smaller ones each with its own focused prompt and tools. In multi-agent systems, an orchestrator delegates subtasks to workers that run with their own context.
4. Advanced. Reasons to split: (a) context isolation (a worker explores noisily and returns a summary, protecting the orchestrator's context); (b) parallelism for independent subtasks; (c) specialization (different tools, prompts, or model tiers per worker); (d) least privilege (a research worker has no write tools). Costs: more tokens overall, coordination failures, harder evaluation, and error propagation. Decompose along natural seams: by data source, by document, by stage, by risk level. Pass structured, minimal handoffs (typed results, citations) rather than transcripts. A cheaper model can do worker tasks while a stronger one orchestrates.
5. Steps. (1) List subtasks and dependencies. (2) Mark independent ones (parallel). (3) Assign tools/permissions per worker. (4) Define the handoff schema. (5) Define orchestrator stop conditions and budgets. (6) Evaluate workers independently and end-to-end.
6. Diagram.
flowchart LR U[User question] --> O[Orchestrator] O --> W1[Worker: policy docs<br/>read-only] O --> W2[Worker: CRM lookup<br/>read-only] O --> W3[Worker: web research<br/>untrusted content] W1 --> R[Structured findings + citations] W2 --> R W3 --> R R --> O --> A[Answer + sources]
7. Scenario. Due-diligence assistant reviewing 200 contracts: one worker per contract extracts clauses to a schema; orchestrator aggregates risk themes. A web-research worker handles untrusted external content in isolation so injected instructions can't reach the contract tools.
8. Recommended/alternatives. Orchestrator-workers with typed outputs. Alternative: one agent loops through all contracts (context overflow, slow, no isolation). Change if subtasks are tiny (overhead dominates) or tightly coupled (shared state makes parallelism fragile).
9. Security. Isolation boundaries are security boundaries: separate identities/tool sets per worker; sanitize and validate worker outputs before the orchestrator acts on them.
10. Cost/latency. Parallelism cuts wall-clock but multiplies tokens; use smaller models for mechanical workers; cache shared prefixes.
11. Mistakes. Multi-agent for simple tasks; passing full transcripts; no schema; no per-worker eval; shared credentials across workers.
12. Scenario question. A research agent's context fills with raw search results and quality drops. Fix? → Delegate searching to worker(s) that return concise structured findings (context isolation).
13. Revision. Split for isolation, parallelism, specialization, least privilege; hand off structured results; evaluate parts and whole.
14. Docs. Building effective agents (orchestrator-workers); Prep Lesson 1.
1.4 End-to-end architecture, PoC → production, and Architecture Decision Records
1. Objectives. Draw an input → processing → output → feedback-loop architecture; distinguish PoC from production design; write an ADR that states alternatives and reversal triggers.
2. Prerequisites. 1.1–1.3.
3. Beginner. Every Claude system has inputs (user/system events), processing (prompting, retrieval, tools, orchestration), outputs (UI/API/action), and a feedback loop (user ratings, human corrections, monitoring) that drives improvement.
4. Advanced. PoC proves possibility (happy path, small data, manual review, no SLA). Production adds: identity, authZ, error handling, observability, evals as release gates, cost controls, rollback, ownership (D3–D7). Architects fail by shipping a PoC. An ADR records: context, decision, alternatives considered, consequences, and triggers for revisiting (e.g., "switch to a smaller model if p95 latency > 3 s at < 2% accuracy loss").
5. Steps. (1) Draw the data/control flow with trust boundaries. (2) Mark where Claude is called, what context it gets, what it can do. (3) Add feedback capture. (4) List NFRs (latency, cost, availability, compliance). (5) Write ADRs for each significant decision. (6) Gap-analyze PoC → production.
6. Diagram.
flowchart LR
subgraph Inputs
U[User] ; E[Events]
end
subgraph Processing
G[Gateway: authN, rate limit] --> P[Prompt assembly + retrieval]
P --> C[Claude] --> T[Tool broker: authZ, validation]
end
subgraph Outputs
R[Response / Action] --> H[Human review if high risk]
end
U --> G
E --> G
T --> R
R --> F[(Feedback + traces)]
F --> EV[Evals / improvement]
EV -.-> P
7. ADR template (use it).
ADR-007: Use routing + deterministic workflows for tier-1 tickets
Status: Accepted | Date: … | Owners: …
Context: 80% of tickets are 6 known categories; SLA p95 < 4 s; cost ≤ $0.02/ticket.
Decision: Haiku-class router → per-category workflow; agent only for "other".
Alternatives: (A) single agent — rejected: variance, cost; (B) rules only — rejected: free-text tickets.
Consequences: router errors misroute (mitigation: confidence threshold → agent); more prompts to maintain.
Revisit if: router accuracy < 95% on regression set, or "other" > 35% of volume.
Evidence: eval run #42, cost model v3.
8. Recommended/alternatives. Always pair a recommendation with 2+ alternatives and a reversal trigger — this is explicitly how the prep course frames defensibility.
9. Security. Mark trust boundaries on the diagram; list who approves; put audit logging in the design, not as an afterthought.
10. Cost/latency/reliability. State budgets per request; define degradation (cached answer, smaller model, "try later"); design timeouts and retries (D3).
11. Mistakes. No feedback loop; undocumented decisions; PoC data ≠ production data; no owner; no rollback.
12. Scenario question. A PoC works on 50 curated documents. Which gap most threatens production? → No evaluation on realistic data, observability, and access control — not model choice. (Principle: production readiness is about the system around Claude.)
13. Revision. I→P→O→feedback; PoC vs production gaps; ADR = decision + alternatives + reversal triggers + evidence.
14. Docs. Prep Lessons 1–2; Messages API https://docs.claude.com/en/api/messages.