CCARP-D1.2 · Solution Design & Architecture17% of CCA-P7 min read

End-to-End Architecture Design (Input to Feedback Loop).

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.

Loading your plan…
Mental modelThe 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.
End-to-End Architecture Design (Input to Feedback Loop), hero illustration featuring Loop mascot in a warm gallery scene.
Share
On this page
01 · Summary

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.

4
Pipeline stages
CCARP-D1 (17%)
Exam domain
Augmented LLM
Atomic building block
3+
Feedback mechanisms (non-exhaustive)
Orchestrator-workers
Aggregation pattern
02 · The decision

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.

Learner decision

Which stage of the pipeline owns each failure, and what contract lets that stage be checked?

03 · Definition

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.

04 · By certification

How each certification frames it

CCA-P: How CCA-P tests end-to-end design

  • CCARP-D1-O2 Design 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.

05 · Mechanics

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.

End-to-End Architecture Design (Input to Feedback Loop) mechanics, painterly diagram featuring Loop mascot.
06 · Worked example

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.

01
Input contract. Each ticket arrives as ticket text plus an account id. A validation step rejects empty tickets and strips attachments the pipeline cannot read, so processing never sees malformed input.
02
Processing. Three steps in code: classify the ticket, fetch the matching policy passage, draft a reply from only that passage. The path is fixed in code, which Anthropic describes as a workflow: LLMs and tools orchestrated through predefined code paths.
03
Output contract. The draft is returned as a structured object: category, reply text, the policy passage id it relied on, and a flag for low confidence. A schema check rejects any output missing the passage id.
04
Feedback loop. Every reviewer decision (accepted, edited, rejected, with a reason code) is stored against the ticket and sent to a named owner each week. Rejections with the reason 'wrong policy' go to the retrieval owner, 'wrong tone' to the prompt owner.
StageContractOwnerFailure signal
InputValidated ticket text and account idIntake service ownerRejected or empty tickets
ProcessingClassify, retrieve policy, draftRetrieval and prompt ownersWrong policy passage, wrong tone
OutputSchema with passage id and confidence flagApplication ownerSchema check failures
FeedbackReviewer decision with reason codeNamed weekly reviewerReasons 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.

07 · Failure modes

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.

08 · In production

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.

09 · Compare

Side-by-side

↔ scroll to compare
StageWhat it coversAnthropic-named pattern that fills itCommon mistake
InputHow data enters: user turn, webhook, batch file, tool resultShape depends on the integration, no single named patternAssuming input is always a live chat turn
ProcessingAugmented LLM call, workflow, or agent loopWorkflow patterns (chaining, routing, parallelization) or orchestrator-workersTreating this as the only box worth designing
OutputStructured, streamed, or human-gated delivery; aggregation of parallel resultsOrchestrator-workers synthesizes worker outputs into one resultShipping raw model text with no delivery contract
Feedback loopModel-level critique loop plus a human-correction channelOne of several options: evaluator-optimizer (generator plus evaluator LLM loop), human-correction logging, or eval-suite/production-monitoring regression checksTreating evaluator-optimizer as the only mechanism, or feedback as a bolt-on afterthought instead of part of the initial design
10 · Exam trap

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.

End-to-End Architecture Design (Input to Feedback Loop) exam trap, painterly cautionary scene featuring Loop mascot.
11 · On the exam

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.

Question 1 of 6 · D1Choose the best answer

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?

Practice this topic with CCA-P questions

12 · FAQ

Frequently asked

Showing 4 of 4 questions

13 · Sources

Sources and next steps

CCA-P exam guide: Domain 1, Solution Design & Architecture

Help someone pass

Share this concept.

One share is one less person stuck on the same question.

Last reviewed: ·Refresh cadence: monthly