Domain 1 – Solution Design & Architecture (17%)

• Translate business problems into end-to-end Claude architectures
• Choose among workflow, agentic, and augmented-LLM patterns
• Multi-agent orchestration strategies and when they earn their complexity
• Decomposition techniques that preserve business value
• Align solutions to efficiency / transformation / productivity / cost / SLA pillars

CCAR-P Domain 1 · Task 1.1

What You Need to Know

Translating a business problem into a Claude solution produces a measurable success criterion, a bounded scope, and a defensible boundary between the model and ordinary software.

Problem-First Design (before any pattern/model/prompt)

1. The job to be done — who, how long, cost, where it goes wrong
2. The constraint set — latency, cost, accuracy, risk, data sensitivity, regulatory
3. The success criterion — metric + baseline + target (defined before build)

Key Concept: Define measurement before implementation. Sequence: problem → constraints → success criterion → solution shape.

The Fit Test: Is This an LLM Problem?

Claude belongs where the task needs language understanding, synthesis, judgement over unstructured input, or flexible conversation. Deterministic rules → conventional software (cheaper, faster, exact, auditable). Most production solutions are hybrids.

Capability Mapping (task shapes)

Task shape	Architecture implication	Evaluation
Classification	Single call, constrained output	Accuracy vs labelled set
Extraction	Structured output + schema validation	Field-level precision/recall
Summarisation	Single call, grounding checks	Faithfulness / similarity
Generation	Draft-for-review, tone constraints	Rubric-graded quality
Conversation	Context management, session state	Multi-turn quality + safety
Agentic action	Tools, guardrails, observability	End-to-end task success rate

Scoping

Start with the narrowest workflow that delivers measurable value, prove it, then expand. Targeted workflow beats general-purpose assistant on every business-value pillar.

Exam Traps

• Proposing a general-purpose assistant when the case names one high-volume workflow
• Selecting architecture before capturing constraints and success criteria
• Routing a fully rule-specified sub-task through a model call

Practice Scenario

Insurer: claims handler must still approve every settlement. 70% of handler time is summarising files and drafting letters. What solution first?

Build Exercise: Write a One-Page Solution Brief (30 min)

CCAR-P Domain 1 · Task 1.2

What You Need to Know

Every production Claude system has six stages:

1. Input — ingestion, validation, normalisation, PII handling (decide before model)
2. Context assembly — retrieval, memory, prompt construction
3. Processing — model call(s): single, workflow, or agent loop
4. Output — schema validation, business-rule checks, guardrail screening, designed failure path. Model output is untrusted until validated.
5. Delivery — sync, async, event, or draft-for-review (risk decision)
6. Feedback loops — user feedback, automated eval on sampled traffic, monitoring → iteration

Key Concept: The two stages most often missing are output validation and the feedback loop.

Design for Failure

• Timeouts, retries with backoff, and idempotency around every model call
• Designed degraded path for every failure mode (queue for human, cached answer, clear error). Never silent.
• Blast-radius analysis: what happens downstream when the model is wrong determines validation/review level.

Exam Traps

• Piping model responses into downstream systems without validation
• Shipping with no quality-signal capture or iteration path
• Silent failure (empty/default output with no signal)
• Fixing unmeasurable quality by upgrading the model

Practice Scenario

Contract-review assistant: lawyers upload, Claude analyses, risk report emailed. Quality inconsistent; team cannot say which reports were wrong or why. Root-cause fix?

Build Exercise: Six-Stage Architecture Audit (30 min)

CCAR-P Domain 1 · Task 1.3

What You Need to Know

Three Tiers (Anthropic)

Tier	Description	When
Augmented LLM	Single model call + retrieval/tools/memory	Default for most problems
Workflow	Predefined code paths orchestrate LLMs + tools	Steps known; need predictability, auditability
Agent	Model dynamically directs its own processes/tools	Path cannot be scripted

Five Workflow Patterns

Pattern	Selection cue
Prompt chaining	Task decomposes into fixed sequential subtasks
Routing	Distinct input categories better handled separately
Parallelisation	Independent subtasks or multiple perspectives (sectioning / voting)
Orchestrator-workers	Subtasks cannot be predicted in advance
Evaluator-optimizer	Clear evaluation criteria exist and iteration helps

Decision Rule

Find the simplest solution that meets requirements; add complexity only when it demonstrably improves outcomes. Escalate tier only when the simpler tier cannot meet a named requirement.

Key Concept: Workflows beat agents when steps are known. Agents earn cost when the path cannot be scripted.

Exam Traps

• Deploying an autonomous agent for a fixed, well-specified pipeline
• Choosing chaining when the scenario describes distinct categories (want routing)
• Choosing evaluator-optimizer with no clear evaluation criteria
• One monolithic prompt for a task that needs staged quality gates

Practice Scenario

Support tickets classified into five categories, then answered or escalated. Each category has its own rules; change to one must not alter others. High volume, latency matters, consistent & auditable. Best architecture?

Build Exercise: Pattern Selection Matrix (25 min)

CCAR-P Domain 1 · Task 1.4

What You Need to Know

When Multi-Agent Is Justified

Excels at breadth-first work that parallelises cleanly: research across independent directions, analysis of many independent units, tasks exceeding one context window, work needing distinct specialisms/tools/permissions.

Cost: ~15× tokens of chat. Value must pay for the multiplier.

Key Concept: Justify the architecture first. Multi-agent for a task one agent handles well is a wrong answer.

Orchestrator-Worker Architecture

• Subagents start with a fresh context (unless forked). Context must be passed explicitly.
• Delegation quality determines system quality. Effective brief: explicit objective, expected output format, tool/source guidance, clear task boundaries.

Failure Modes

Failure	Signature / Root cause
Narrow decomposition	Systematic gaps — coordinator's split incomplete
Duplicated work	Overlapping scopes — boundaries never partitioned
Effort mismatch	Too many agents for simple fact-check
Lost attribution	Findings as free prose lose sources

Duplication + gaps = unpartitioned coordinator decomposition.

Orchestration Strategy

• Parallel where independent, sequential where dependent
• Durable state and checkpointing
• Observability of agent decisions
• Through-the-coordinator is the default topology

Exam Traps

• Diagnosing overlapping/missing sections as a subagent capability problem
• Assuming subagents can see coordinator conversation or each other
• Proposing multi-agent for a task that fits one context window
• Fixing coverage gaps by adding more subagents (same briefs)

Practice Scenario

Due-diligence system: coordinator + six parallel research subagents. Reports arrive with three nearly identical sections and two risk areas missing. Root cause?

Build Exercise: Design a Bounded Orchestrator (30 min)

CCAR-P Domain 1 · Task 1.5

What You Need to Know

Fixed vs Dynamic Decomposition

Type	When	Pattern
Fixed (design time)	Steps known in advance	Prompt chaining
Dynamic (run time)	Shape emerges during execution	Orchestrator-workers

Four Decomposition Axes

• By stage — sequential phases with hand-offs (later depends on earlier)
• By section — independent units in parallel
• By perspective — same input through different lenses / voting
• By specialism — different tools, prompts or models needed

Attention Dilution

One pass covering too much → inconsistent depth, missed items, contradictory judgements.

Fix (both mandatory):

1. Per-unit local passes (consistent depth on every unit)
2. Separate integration pass (cross-unit issues invisible to local passes)

Bigger model / larger context window does not fix attention dilution.

Interface Discipline

• Intermediate outputs structured against a defined schema (not free prose)
• Acceptance gates between stages (stop error propagation)
• Attribution travels as fields

When Not to Decompose

Decompose only when quality improves, task cannot fit one context, or stages need independent verification. Otherwise stay in one call.

Exam Traps

• Splitting a one-call task into a multi-stage pipeline for “rigour”
• Fixing inconsistent depth with a larger model or bigger context
• Local passes only, no integration pass
• Passing free-text summaries between stages

Practice Scenario

Compliance team checks 400-page loan agreements against 60 policy rules. Single-prompt approach misses violations inconsistently. What should the architect design?

Build Exercise: Decompose a Document-Analysis Pipeline (30 min)

CCAR-P Domain 1 · Task 1.6

What You Need to Know

Five Business Value Pillars

Pillar	Meaning
Efficiency	Same outcome with less input (automating existing process)
Transformation	Capabilities not previously possible
Productivity	People ship more/better with AI assistance
Cost	Unit economics vs human/legacy baseline
Performance SLAs	Contractual latency, availability, quality targets

Test: does the capability already exist? Yes → efficiency. No → transformation.

Design Decisions Tied to Pillars

• Model selection — per-task cost/performance; smallest model that meets quality bar
• Prompt caching — ~90% cache-read cost reduction; serves cost + latency SLA (static first, dynamic last)
• Batch processing — halves cost of async work; sacrifices request-path latency
• Multi-agent — ~15× tokens; name the pillar that pays for it

Key Concept: Caching helps repeated static prefixes on the request path. Batching helps asynchronous volume off the request path. They are directional opposites on latency.

SLA Engineering

• Latency: p95 budget decomposes into per-stage budgets; stage times sum
• Availability: forces fallback design (degraded modes, queuing, human fallback)
• Quality: accuracy floors require evaluation machinery in the feedback loop

Value Case

Baseline before build. State hypothesis (pillar, metric, target, how measured) and verify after.

Exam Traps

• Defaulting to the most capable model for every task
• Classifying automation of an existing process as transformation
• Offering batch for interactive use cases (or caching for one-off async volume)
• Accepting sequential large-model calls against a tight p95, or availability with no fallback

Practice Scenario

Bank wants customer-email drafting assistant for relationship managers: p95 ≤ 3 s and strict per-email cost ceiling. Best design?

Build Exercise: Write the Value Case and SLA Budget (30 min)