Design end-to-end architectures (input → processing → output → feedback loops)

What You Need to Know

End-to-end Claude architectures name four stages: input, processing, output, and feedback. Intake validates and authenticates; processing retrieves, reasons, and calls tools; output delivers to a user or system; feedback captures outcomes, failures, and human review so the system improves. Diagrams that stop when the model responds are incomplete.

Failures, retries, and escalations must re-enter the loop. Monitoring and human-in-the-loop (HITL) are first-class stages when risk requires them — not slideware. Feedback is only real when it feeds evals, prompts, retrieval, or ops. A thank-you email is not a feedback architecture.

The four stages

Input — channel, auth, validation, and scoping of the request
Processing — retrieval, Claude reasoning, tools, and intermediate checks
Output — delivery to UI, ticket, API, or downstream system
Feedback — corrections, failures, HITL outcomes, and metrics that change the system

Decision rules

Name every stage: input, processing, output, and feedback.
Plan how failures, retries, and escalations re-enter the loop.
Treat monitoring and HITL as first-class stages when risk requires them.
Feedback must feed evals, prompts, retrieval, or ops — not only a UI thank-you.
Incomplete diagrams that stop at "model responds" usually fail exam items.

Why feedback must change the system

Without a path from corrections and failures into evals and configuration, quality plateaus and risk accumulates silently. Architects design the backlog: who labels gold answers, what triggers a prompt or index change, and how monitoring signals join the same queue. Exam stems that show intake → Claude → UI without a corrections path key on the missing feedback loop.

Review checklist

Are all four stages present and owned?
Do failure and retry paths re-enter processing or HITL?
Is HITL on the runtime path when risk requires it?
Do thumbs-down / corrections become eval cases?
Does monitoring feed the same improvement backlog?

Prefer answers that add a real feedback path over answers that only enlarge the model or add courtesy messaging. Happy-path-only diagrams are a common distractor.

Exam application

Intake + Claude + UI without corrections → missing feedback loop. Prefer designs where failures re-enter and feedback updates evals/prompts/retrieval. Distractors: larger model, thank-you-as-feedback, HITL only in slides.

Exam traps

Treating feedback as a thank-you email only
Feedback must feed evals, prompts, retrieval, or ops. Courtesy messages do not close the improvement loop.
HITL only in slides
Human review belongs on the diagram with entry/exit criteria when risk requires it — not as a bullet that never reaches the runtime path.
Ignoring failure and retry paths
Timeouts, tool errors, and escalations must re-enter processing or HITL. Happy-path-only diagrams fail exam items.
Diagrams that stop at "model responds"
Output without a feedback stage is incomplete architecture. Incomplete intake→output paths are the usual trap.

Practice scenario

A design review shows a policy Q&A diagram with user intake, Claude processing, and an answer UI. There is no path for corrections, failures, or outcome signals back into the system. What is the primary architectural gap?

Option AMissing feedback loop — corrections, failures, and outcomes must re-enter evals, prompts, retrieval, or ops, not stop at the model response UI.Option BMissing a second, larger model so answers are automatically more accurate.Option CMissing a thank-you email after every answer, which fully satisfies the feedback stage.Option DMissing a slide that mentions HITL once; diagrams never need operational review paths.

Build exercise

Sketch an e2e architecture for a policy Q&A assistant with feedback into evals

40 minutes

What you'll learn

Name input, processing, output, and feedback on one diagram
Route failures, retries, and escalations back into the loop
Place HITL and monitoring as first-class stages when risk requires them
Wire corrections into evals, prompts, and retrieval with owners

Step 1
Name all four stages on the diagram
Draw input (intake/auth/validate), processing (retrieve, reason, tools), output (deliver to user/system), and feedback (signals that change the system). Label owners for each stage.
Why: Exam items expect every stage named. Stopping at Claude's reply is an incomplete architecture.
You should see: A four-box diagram with arrows and a named owner per stage.
Step 2
Route failures, retries, and escalations back in
For timeouts, empty retrieval, policy refusal, and user dispute, show where the path re-enters processing or HITL. Do not leave dead ends.
Why: Failures are part of the architecture. Architects plan re-entry, not only the happy path.
You should see: Annotated failure arrows with retry limits and escalation criteria.
Step 3
Make HITL and monitoring first-class when risk requires them
If answers affect compliance or money, put human review on the path with clear gates. Add monitoring for latency, refusal rate, and correction rate — not only uptime.
Why: Monitoring and HITL are stages, not afterthoughts. Slide-only HITL fails professional review and exam stems.
You should see: HITL gate criteria and a monitoring list tied to the feedback loop.
Step 4
Wire feedback into evals, prompts, and retrieval
Define how corrections become eval cases, how patterns trigger prompt or retrieval changes, and who owns the backlog. Close the loop with a weekly improvement ritual.
Why: Feedback that does not change the system is decoration. The exam keys on feedback that feeds improvement.
You should see: A feedback → eval/prompt/index change contract with an owner and cadence.

Sources

Build with Claude — docs.anthropic.com
Tool use overview — docs.anthropic.com — processing-stage tool paths
Reduce hallucinations — docs.anthropic.com — quality loops and grounding