On this page
TLDR
An architect-level design task is never just "the prompt in the middle" - it is the full pipeline: how input arrives, how it is processed (augmented LLM, workflow, or agent loop), how output is delivered, and how the system learns from what happened. The augmented LLM, an LLM enhanced with retrieval, tools, and memory, is the atomic building block every end-to-end design composes from. The feedback stage itself has multiple valid mechanisms - evaluator-optimizer, human-correction logging, production monitoring - not one canonical answer.
What you are deciding
An end-to-end Claude architecture defines four contracts: what goes in, what processing does, what comes out, and who receives feedback when an output fails. The model call is one box in the middle, not the design.
Which stage of the pipeline owns each failure, and what contract lets that stage be checked?
What it is
An architect-level design task is never just "the prompt in the middle" - it is the full pipeline: how input arrives (a user turn, a webhook, a batch file, a tool result), how it is processed (a single augmented LLM call, a workflow, or an agent loop), how output is delivered (structured, streamed, or gated by a human), and, critically, how the system learns from what happened (evaluator feedback, logged corrections, retrained prompts or examples).
Anthropic's building-effective-agents framework is explicit that the augmented LLM is the basic building block every end-to-end design composes from, and that workflows and agents are compositions of that block with defined control flow around it, not replacements for thinking through the full loop.
How each certification frames it
CCA-P: How CCA-P tests end-to-end design
CCARP-D1-O2Design end-to-end architectures (input -> processing -> output -> feedback loops)
The Professional guide lists the objective as designing end-to-end architectures with input, processing, output and feedback loops (PDF page 4, Domain 1). Expect scenario questions where several answers improve the model step and exactly one fixes the stage that owns the failure.
Read each option for the stage it changes. An option that rewrites the prompt changes processing. An option that adds a schema check changes the output contract. An option that routes rejected outputs to a named reviewer changes the feedback loop.
How it works
The augmented LLM is the atomic unit. Retrieval, tools, and memory augment a single LLM call; both the workflow and agent patterns are built by composing multiple augmented-LLM calls with control flow layered on top, not by inventing something more exotic underneath.
The feedback stage has more than one valid mechanism - evaluator-optimizer is one option, not the canonical answer. Evaluator-optimizer (one LLM call generates a response while a second LLM call evaluates it and feeds back critique in an iterative loop, until a quality bar is met) is Anthropic's best-known named pattern for closing a feedback loop programmatically, and it fits well when there are clear evaluation criteria an evaluator can check against. But it is not the only mechanism an end-to-end design can use for feedback: a human-correction channel (a person reviews output and their edits get folded back into prompts or examples), structured production monitoring (logged stop_reasons, error rates, or eval-suite regressions that trigger a design revisit), and automated eval-suite regression checks on every prompt change are all equally valid feedback mechanisms - which one (or combination) fits depends on whether the quality bar is something a second LLM call can check, something only a human can judge, or something that only shows up in aggregate production behavior.
Orchestrator-workers handles output aggregation in more complex designs. A central LLM dynamically breaks a task down, delegates to worker LLMs, and synthesizes their results back into one output - this is the named pattern for the output stage whenever multiple parallel results need to become one coherent deliverable.
Human-layer feedback is architectural, not a bolt-on, and often the mechanism that matters most. Designing where a human reviews output, and how that review feeds back into prompt or example revision, is part of the end-to-end shape - a contract-review system whose evaluator-optimizer pass checks extraction quality but never routes a human legal reviewer's edits back into the few-shot examples has only closed part of its feedback loop, regardless of how well-tuned the evaluator-optimizer pass itself is.
The whole design is a hypothesis, not a final artifact. Anthropic's enterprise implementation guidance frames production rollout as inherently iterative - the initial architecture, all four stages included, is expected to be revised from real usage feedback, not shipped once and left alone.

Worked example: a support-reply pipeline with four contracts
Authored teaching example, not a bank question.
A team wants Claude to draft replies to support tickets. The first version is one large prompt that takes a ticket and returns a reply. Reviewers keep rejecting replies but nobody knows which stage to fix.
| Stage | Contract | Owner | Failure signal |
|---|---|---|---|
| Input | Validated ticket text and account id | Intake service owner | Rejected or empty tickets |
| Processing | Classify, retrieve policy, draft | Retrieval and prompt owners | Wrong policy passage, wrong tone |
| Output | Schema with passage id and confidence flag | Application owner | Schema check failures |
| Feedback | Reviewer decision with reason code | Named weekly reviewer | Reasons that map to no stage |
When a reply is rejected, the reason code names the stage. The team fixes retrieval or the prompt instead of rewriting everything, and the stored decisions become the evaluation set for the next change. Check afterwards that every output field has an owner and every rejection reason maps to exactly one stage.
How this decision goes wrong
Prompt-only design
Looks right: One carefully tuned prompt handles the whole task, so the system looks simple.
Why it fails: With no input or output contract, a bad reply could come from bad input, wrong retrieval, the prompt or the format. Nothing can be checked in isolation.
Instead: Split the path into stages with explicit contracts, and keep the path in code when the steps are fixed and well defined.
Feedback without an owner
Looks right: Reviewers can reject replies, so the loop exists.
Why it fails: Rejections pile up in a log that nobody reads, or they cannot be traced to a stage, so the same failure repeats.
Instead: Give each rejection reason a stage and each stage a named owner, and review the stored decisions on a fixed rhythm.
Where you'll see it
Contract-review pipeline
Input is uploaded PDFs (batch or on-demand); processing is an augmented LLM with clause-library retrieval plus structured extraction; output is risk-flagged JSON to a legal-review UI; feedback is an evaluator-optimizer pass plus a logged-correction channel from human reviewers.
Iterative production rollout
A shipped v1 architecture is treated as a hypothesis; usage data drives revision of the processing and feedback stages rather than treating the initial design as final.
Side-by-side
| Stage | What it covers | Anthropic-named pattern that fills it | Common mistake |
|---|---|---|---|
| Input | How data enters: user turn, webhook, batch file, tool result | Shape depends on the integration, no single named pattern | Assuming input is always a live chat turn |
| Processing | Augmented LLM call, workflow, or agent loop | Workflow patterns (chaining, routing, parallelization) or orchestrator-workers | Treating this as the only box worth designing |
| Output | Structured, streamed, or human-gated delivery; aggregation of parallel results | Orchestrator-workers synthesizes worker outputs into one result | Shipping raw model text with no delivery contract |
| Feedback loop | Model-level critique loop plus a human-correction channel | One of several options: evaluator-optimizer (generator plus evaluator LLM loop), human-correction logging, or eval-suite/production-monitoring regression checks | Treating evaluator-optimizer as the only mechanism, or feedback as a bolt-on afterthought instead of part of the initial design |
The exam trap
The trap is designing only the "processing" middle box (the prompt or agent) and treating input ingestion and the feedback loop as implementation details to solve later. The objective explicitly tests whether a candidate designs all four stages together, since a system with a well-tuned prompt but no feedback loop degrades silently in production.

Question patterns
CCA-P practice questions
6 approved CCA-P questions for this topic. Tap an answer to check it, then read the rationale for every option.
You're designing a contract-review system: intake (PDF upload) -> Claude extracts clauses -> a downstream compliance check -> a human approves or rejects the flagged clauses. Six months in, the legal team reports the model keeps making the same clause-classification mistakes even after they correct them weekly in a shared spreadsheet. What is missing from the end-to-end design?
Frequently asked
Showing 4 of 4 questions
Sources and next steps
- Claude Certified Architect - Professional Exam Guide v1.0 (July 2026), PDF page 4, section: Domain 1: Solution Design & Architecture, detailed objectives. Checked 2026-10-16.
- Building effective agents (Anthropic engineering), section: Workflows vs. agents; when to use agents. Checked 2026-10-16.
