Claude Certification Guide CCAR-P

Curriculum › Solution Design & Architecture · 17% of the exam

End-to-end architecture and pattern selection

What you’ll be able to do

  • Design an end-to-end architecture covering input handling, processing, output delivery and feedback loops
  • Place validation, guardrails and human review at the stage boundaries where they are cheapest and most effective
  • Distinguish augmented LLM, workflow and agentic patterns by who controls the execution path
  • Select the simplest pattern that meets the requirement and justify moving up in complexity
  • Design feedback loops that turn production outcomes into evaluation data and improvements

What you need to know

The model call is one box out of four

A production Claude system is a pipeline, and most incidents happen outside the model call. Design each stage deliberately:

  • Input: where requests and documents come from, how they are authenticated, validated, normalized (file formats, encodings, OCR), deduplicated and screened. This is where you minimize sensitive data, apply PII redaction if the use case needs it, and reject inputs the system is not designed to handle.
  • Processing: context assembly (system prompt, retrieved documents, conversation state), the model call or calls, and any tools. Decide what is static and cacheable, what is retrieved per request, and what the model is allowed to do.
  • Output: structured output and schema validation, business-rule checks in code, confidence or uncertainty signals, routing to a human reviewer when required, and delivery into the system of record. An output that parses is not necessarily an output that is allowed.
  • Feedback: logs and traces, user ratings and corrections, reviewer decisions, downstream outcomes (was the refund reversed? did the customer reopen the ticket?). These flow into an evaluation set and a change process for prompts, retrieval and tools.
input processing output feedback feedback becomes eval cases and changes to prompts, retrieval and tools

Put controls at the boundaries

Each stage boundary is a natural control point. Rejecting an unsupported file at input is cheaper than debugging a hallucinated extraction later. Hard rules (a refund limit, a required approval, a forbidden field) are enforced in code at the output boundary or around tool execution, not only described in the prompt, because prompts shape behavior probabilistically while code enforces it. Human review sits where error cost is concentrated, typically between output and delivery, and it is part of the architecture, with its own queue, latency and capacity.

Three patterns, distinguished by who controls the path

Anthropic's guidance on building effective agents distinguishes building blocks by how much control the model has over the execution path:

  • Augmented LLM: a single model call enhanced with retrieval, tools and memory. The application decides when to call; the model may use tools within that call. Many real needs (answer a policy question from a knowledge base, extract fields from a document) stop here.
  • Workflow: several model calls orchestrated through predefined code paths. Common shapes are prompt chaining (fixed sequence of steps), routing (classify, then send to a specialized path), parallelization (split into independent parts, or run several attempts and vote), orchestrator-workers (a model plans subtasks that code dispatches) and evaluator-optimizer (one call generates, another critiques, repeat). The developer owns the control flow, which makes cost, latency and behavior predictable and testable.
  • Agent: the model directs its own process, choosing tools and next steps in a loop until it judges the goal met. Use it when the number and order of steps cannot be known in advance, such as open-ended investigation or multi-system troubleshooting.

Select the simplest pattern that works

Each step up the ladder buys flexibility and costs predictability. Agents use more tokens, have more variable latency, are harder to evaluate because two runs may take different paths, and need more governance: tool permissions, budgets, stop conditions, audit trails. Workflows are easier to test and to fit to an SLA, but break when the task genuinely needs to adapt.

A practical selection test:

  • Can one well-grounded call meet the acceptance bar? Use an augmented LLM.
  • Can you write down the steps in advance, and are they the same each time? Use a workflow; pick the shape from the structure of the task.
  • Do the steps depend on what earlier steps discover, and is the extra cost and variance acceptable for the value? Use an agent, bounded by tool scope and a budget.

Patterns compose. A routing workflow can send most traffic down cheap fixed paths and only escalate genuinely novel cases to an agent; an agent can call a fixed extraction chain as one of its tools. Justify each increase in complexity with a measured gap, not with the capability of the pattern.

Feedback loops close the system

A system without a feedback loop degrades silently: documents change, user behavior shifts, edge cases accumulate. Capture structured signals (reviewer overrides with a reason code, corrections, escalations, downstream reversals), sample them into a versioned evaluation set, and run that set before every prompt, model or retrieval change. Feedback that lands only in a dashboard does not improve anything.

Key concept

Architect the whole path, input to feedback, enforce hard rules in code at stage boundaries, and choose the least autonomous pattern (augmented LLM, workflow, agent) that meets the requirement.

Questions here often describe an over-built agent for a predictable task, a rigid chain failing on open-ended work, or a defect whose root cause sits in input handling, output validation or a missing feedback loop rather than in the model.

Practice scenario

ScenarioAn insurer built an agent with a dozen tools to classify incoming broker emails into one of seven request types and file them in the correct queue. It works, but latency varies widely, per-email cost is several times the estimate, and the compliance team cannot explain why two similar emails took different tool paths. Misclassifications are corrected by queue owners, but those corrections are not recorded anywhere.
Work it through, then open this

The task has a fixed shape: read one email, assign one of seven labels, file it. That is a routing workflow or even a single augmented call with structured output, not an agent. Replacing the agent with a classification call (enum-constrained output) plus code that files the email makes latency and cost predictable and gives compliance one auditable path. Add input handling for attachments and non-English emails, and a low-confidence route to a human queue.

The second gap is the missing feedback loop. Capture each queue owner’s reclassification as a labeled example with the original email, and use those cases as the regression set before changing the prompt or the model.

Build exercise — Architecture review of an existing system

Advanced · 45 min

What you’ll learn

  • Auditing a design stage by stage rather than model-first
  • Matching the pattern to the structure of the task
  • Designing a feedback loop that reaches an evaluation set

  1. Draw a current or planned Claude system as input, processing, output and feedback boxes, and list the controls at each boundary.

    • Why: Gaps are easiest to see when each stage has to be filled in explicitly.
    • You should see: At least one boundary with no validation or no owner, often output-to-delivery or the feedback stage.

  2. Classify the processing stage as augmented LLM, workflow (name the shape) or agent, then argue for the next simpler pattern and see whether it would meet the acceptance bar.

    • Why: Complexity should be justified by a gap that the simpler pattern leaves.
    • You should see: Either a concrete case the simpler pattern fails, or a simplification you can propose.

  3. Define three feedback signals, where each is captured, and how it becomes an evaluation case.

    • Why: Feedback only improves the system if it is structured and fed into a regression set.
    • You should see: Signals with an owner, a schema and a path into an eval run, not just a dashboard.

Exam traps

Designing only the model call and treating input handling and output delivery as someone else’s problem

Many failures originate in ingestion or delivery. The architecture includes all four stages.

Choosing an agent because it is the most capable pattern, not because the path is unpredictable

Agents trade predictability, cost and testability for flexibility. Use one only when the steps cannot be fixed in advance.

Forcing an open-ended task into a rigid workflow that cannot adapt to what it discovers

Predefined steps either miss what investigation reveals or do unnecessary work. Open-ended tasks need adaptive control.

Collecting user feedback that never reaches an evaluation set or a change process

Dashboards alone change nothing. Structure the signals and turn them into regression cases.

Sending model output straight to downstream systems without schema or business-rule validation

Parsed output can still violate business rules. Validate in code before delivery.

Relying on the system prompt alone to enforce a hard business constraint

Prompts influence behavior; code enforces it. Put hard limits at the output or tool-execution boundary.

Sources

Quick check

Purchase orders take nine days end to end. Analysis shows about seven of those days are spent waiting for three managers to approve in sequence; filling in the request form takes around twenty minutes. The sponsor wants a Claude assistant that drafts purchase requests. What should the architect advise?