What you need to know
An end-to-end architecture covers four stages: input (what arrives and in what shape), processing (what Claude, your code and other systems do with it), output (what leaves the system, and in what form), and the feedback loop (how production results change the system over time). Exam scenarios often describe a design that handles the middle two well and forgets the first or the last.
Reference architectures are starting shapes
A handful of shapes cover most enterprise workloads. Treat them as patterns to adapt and combine, not blueprints to copy.
| Shape | Fits | Built well | Typical failure |
|---|---|---|---|
| Agent | Open-ended investigation where the steps cannot be listed in advance | Narrow tool set, turn and token budgets, a clear stopping rule | Unlimited autonomy and state-changing tools with no review |
| Retrieval (RAG) | Answering from a stable body of knowledge: manuals, policies, regulations | Documents chunked and indexed; relevant chunks passed in as context | Used for data that changes, such as order status or stock levels |
| Document pipeline | Pulling structured fields from claims, invoices or contracts | OCR, extraction against a schema, validation, an exception route | Low-confidence results flow on as if they were correct |
| Routing | Mixed incoming requests that need different handling | Classify, then send each kind to retrieval, a transactional API or a person | No path to a human; retrieval used for live data |
| Coding agent | Changing an unfamiliar codebase | Agentic exploration, then fixed steps to plan, edit, test and review | Edits merged without a human review gate |
Real systems mix these. A support assistant is often a router whose branches are a RAG lookup, an order-status API call and a human queue.
Retrieval is for knowledge, tools are for live state
The most common architectural mistake in this domain is answering a live-state question from an index. An index is a snapshot. If a customer asks where their order is, retrieval returns text about the order as it was when the index was last refreshed, and the answer sounds just as confident when it is wrong. No better embedding model or faster refresh cycle fixes this. The fix is to call the system that owns the data.
A demo is not a production system
A proof of concept hides four problems that production exposes:
- Cost. Fifty requests a day cost almost nothing. The production bill must be modeled at real volume before the design is approved.
- Latency. A single request in a demo says little about the 95th-percentile latency under concurrent load.
- Reliability. A demo has no retries or fallbacks; the developer simply runs it again. Production needs them from the start.
- Unexpected inputs. Demos are tested on inputs the builder expected. Production brings the ones nobody expected.
Three reliability controls belong around every model call: retries with exponential backoff for transient errors such as rate limits and timeouts, a fallback (another model tier, a cached answer or a graceful message) when the primary path is unavailable, and a circuit breaker that stops calling a failing dependency so one outage does not cascade. They are far harder to add after launch than to design in.
Close the loop
The output stage is not the end. A complete architecture says how results are captured and acted on:
- Signals. Logs, user ratings, escalations, corrections made by reviewers, eval scores.
- Triage. Sort each signal: a defect, a gap in scope, a data problem or noise.
- Decide. Agree who owns the fix and how urgent it is.
- Act. Change the prompt, the data, the routing or the scope.
- Review. Check the change worked, and add the failing case to the evaluation set so it cannot quietly return.
In the exam
Look for which stage the scenario is really about. If the symptom is wrong or stale facts, check the data access pattern. If the symptom is outages or cost overruns after launch, look for missing reliability controls or a cost model built from demo traffic. If the system "works" but nobody can show it is improving, the missing piece is the feedback loop. The best answer usually fixes the stage that failed rather than adding complexity elsewhere.
Check your understanding
A support assistant answers "Where is my order?" from an index of order records refreshed every six hours. Customers get answers that contradict the tracking page. What is the best fix?
Show answer
Answer: D. Order status is live state. Any index is a snapshot, however often it is refreshed, so the fix is a tool call to the system that owns the data. Retrieval stays the right mechanism for stable FAQ content.
A proof of concept ran well at 40 requests a day. Before launching at 30,000 a day, what should be added first?
Show answer
Answer: C. A demo has no reliability controls because a person simply runs it again. At production volume, transient errors are certain, so retries, a fallback and a circuit breaker must exist before launch.
An invoice system extracts fields, validates them and posts them to the ERP, but never records the corrections reviewers make. What is missing?
Show answer
Answer: B. Reviewer corrections are the system's best evidence of where it fails. Without a feedback loop they are lost, so the same errors return and nobody can show the system is improving.
Apply it: Design the claims intake end to end
Larkfield has accepted the "feasible with constraints" verdict. Sketch the end-to-end architecture for claims intake as a table, then add the reliability controls and the feedback loop that a demo would leave out.
- Inputs. List each channel and what has to happen before Claude sees the content.
Done when: all three channels from the case arrive in one consistent form. - Processing and outputs. List the stages in order. For each, name the owner (Claude, a system or a person) and what it produces.
Why: naming the owner of every stage exposes steps that were silently given to the model.
Done when: the final outputs are a created claim in ClaimsCore and a sent acknowledgement. - Reliability. Name three controls around the model calls, and what happens to a claim while Claude's API is unavailable.
- Feedback loop. Describe how corrections made by handlers flow back into the system.
Done when: a correction made today could stop the same error next month.
Show model answer
Inputs
| Channel | Before Claude |
|---|---|
| Strip signatures and threads; save attachments to the document store | |
| Web form | Structured fields kept as they are; photos stored |
| Scanned post | OCR, with page images kept for reviewers |
All three become one "claim package": text, structured fields if any, links to attachments, channel, and received time.
Processing and outputs
| Stage | Owner | Produces |
|---|---|---|
| Extract the 31 fields | Claude (structured output against the schema) | Fields with a confidence per field |
| Validate key fields, check policy status | Policy Admin API plus rule checks | Pass, mismatch or missing |
| Fraud score | Fraud rules engine | Score and flags |
| Route | Code: rules on confidence, validation and size | Straight-through, or handler queue with the reason |
| Handler review (when routed) | Intake handler | Corrected fields |
| Create the claim | ClaimsCore API | Claim record |
| Draft and send the acknowledgement | Claude drafts from a template; code sends | Acknowledgement, plus any missing-document request |
Reliability
- Retries with exponential backoff on rate limits, timeouts and server errors, with a cap on total wait.
- A fallback: if the model is unavailable, packages wait in a durable queue and, past a set age, go to handlers so the one-day SLA still holds.
- A circuit breaker on the extraction service so a failing dependency stops being called and the queue drains to people instead.
Feedback loop
Every handler correction is stored against the field and the package. Weekly, the team triages corrections (prompt issue, schema gap, OCR quality, genuinely ambiguous input), changes the prompt or routing, and adds the corrected packages to the evaluation set so a regression shows up before release.