# 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. **Domain:** CCARP-D1 · Solution Design & Architecture (17% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/end-to-end-architecture-design **Last reviewed:** 2026-05-04 ## Quick stats - **Pipeline stages:** 4 - **Exam domain:** CCARP-D1 (17%) - **Atomic building block:** Augmented LLM - **Feedback mechanisms (non-exhaustive):** 3+ - **Aggregation pattern:** Orchestrator-workers ## 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 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. ## Where you'll see it in production ### 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. ## Comparison | 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 | ## Exam-pattern questions ### Q1. An architect designs a strong system prompt and agent loop for a contract-review system but leaves "how contracts arrive" and "what happens to reviewer edits" as implementation details for later. What is the risk? A system with a well-tuned prompt but no defined input path or feedback loop degrades silently in production - all four stages (input, processing, output, feedback) need to be designed together, not just the processing middle. Named distractor: "the prompt is the hardest part, so get it right first and backfill the rest" - that is exactly the trap the objective tests against. ### Q2. Multiple parallel subagents extract clauses from a contract. The architect ships each subagent's raw output directly to the legal-review UI without further processing. What stage was skipped? The output and aggregation stage - an orchestrator-workers pattern should synthesize the parallel results into one coherent output before delivery. Named distractor: "parallel outputs are fine to deliver as-is since each subagent already verified its own work" - synthesis into a single output is a distinct design step, not automatic. ### Q3. A team builds an evaluator-optimizer loop that checks extracted clauses against source text before delivery, but never routes human legal-reviewer edits back into the extraction prompt's few-shot examples. What is missing from their feedback loop? The human-layer feedback channel - 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, not a bolt-on. Named distractor: "the evaluator-optimizer loop is sufficient since it already checks quality before delivery" - evaluator-optimizer is one valid feedback mechanism, not the whole feedback stage; it is model-to-model and does not capture what human reviewers actually correct over time, so a design needs both, not evaluator-optimizer alone. ### Q4. An architect treats their v1 end-to-end design as the final architecture and declines to revise it after three months of production usage data. What does Anthropic's guidance say about this? Production AI rollout is inherently iterative - the initial architecture is a hypothesis to be revised from real usage feedback, not a final design. Named distractor: "a well-designed v1 should not need revision if the stated requirements did not change" - the guidance expects revision based on observed usage, independent of whether stated requirements changed. ### Q5. A contract-review system's input stage only handles on-demand single-PDF uploads. Six months later a client wants nightly batch uploads of 500 contracts, and the processing pipeline breaks. What was under-designed at the start? The input stage - it should have been designed for the range of arrival shapes (user turn, webhook, batch file, tool result) relevant to the use case, not just the first-observed pattern. Named distractor: "this is a scaling problem, not an architecture problem" - the objective explicitly treats input ingestion as one of the four stages to design up front, not an implementation detail to patch later. ## FAQ ### Q1. Is "processing" just the system prompt? No. Processing is however many augmented-LLM calls are composed together, a single call, a workflow, or an agent loop, built on the augmented LLM as the atomic unit. ### Q2. Does an evaluator-optimizer pass count as the whole feedback loop on its own? It is one valid mechanism at the model layer, but architect-level design should also account for the human-review layer, where a person checks output and how those corrections get folded back into prompts or examples. --- **Source:** https://claudearchitectcertification.com/concepts/end-to-end-architecture-design **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.