Three Shapes and a Loop You'll Forget to Draw

The previous chapter settled that the problem is worth solving and Claude is genuinely part of the answer. The next decision is structural: what shape does the system take? There are only a few fundamental shapes, and most production systems combine them. Know the three and their cost and reliability profiles. That’s what lets you pick the simplest structure that will actually hold — and defend it when someone asks why you didn’t build something fancier.

The three fundamental patterns

Every Claude system is built from three primitives. The axis that separates them is how much control you hand to the model.

The augmented LLM is a single model call, enriched. On its own a model only maps a prompt to text. Augment it two ways. Retrieval fetches relevant documents and puts them in the prompt. Tools let it call a function and use the result. With either, one call can ground its answer in your data or act on the world. There’s no loop and no multi-step orchestration: request in, one enriched call, answer out. This is the atom the other two patterns are built from.

The workflow is multiple steps whose order your code fixes. The model does discrete pieces of work: classify this, then summarize that, then draft a reply. But the control flow lives in your program, not in the model’s head. You decide which step runs, in what order, and when it ends. This is the “predetermined path” pattern. The workflow-versus-agent chapter works it in runnable code.

The agent hands control to the model. It’s a loop. The model looks at the state and decides the next action: call a tool, ask a question, finish. Your code executes that decision and feeds the result back. It repeats until the model says it’s done. Nobody wrote the sequence in advance. This is the agentic loop from Foundations, and its defining property is that the model controls the path.

The progression is one of increasing model autonomy. The augmented LLM hands over no control: one call. The workflow keeps control with you while the model does the pieces. The agent takes control of the flow. More autonomy buys more flexibility and costs you more predictability. That single tradeoff drives the whole choice.

Reading their profiles

You choose among the three by their profiles, not their sophistication. Line them up:

• Augmented LLM — most reliable, cheapest, lowest latency. One call means one place to fail, a predictable bill, and a single round-trip. Its ceiling is that it can’t do genuinely multi-step work. If the task needs several dependent stages, one call either does them badly or not at all.
• Workflow — still highly predictable, because you wrote the path. Cost and latency are the sum of its fixed steps, known in advance. It handles multi-step tasks a single call can’t. Its limit is rigidity: it can only handle the paths you foresaw and coded. Hand it an input the sequence didn’t anticipate and it has no way to adapt.
• Agent — most flexible, least predictable, most expensive. It adapts to inputs you never imagined. That’s exactly why you can’t bound its cost or latency in advance: the number of loop iterations depends on what the model decides at runtime. Each turn re-sends the growing context, so token cost climbs, and more autonomy means more ways to go wrong. You accept that unpredictability only when the task genuinely demands runtime adaptation.

The discipline is the same one from Foundations: start with the simplest pattern that works, and add autonomy only when a real limit forces you to. Try a single augmented call first. If the task is genuinely multi-step but its path is known, make it a workflow. Reach for an agent only when the path can’t be known ahead of time — when the model must decide, at runtime, what to do next. Reaching for an agent because it sounds advanced is the classic over-engineering trap. In design reviews it shows up as unbounded cost and flaky behavior on a task a workflow would have handled deterministically.

One diagnostic question cuts through it: can you draw the flowchart in advance? If you can enumerate the steps and their order before any request arrives, you have a workflow. Coding that flowchart is safer than asking a model to rediscover it every run. If you genuinely cannot, because the right next step depends on what the model finds along the way, an agent is warranted. Most tasks people reach for agents on turn out to be drawable, which is why the honest default sits lower on the autonomy scale than instinct suggests.

The end-to-end shape, including the part you’ll forget

Patterns describe the processing core. A production system is bigger than its core, and it has four parts, not three:

1. Input — where requests enter and get shaped: the user’s message, plus what you attach to it (retrieved context, prior conversation, system prompt, guardrails on what’s allowed in).
2. Processing — one of the three patterns above, or a composition of them, doing the actual work.
3. Output — where the result leaves: formatting, validation, output guardrails, and the action or reply the user or a downstream system receives.
4. Feedback loops — how the system’s own behavior flows back to improve it.

Newcomers draw the first three and stop. The fourth is what separates a demo from a system that survives contact with production. A feedback loop is any path by which the system’s outputs inform its future behavior. Log every request and response so you can debug and audit. Capture outcomes — did the user re-ask, escalate, or leave satisfied? — to feed evaluation. Route low-confidence cases to a human whose correction becomes tomorrow’s eval example or few-shot sample. Monitor quality, cost, and latency so drift is caught before customers report it. A system without feedback loops can’t be evaluated, can’t be improved, and can’t be trusted, because you’d have no evidence it’s still working. The whole later arc on evaluation builds on this. The feedback loop is not an add-on; it’s a first-class part of the architecture. The exam treats an architecture that omits it as incomplete.

Composing them: the bookshop platform’s shape

Real systems mix the patterns; the skill is putting each shape where it fits. Decide the support platform piece by piece.

Answering a knowledge question — “what’s your return window on opened items?” — is an augmented LLM. Retrieve the relevant policy chunks, put them in one call, get a grounded answer. No loop, no multi-step orchestration; it’s the cheapest, most reliable shape and it fits the most common request. Don’t make this an agent.

Resolving a refund request is not one call. It has real steps with a known order: identify the order with the lookup_order tool, check eligibility with the rules engine from chapter 1, then either process the refund with the process_refund tool (behind a human gate) or explain the denial. That fixed sequence is a workflow. You want it predictable and auditable, its path is known, so there’s no reason to hand control to the model. Coding the steps buys you determinism on the part of the system that touches money.

The customer-facing coordinator fields whatever the user says: a question, an order status check, a refund, a follow-up that changes the subject. Its path can’t be fixed in advance, because the customer decides where the conversation goes. That’s the one place an agent earns its unpredictability: the model reads each message and decides whether to answer from knowledge, call a tool, or hand off. It delegates the refund workflow and the knowledge lookup rather than reimplementing them.

So the platform is a composition. An agentic coordinator sits on top, delegating to an augmented-LLM knowledge path and a workflow refund path. All of it is wrapped in the four-part shape: input shaping and guardrails on the way in, validation and guardrails on the way out, and feedback loops threaded through — logging, outcome capture, eval, human review. Each part uses the simplest pattern its job allows. That is the whole discipline: not one grand pattern, but the right small shape in each place, and the feedback loop drawn in from the start.

What the exam is really checking

Domain 1 pattern items give you a scenario and ask for the right architecture, and the trap answers over-build. They offer a multi-agent system where an augmented call would do, or an agent where the path is fixed and a workflow is safer and cheaper. The credited answer is almost always the simplest pattern that meets the requirement, matched to the reliability, cost, and latency the scenario demands. And when an item lists an architecture’s components, the one that’s missing is often the feedback loop — the tell that it’s the wrong answer. Know the three profiles cold, remember the fourth box (feedback) is part of the picture, and these items resolve quickly.

Next: multi-agent decomposition at scale — when a system warrants several agents, how to orchestrate them, and the cost of cutting too finely.