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 the data passes through: input, context assembly, processing, output, delivery and feedback.
A van hire firm uses Claude to answer customer emails about bookings, deposits and damage charges.
The Canonical Pipeline
-
Input. Ingestion, validation and normalisation of incoming data. PII handling is decided here, before anything reaches a model, not retrofitted afterwards. Once data has reached the model, it is too late to decide. The van hire firm settles what happens to a customer's licence number at this stage, before the email goes to Claude.
-
Context assembly. Retrieval, memory and prompt construction: everything that decides what the model sees. For the firm, that is the customer's booking record, earlier emails and the reply instructions. The strategies live in Domains 2 and 3; at this level you place the stage correctly and know what belongs in it.
-
Processing. The model call or calls: a single augmented call, a workflow of calls, or an agent loop. The firm's reply could come from one call that reads the email and the booking record. Pattern choice belongs to objective 1.3.
-
Output. Validation and handling of what the model returns: structured-output parsing, schema checks, guardrail screening, and a designed failure path 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. Schema validity is not business validity, so business-rule checks sit here too. A reply can match the schema and still quote a deposit the firm does not charge.
-
Delivery. How results reach users or systems: synchronous response, asynchronous job, event, or draft for human review. Delivery choice is a risk decision as much as a UX one. Draft for review is the standard mitigation when output errors carry consequences, because a person sees the error before the customer does. The firm can send every reply about a damage charge to staff as a draft.
-
Feedback loops. User feedback capture, automated evaluation on sampled traffic, and monitoring signals, all routed somewhere they can drive prompt, retrieval and design iteration. 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 firm, staff corrections to drafts and a graded sample of sent replies would feed the next prompt change.
Key Concept
The two stages most often missing from real designs, and from exam stems, are output validation and the feedback loop.
Design for Failure
Model calls and their dependencies fail, and a production architecture assumes it.
- Timeouts, retries with backoff, and idempotency around every model call. A retry runs the call again, so any side effect it triggers can run twice. A retried call that double-executes a side effect is a self-inflicted incident, such as a van hire customer charged the deposit twice.
- A designed degraded path for every failure mode: queue 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 look. If the firm'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 determines how much output validation and human review the architecture needs. A wrong internal draft costs an edit. A wrong customer-facing settlement figure costs real money and trust. The model is the same in both cases, and the architecture differs. At the firm, a wrong damage charge sent to a customer needs more checks than a wrong internal note.
In the exam
The favourite stem describes an architecture with a stage missing and asks what breaks. Walk the six stages and mark what exists. The professional-level answer names the missing stage and fixes it at root cause, not by adding 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 does, because those stages make quality measurable. For the van hire firm, that means 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 on top.
Shipping with no mechanism to capture quality signals or route them into iteration
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. This is the most commonly missing stage in exam stems.
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: 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 on paper.
You should see: A simple diagram from user input to delivered output, with every hop the data takes.
- Label each element of your diagram with one of the six stages: input, context assembly, processing, output, delivery, feedback
Why: The stage labels turn a diagram into an audit. 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 schema validity is not business validity. 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. A designed degraded path is the difference between an incident and a queue entry.
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 — the stage that separates production systems from demos.
You should see: One paragraph naming the signal (user rating, correction, sampled eval), the store, and the review cadence that acts on it.
Sources
- Structured outputs — Anthropic
- Define success criteria and build evaluations — Anthropic
- Building Effective AI Agents — Anthropic