Domain 1: Solution Design & Architecture
17% of examTranslate a business problem into a Claude-based solution design
Key Points
- Design flow: elicit the business outcome, derive functional/non-functional requirements, then choose the architecture that meets them at acceptable cost.
- Extract six dimensions before picking a pattern: latency, volume/scale, criticality, data sensitivity, cost ceiling, and quality bar.
- These constraints -- not preference -- decide realtime vs. batch, model tier, integration protocol, and human-in-the-loop placement.
- Every architectural decision should be traceable to a stated constraint, not a default preference.
- Production designs add evaluation, observability, security, and lifecycle as first-class concerns from day one -- a POC is not production.
Decision Rules
When: A stakeholder asks for 'an agent' or 'the biggest model' before constraints are established
→Anchor on the six dimensions first; do not commit to autonomy or model tier until requirements justify it.
When: The task describes fixed, known steps with a predictability requirement
→Recommend a workflow, not an agent, regardless of how capable the model is.
When: You are asked to 'design a solution' rather than 'build a demo'
→Explicitly include evaluation, observability, security, and lifecycle as parts of the answer, not afterthoughts.
✗ Anti-Patterns to Reject
- Jumping to 'use an agent' or 'use the biggest model' before the requirements justify it.
- Treating a proof-of-concept design as production-ready, omitting evaluation, observability, security, and lifecycle.
Select among the augmented LLM, workflow, and agentic architectural patterns
Key Points
- Three patterns on a complexity gradient: augmented LLM (base unit), workflow (predefined code paths), agent (LLM-directed loop).
- The augmented LLM -- model + retrieval + tools + memory -- is the atomic unit that workflows and agents compose.
- Workflows fit known, fixed steps where predictability and testability matter; agents fit open-ended tasks whose steps can't be enumerated in advance.
- Agents run plan -> call tool -> observe -> repeat, trading latency/cost/predictability for handling open-ended tasks.
- Five workflow composition patterns: prompt chaining, routing, parallelization (sectioning/voting), orchestrator-workers, evaluator-optimizer.
- Exam trap: the line between orchestrator-workers and parallelization sectioning is who decides the subtasks, and when.
Decision Rules
When: The task is the same fixed sequence every time
→Use prompt chaining.
When: Input falls into distinguishable categories needing different handling
→Use routing.
When: Independent subtasks are known in advance vs. must be decided by a central LLM at runtime
→Use parallelization (sectioning) for the former; use orchestrator-workers for the latter.
When: Output quality benefits from a critique-and-refine cycle
→Use evaluator-optimizer.
✗ Anti-Patterns to Reject
- Confusing orchestrator-workers (subtasks decided dynamically at runtime) with parallelization sectioning (subtasks known in advance).
- Escalating to a workflow or agent before confirming a single augmented LLM call can't satisfy the requirement.
Design end-to-end architecture with input, processing, output, and feedback loops
Key Points
- End-to-end architecture shape: input -> processing -> output -> feedback loops.
- Input stage: ingestion, validation, separating trusted instructions from untrusted data, retrieval of grounding context.
- Processing stage: the chosen pattern (augmented LLM/workflow/agent), model selection, prompt/context assembly.
- Output stage: structured-output contracts, validation, defensive parsing, delivery to downstream systems.
- Feedback loops (evaluation, monitoring, observability) are mandatory, not optional, because LLM output is non-deterministic.
Decision Rules
When: Asked to 'design the architecture' for a system
→Walk through all four stages explicitly -- an answer that only addresses processing is incomplete.
When: A new model version ships
→Rely on the feedback loop (evals/monitoring) to detect regressions rather than assuming behavior is unchanged.
When: Untrusted data enters at the input stage
→Separate it from trusted instructions before it reaches the model.
✗ Anti-Patterns to Reject
- Stopping the design at 'output' with no plan for evaluation or monitoring.
- Treating feedback loops as optional because 'the demo worked.'
Design multi-agent systems and orchestration for genuinely separable work
Key Points
- A manager/orchestrator coordinates specialized subagents, each with its own context window, returning only a condensed result.
- Context isolation is the defining benefit -- a subagent can read a lot and return only a condensed result.
- Specialization lets each subagent get a focused prompt, tool set, and model tier (Haiku for cheap steps, Sonnet/Opus for hard ones).
- Multi-agent hierarchies multiply token usage and add real coordination overhead -- reserve them for genuinely separable, expensive-enough work.
- A single well-scoped augmented LLM often wins on cost and latency over a multi-agent design.
Decision Rules
When: A subtask requires reading far more material than the final answer needs
→Delegate it to a subagent for context isolation.
When: Subtasks are independent
→Run subagents in parallel for the parallelism benefit.
When: Considering a multi-agent design
→First check whether a single augmented LLM or simpler workflow would satisfy the requirement at lower cost and latency.
✗ Anti-Patterns to Reject
- Treating subagents as 'just more prompts' instead of valuing their separate context window.
- Assuming a multi-agent design is automatically better or higher quality than a single augmented LLM.
Apply decomposition techniques to make complex problems tractable
Key Points
- Four decomposition techniques: sequential, parallel, routing, recursive/hierarchical.
- Sequential decomposition (prompt chaining) fits ordered sub-steps that depend on the last.
- Parallel decomposition fits independent subtasks that run concurrently and merge.
- Routing decomposition classifies first, then sends each class down a specialized path.
- Decomposition improves reliability: smaller steps are easier to prompt, evaluate, and debug, and boundaries are natural gate-check points.
Decision Rules
When: Each step needs the previous step's output
→Use sequential decomposition.
When: Subtasks are independent and can run at once
→Use parallel decomposition.
When: Inputs fall into distinguishable categories
→Use routing decomposition.
When: The task needs open-ended delegation that may itself need further breakdown
→Use recursive/hierarchical decomposition.
✗ Anti-Patterns to Reject
- Using one sprawling mega-prompt instead of decomposing into well-scoped steps with clear input/output contracts.
- Skipping gate checks or validation at decomposition boundaries.
Align architectural decisions to business value pillars
Key Points
- Five business value pillars: efficiency, transformation, productivity, cost, and performance/SLAs.
- Every architectural tradeoff should be traceable to one of the five pillars.
- 'Smaller model + prompt caching' serves cost/performance; 'human-in-the-loop review' serves risk/quality.
- Optimizing an unrequested metric (e.g., latency) at the expense of a requested one (e.g., cost) is wrong even if it looks like an improvement.
Decision Rules
When: A stakeholder states cost as the goal for a high-volume, latency-tolerant job
→Route to a smaller model tier and/or batch it -- not the largest model 'for reliability.'
When: You cannot name the pillar a proposed change serves
→Treat the change as not yet justified.
When: Choosing a tradeoff lever
→Pick the one that most directly serves the stated pillar (model tier/batching for cost, caching/async for performance, human review for quality/risk).
✗ Anti-Patterns to Reject
- Optimizing a metric the business didn't ask for (e.g., squeezing latency) at the expense of one it did (cost, quality).
- Swapping in the largest, most capable model 'for reliability' when the stated goal is cost reduction.