What You Need to Know
Every production Claude system has the same six stages, whether or not anyone drew them. A stage is one job that the data passes through. The six stages are input, context assembly, processing, output, delivery and feedback.
This lesson uses one made-up example throughout: a supermarket chain that uses Claude to answer customer emails about online orders, delivery charges and refunds.
The Canonical Pipeline
-
Input. This stage ingests, validates and normalises incoming data. To normalise data is to convert it to one standard format. Decide the handling of PII (personally identifiable information) here, before anything reaches a model. Do not retrofit it afterwards. Once data reaches the model, it is too late to decide. The supermarket chain settles what happens to a customer's home address at this stage, before the email goes to Claude.
-
Context assembly. This stage is retrieval, memory and prompt construction: everything that decides what the model sees. For the chain, the model sees the customer's order record, earlier emails and the reply instructions. Domains 2 and 3 cover the strategies. At this level, you place the stage correctly and know what belongs in it.
-
Processing. This stage is the model call or calls: a single augmented call (one model call with retrieval, tools and memory added), a workflow of calls, or an agent loop. The chain's reply could come from one call that reads the email and the order record. Objective 1.3 covers the choice of pattern.
-
Output. This stage validates and handles what the model returns. It includes structured-output parsing, schema checks, guardrail screening (checks that block content the system must not send), and a designed failure path for when validation fails. Model output is untrusted input to downstream systems until validated. Structured outputs constrain responses to a schema, so a completed response gives downstream code valid, parseable data. Output that matches the schema can still break business rules, so business-rule checks also belong in this stage. A reply can match the schema and still quote a delivery charge the chain does not have.
-
Delivery. This stage is how results reach users or systems: a synchronous response, an asynchronous job, an event, or a draft for human review. The choice of delivery is a risk decision as much as a UX decision. Draft for review is the standard way to reduce risk when output errors have consequences, because a person sees the error before the customer does. The chain can send every reply about a refund to staff as a draft.
-
Feedback loops. This stage captures user feedback, runs automated evaluation on sampled traffic (a sample of real requests), and collects monitoring signals. It routes all of them to a place where they can guide repeated changes to the prompt, the retrieval and the design. This stage separates production systems from demos. An architecture with no evaluation path cannot improve and cannot prove its value, because nothing records which outputs were wrong. At the chain, staff corrections to drafts and a graded sample of sent replies would provide input for the next prompt change.
Key Concept
The two stages most often missing from real designs, and from exam questions, are output validation and the feedback loop.
Design for Failure
Model calls and their dependencies fail, and a production architecture assumes that they fail.
- Timeouts, retries with backoff, and idempotency apply to every model call. Backoff means a longer wait before each new retry. Idempotency means that a call that runs twice has the same effect as one run. A retry runs the call again, so any side effect it triggers can run twice. A retried call that runs a side effect twice is an incident that the system causes itself. For example, the system refunds a supermarket customer twice for one order.
- A designed degraded path for every failure mode: queue the work for a human, serve a cached answer, or return an explicit error. Failure is never silent. An empty response that looks like success is the worst outcome available, because nothing tells anyone to check it. If the chain's model call times out, the email goes to the staff queue.
- Blast radius analysis. Ask what happens downstream when the model is wrong. The answer is the blast radius, and it determines how much output validation and human review the architecture needs. A wrong internal draft costs an edit. A wrong customer-facing refund amount costs real money and trust. The model is the same in both cases, and the architecture differs. At the chain, a wrong refund amount sent to a customer needs more checks than a wrong internal note.
In the exam
The most common question describes an architecture with a stage missing and asks what breaks. Check the six stages in order and mark what exists. The professional-level answer names the missing stage and fixes the root cause. It does not add capability elsewhere. When quality is inconsistent and nobody can say why, the diagnosis is a missing feedback loop, not a weak model. A bigger model, more retrieval or a longer prompt does not fix unmeasurable quality. Adding validation and feedback capture fixes it, because those stages make quality measurable. For the supermarket chain, those stages hold rule checks and logged staff corrections.
Exam Traps
Piping model responses straight into downstream systems without schema validation or guardrail checks
Model output is untrusted until validated. A malformed or wrong response corrupts downstream state. Validation plus a designed failure path stops bad output propagating, and schema validity still needs business-rule checks as well.
Shipping with no mechanism to capture quality signals or route them into the next round of changes
Without a feedback loop, quality complaints arrive with no data on which outputs were wrong or why. The system cannot improve and its value cannot be proven. Capture staff corrections and a graded sample of outputs, and route both into prompt changes.
Catching model or dependency errors and returning empty or default output without signalling
Silent failure hands users wrong or missing results with no indication anything failed. Every failure mode needs an explicit degraded path (a defined response for when that failure happens): queue for a human, serve a cached answer, or return a clear error.
Fixing an unmeasurable-quality problem by upgrading the model
Without evaluation and feedback capture, nobody can measure whether the upgrade changed anything. The root cause is the missing loop, not model capability. Fix the stage that is absent, not the one that is easiest to swap.
Practice Scenario
A team ships a contract-review assistant: lawyers upload a contract, Claude analyses it, and a risk report is emailed back. Lawyers complain that quality is inconsistent, and the team cannot say which reports were wrong or why. Which change addresses the root cause?
Build Exercise
Six-Stage Architecture Audit
What you'll learn
- How to decompose any Claude system into the six pipeline stages
- How to spot the missing stage in a described architecture
- How to design a failure path for the model call
- How to design a feedback loop that makes quality measurable
- Take an existing or planned Claude solution and draw its data flow end to end, as boxes and arrows
Why: You cannot audit stages you have not drawn. Most missing-stage problems are invisible until the flow is drawn.
You should see: A simple diagram from user input to delivered output, with every step the data passes through.
- Label each element of your diagram with one of the six stages: input, context assembly, processing, output, delivery, feedback
Why: With the stage labels, you can use the diagram to audit the system. Unlabelled elements usually mean a stage is doing two jobs or a job is being done nowhere.
You should see: Every box labelled; at least one stage with no box at all is the common finding.
- For the output stage, write down what is validated today and what a failure does — then add schema validation and a business-rule check if either is missing
Why: Model output is untrusted until validated, and output that matches the schema can still break business rules. Both checks belong in the output stage.
You should see: A two-line spec: what the schema check enforces, and what the business-rule check enforces on top.
- Define the failure path for the model call: timeout, retry policy, and the degraded-but-safe behaviour when retries are exhausted
Why: Production architectures assume failure. With a designed degraded path, a failure becomes a queue entry instead of an incident.
You should see: Three lines: timeout value, retry count with backoff, and the explicit fallback (queue for human, cached answer, or clear error).
- Design the feedback loop: what quality signal is captured, where it is stored, and how it reaches the next design iteration
Why: The feedback loop is what makes quality measurable and improvable — production systems have this stage, and demos do not.
You should see: One paragraph naming the signal (user rating, correction, sampled eval), the store, and the review schedule that acts on it.
Sources
- Structured outputs — Anthropic
- Define success criteria and build evaluations — Anthropic
- Building Effective AI Agents — Anthropic