CCAR-P · module 1 of 7 · 17% of the exam

Solution design and architecture

Covers the 6 official objectives: translate business problems into Claude solutions; design end-to-end architectures; select architectural patterns (workflow/agentic/augmented LLM); design multi-agent systems and orchestration; apply decomposition techniques; align to business value pillars.

Objective: Translate business problems into Claude-based AI solutions

• Core concept: Before picking a pattern or a model, restate the business problem as: input source → desired output → who consumes it → what "good" looks like (metric). An architect's first move is a requirements pass, not a tool choice.
• Anthropic-platform specifics:
  • Map the ask to a tier: single LLM call (classification/extraction/summarization/Q&A) vs. workflow (code-controlled multi-step) vs. agent (open-ended, model-driven tool use) vs. Managed Agents (server-hosted stateful agent with its own sandbox).
  • Four criteria gate "should I build an agent at all": Complexity (is it multi-step and hard to fully specify up front?), Value (does the outcome justify latency/cost?), Viability (is Claude actually capable at this task type?), Cost of error (can mistakes be caught/rolled back — tests, review, human review?). If any answer is "no," stay at a simpler tier.
  • "Start simple" is a graded default, not a slogan: prefer the least amount of code you own. For a hosted/scheduled/memory-backed agent, Managed Agents can be the simplest choice (no loop code, no state files, no scheduler) even though it's the biggest platform surface.
• Decision heuristic: If the task can be fully specified as "given X, produce Y," it's a single call or workflow — don't reach for agentic delegation. If the task requires the model to decide what to do next based on intermediate results (e.g., "investigate this outage"), it's agentic.

Objective: Design end-to-end architectures (input → processing → output → feedback loops)

• Core concept: A complete solution has four stages architects must explicitly design, not just the "call the model" middle: (1) input ingestion/normalization, (2) processing (the model + tools + context), (3) output delivery/formatting, (4) feedback loop (how the system gets better over time — logging, evals, human corrections feeding back into prompts/data).
• Anthropic-platform specifics:
  • Input stage: consider Files API for reusable documents (PDF, images) across multiple calls instead of re-uploading base64 each time; Batches API for non-latency-sensitive bulk input at 50% cost.
  • Processing stage: model tier selection, system prompt design, tool surface, context management (compaction/context editing/memory for long-running work).
  • Output stage: structured outputs (output_config.format with JSON schema) when downstream systems need guaranteed-parseable output rather than prose; citations when the answer must be traceable to source documents.
  • Feedback loop: observability (logging via usage, _request_id), eval datasets sourced from real production failures, and — for agents — memory tools/memory stores so lessons persist across sessions rather than being re-derived every run.
  • A feedback loop without a metric is not a feedback loop — tie it to the eval framework from Domain 4.
• Decision heuristic: If a proposed architecture diagram has no arrow going back from output to processing/input, the feedback loop is missing — that's an incomplete design, not a stylistic choice.

Objective: Select architectural patterns (workflow, agentic, augmented LLM)

• Core concept: Three named patterns, ordered by increasing autonomy and increasing token/latency cost:
  1. Augmented LLM — a single call enriched with retrieval, tools, and memory, but the caller (your code) still decides what happens next. No loop.
  2. Workflow — your code orchestrates a fixed, predefined sequence of LLM calls and tool calls (e.g., prompt chaining, routing, parallelization, orchestrator-worker, evaluator-optimizer). Control flow is code-defined and predictable.
  3. Agentic — the model decides the sequence of actions in a loop (tool_use → execute → feed back → repeat) until it determines the task is done. Control flow is model-defined and open-ended.
• Anthropic-platform specifics:
  • Workflow sub-patterns worth naming on the exam: prompt chaining (sequential steps, each validates the previous), routing (classify then dispatch to a specialized prompt/model), parallelization (fan out independent subtasks, aggregate), orchestrator-workers (a lead call decomposes and delegates), evaluator-optimizer (one call generates, another critiques/scores, loop until it passes — this is the same shape as Managed Agents' Outcome/rubric grading).
  • Agentic pattern in the API = the Tool Runner or a manual while stop_reason == "tool_use" loop; in Managed Agents = the session event loop, hosted by Anthropic.
  • Prefer workflow over agentic whenever the sequence of steps is knowable in advance — it's cheaper, faster, and more predictable to test.
• Exam heuristic: "The steps are known and fixed" → workflow. "The model must decide what to investigate next based on what it finds" → agentic. "One call, enriched with context/tools, no loop" → augmented LLM.

Objective: Design multi-agent systems and orchestration strategies

• Core concept: Multi-agent designs exist to parallelize independent work or to give subagents separate, uncontaminated context windows — not simply "more agents = better."
• Anthropic-platform specifics:
  • API-level: spawn subagents as separate messages.create()/tool-runner calls with their own system prompt and tool surface; the orchestrator aggregates results. Each subagent's context is isolated — good for parallel independent research, bad if the subagent needs the full shared history.
  • Managed Agents: multiagent: {type: "coordinator", agents: [...]} on the agent config — roster of up to 20 agents (by ID, pinned version, or {type:"self"}), each running in its own thread sharing only the container filesystem, not conversation history. One level of delegation only (depth > 1 is ignored). Cross-thread tool confirmations are cross-posted to the primary thread so you only watch one stream.
  • Coordination costs: every subagent call is a fresh context (no free cache reuse across differently-configured subagents), and cross-agent coordination overhead (message-passing, result aggregation) grows with agent count — don't add agents past the point where the task is genuinely parallel/independent.
• Decision heuristic: Use multiple agents when subtasks are independent (parallelizable, benefit from isolated context) or need different tool surfaces/expertise (e.g., a reviewer agent with read-only tools vs. an implementer agent with write access). Do not use multiple agents just to "feel" more sophisticated, or for strictly sequential work a single agent can already do — that's over-engineering, a classic exam distractor.

Objective: Apply decomposition techniques for complex problem solving

• Core concept: Break an ambiguous, large task into smaller units with clear inputs/outputs before deciding how to execute each unit (call, workflow-step, or subagent).
• Anthropic-platform specifics:
  • Decomposition techniques mirror the workflow sub-patterns above: sequential decomposition (chaining), parallel decomposition (independent subtasks fanned out), hierarchical decomposition (orchestrator-workers).
  • Tool/skill design follows the same instinct: progressive disclosure — a Skill's short description sits in context by default, full instructions load only when relevant; tool search loads only relevant tool schemas instead of dumping every tool definition into context up front. This is decomposition applied to context, not just task steps.
  • For long-horizon agents, decomposition also shows up as memory/scratchpad design: write intermediate findings to files/memory rather than holding everything in one context window.
• Decision heuristic: If a single prompt is trying to do "understand + plan + execute + verify" all at once and quality is poor, decompose into separate steps/calls with an explicit handoff, not a bigger prompt.

Objective: Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

• Core concept: Every architecture decision should be traceable to one of: efficiency (do the same work with less human time/cost), transformation (enable work that wasn't possible before), productivity (help people do more, faster — e.g., Claude Code for developer workflows, Domain 7 territory), cost (token/infra spend vs. value delivered), performance SLAs (latency/uptime/accuracy commitments the business made to its own customers).
• Anthropic-platform specifics:
  • Model tier choice is a direct value-pillar lever: Opus for correctness-critical/complex reasoning, Sonnet for balanced production workloads, Haiku for high-volume/low-latency/cost-sensitive tasks. Picking Opus everywhere isn't "safer" — it can blow the cost pillar for no accuracy gain on simple tasks, and picking Haiku for a hard reasoning task blows the performance/accuracy pillar.
  • Prompt caching (see Domain 2/Domain 3) is a direct cost + latency lever — the architecture-level decision to structure prompts with stable-prefix-first ordering pays for itself on repeated-context workloads.
  • Batches API (50% cost, non-latency-sensitive) trades performance SLA for cost — correct only when the SLA tolerates async delivery.
• Decision heuristic: When two architectures both "work," the tie-breaker is which one better serves the stated business-value pillar in the scenario — a scenario that says "must respond in under 2 seconds" should never recommend a design that adds an unnecessary agentic loop or a heavier model than needed.

How to think through the question

Domain 1 questions almost always hand you a design and ask whether it is the right shape. The scenario, not the option list, contains the constraint that decides the answer.

Signal words to look for

Reasoning procedure

1. Restate the business problem as input, desired output, who consumes it, and what good looks like as a metric. If the question is asking what to do first and none of that is established, the answer is usually the requirements pass.
2. Decide the tier before the pattern: a single call, a workflow, or an agent. Ask whether the sequence of steps is knowable in advance.
3. Run the four gates, and remember that cost of error is a veto rather than one vote out of four.
4. Find the stated constraint and the business value pillar the scenario cares about most, and use them as a filter over the remaining options.
5. Eliminate options that add autonomy, agents, or model capability the constraint does not pay for. Over-engineering is the most common wrong answer in this domain.
6. Check the surviving option covers all four stages, especially a feedback loop that is tied to a metric rather than to a log file.

Worked example

A team wants a system that, given a rejected insurance claim, pulls the policy document, checks three named eligibility rules, and drafts a decision letter for a human adjuster to review and sign. Volume is about 4,000 claims a day and the interface has a two second response target. A colleague proposes a coordinator agent with a subagent per rule.

Work the signals. "Three named eligibility rules" means the steps are fixed and knowable, so this is a workflow rather than an agentic problem. "Two second response target" is a hard filter that rules out anything adding round trips. "A human adjuster reviews and signs" means the cost of error gate is satisfied, because a mistake is caught before it has effect. "About 4,000 a day" with mostly routine extraction points at right sizing rather than at the top tier.

Now filter. The proposed coordinator adds delegation overhead and latency for work that is neither independent nor open ended, so it fails both the pattern test and the stated latency constraint. Any option that reaches for the most capable model at high effort fails the same constraint and the cost pillar. The answer is a prompt chaining workflow: extract the relevant policy clauses, evaluate the three rules, and generate the letter through a structured output the downstream system can rely on, with the model tier matched to each step and adjuster corrections logged into an eval set so the feedback loop is real.

Exam traps (Domain 1)

• Recommending an agentic pattern when the steps are fully known in advance — workflow is correct, agentic is over-engineering (classic "if in doubt, add more autonomy" distractor).
• Recommending more subagents as the fix for a quality problem that's actually a decomposition/prompt problem — spawning agents is not free, and unnecessary parallelism is a common plausible-but-inferior distractor.
• Treating "use the most capable model" (Opus/Fable-tier) as always correct — ignores the cost/performance business-value pillar; the right answer is often "right-size the model to the task."
• Designing an architecture with no feedback loop (no logging, no eval hook, no memory) and calling it "done" — incomplete end-to-end design.
• Choosing multi-agent coordination for sequential, dependent work (each step needs the prior step's full context) — this is a workflow/chaining problem, not a multi-agent problem; multi-agent shines on independent work.