TLDR
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. Anthropic: building-effective-agents
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
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.
Side-by-side
| 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 |
Question patterns

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?
"the prompt is the hardest part, so get it right first and backfill the rest" - that is exactly the trap the objective tests against.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?
"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.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 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.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?
"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.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?
"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.Frequently asked
Is "processing" just the system prompt?
Does an evaluator-optimizer pass count as the whole feedback loop on its own?
Work this with your AI
Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.
- Drill it like the exam (scenario MCQs)Practice in the exam's scenario-MCQ format with trap awareness.
- Explain it back (Feynman)Build durable, transferable understanding of a concept you can half-state.
- Test me, adapting the difficultyActive recall practice on a concept you think you know.
- Check my prerequisites firstBefore studying a concept that keeps not sticking.
- Find the high-leverage 20%When a domain feels too big and you are short on time.
