AI Agent Design Patterns: From Prompt Chains to Multi-Agent

AI agent design patterns are the few shapes production LLM systems actually take: prompt chains with gates, routers, parallel fan-outs, an evaluator grading a generator, and an orchestrator briefing workers. Most tasks need a workflow, not an agent. The pattern you pick decides what you can verify and where a human must sign.

This guide to AI agent design patterns follows Part IV of AI Agents, Engineered, five chapters in the full book: Chapter 10, “Workflows and Composition Patterns”, Chapter 11, “Multi-Agent Systems”, Chapter 12, “Oversight and Autonomy”, Chapter 13, “Writing the Outer Loop” and Chapter 14, “Choosing Your Approach: When Not to Build an Agent”. The distinction everything rests on, who decides the next step, is set up in Chapter 1, “What Is an Agent?”, free to read.

One convention runs through every diagram in Chapter 10, and I find it the fastest way into the whole catalog: “the arrows belong to your code, and the shaded boxes belong to the model.” Everything a workflow promises over an agent, from a legible bill to a failure you can point at, follows from who holds the arrows.

What is the augmented LLM, and why is it the base unit?

The augmented LLM is a single model call with three ports attached: retrieval, tools, and memory. All the AI agent design patterns in this guide arrange copies of that one unit, and what an arrangement adds is structure, never new intelligence. Before you wire boxes together, make sure one box cannot do the job.

The term comes from Anthropic’s essay on the subject, which calls it “the basic building block of agentic systems”: “an LLM enhanced with augmentations such as retrieval, tools, and memory” (Schluntz and Zhang, 2024). Chapter 10 builds it in front of a support desk. A customer asks whether their plan includes a feature; a good answer needs the current plan matrix (retrieval), the customer’s actual plan from billing (a tool), and the two earlier messages in the thread (memory). Remove any port and no prompt rescues the answer.

The practical advice is to be slow to add the first arrow. Classifying a ticket, extracting invoice fields, summarizing a call: each is one augmented call, even at volume. Chapter 10’s rule is short: “Exhaust the box before you reach for the wiring.” On frameworks, the same essay notes that “many patterns can be implemented in a few lines of code.” Three calls and two if statements are a chain; a dictionary lookup is a router.

What are the three workflow shapes?

The three workflow shapes are prompt chaining, routing, and parallelization, and each cures a different overload of a single call. Chaining cures sequence (too many jobs in order), routing cures category (one prompt serving inputs that want different handling), and parallelization cures stakes or scope. In all three, you write the subtask list at design time.

That property is both strength and boundary: because the steps exist before any input arrives, every arrow is testable code and any run can be replayed. The shapes also nest, since each presents the same face to your code: calls in, checked outputs out. The post on agentic workflow patterns works each shape through with its trade-offs.

How does prompt chaining with gates work?

Prompt chaining splits a task into a fixed sequence of model calls, each consuming the previous one’s output, with a gate between steps: a check in ordinary code that stops a bad intermediate before the next step builds on it. Each narrow call is an easier prediction than one call juggling everything.

The gate is the load-bearing part. Ungated, a wrong label at step one is faithfully elaborated by every later step, which is compounding error with more steps; the compounding error calculator shows how fast it bites. Caught at the seam, the same label costs one retry. Chapter 10 compresses this into one line: “A chain without gates is just a slower way to be wrong; the gates are what you are actually building.” Its warning sign for a forced decomposition is equally useful: gates you cannot write mean seams the task never had.

When should you route inputs, and when should you parallelize?

Route when one prompt is being stretched across inputs that want different handling; parallelize when a step carries independent concerns or a verdict too important for one draw. Routing puts a classifier in front of specialized branches, and the router’s error rate becomes a floor under everything downstream, so it deserves its own measurement.

Parallelization comes in two flavors. Sectioning splits a step into independent subtasks run at once, such as one call screening a ticket for abuse while another drafts the reply. Voting runs the same task several times and aggregates, such as several review prompts checking code for a vulnerability and flagging it if any one objects. Voting’s threshold is a dial you set per task, and five votes cost five times the tokens. Sectioning has fine print: if parallel subtasks secretly share a decision, each settles it its own way and the pieces refuse to compose.

When does an evaluator–optimizer loop earn its cost?

An evaluator–optimizer loop earns its cost when you can write down what good means and feedback measurably improves the next attempt. One call generates, a separate evaluator returns specific feedback, and the generator revises until the evaluator passes the candidate or a cap stops the loop.

The source essay gives two signs of fit: that responses “can be demonstrably improved when a human articulates their feedback,” and “that the LLM can provide such feedback” (Schluntz and Zhang, 2024). Who sits in the evaluator’s seat decides everything. A test suite or compiler returns a located fault; an LLM-as-a-judge critic returns an estimate, and Chapter 10 is blunt that “A weak critic is worse than none.”

Expect front-loaded gains: the book advises planning “for two or three productive rounds,” with a hard iteration cap, a no-progress exit, and the best candidate kept rather than the last. The failure shapes are the rubber stamp (everything passes on round one), oscillation, over-editing, and the wrong hill. Under all of them sits one caution: “the loop optimizes exactly what the evaluator measures, and nothing else.” Of practitioner recipes that run five self-reviews in a row, the chapter’s verdict is “Five reviews and then the test suite is a discipline. Five reviews instead of the test suite is a séance.” The evaluator–optimizer pattern deep dive covers convergence in detail.

Which AI agent design patterns fit which problem?

Pick the pattern by the overload you observe, and price its characteristic failure before you adopt it. The table is the field guide in compressed form; the design patterns cheat sheet expands each row.

Pattern	Use it when	Characteristic failure	Rough cost vs one call	Chapter
Augmented LLM	One call with the right ports can answer	Missing or bloated port (stale data, wrong plan)	1×	Ch. 10
Prompt chain + gates	Fixed, ordered subtasks with checkable seams	Ungated error elaborated downstream	≈ steps ×	Ch. 10
Routing	Distinct input categories pull one prompt apart	Misroute: the right specialist for the wrong ticket	1× plus router	Ch. 10
Sectioning	Independent concerns in one step	Hidden shared decision; pieces don’t compose	≈ sections ×, little added latency	Ch. 10
Voting	A high-stakes verdict comparable by equality	Keeping “the best” without a scorer	≈ votes ×	Ch. 10
Evaluator–optimizer	Clear criteria, feedback that improves the next draft	Rubber stamp, oscillation, wrong hill	≈ rounds × 2	Ch. 10
Orchestrator–worker	Subtask list depends on the input	Vague briefs, conflicting assumptions, merge wall	Roughly 15× chat tokens in one team’s data	Ch. 11
Agent in an outer loop	Unattended work with a machine-checkable “done”	Confidently wrong at scale; verification debt	Per pass × passes	Ch. 13

Single agent or multi-agent?

Start with one agent, then ask whether the work decomposes into branches that can run without seeing each other: no shared mutable state, no dependence on each other’s choices, no ordering that matters. If yes, an orchestrator with workers is on the table. If no, keep one continuous context.

The two camps in this argument are both on the record. Cognition’s essay argues that “running multiple agents in collaboration only results in fragile systems” because “decision-making ends up being too dispersed and context isn’t able to be shared thoroughly enough between the agents” (Yan, 2025). Anthropic reports a production research system where parallel workers “cut research time by up to 90% for complex queries” (Anthropic, 2025).

Chapter 11 reconciles them through the workload. Research is read-heavy and its findings compose by juxtaposition; coding mutates one shared artifact and composes by merge. Multi-agent, in the chapter’s phrase, “is an architecture with a habitat.” The bill is real either way: the same Anthropic team found that “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” As Chapter 11 puts it, parallelism “never buys efficiency.” The full comparison, with a decision table, is in single agent vs multi agent.

What does orchestrator–worker add over a parallel fan-out?

The orchestrator–worker pattern adds runtime decomposition: a model reads the input, decides which subtasks exist and how many, briefs a worker for each, and synthesizes the results. A parallel workflow fans out to a list you fixed in advance; the orchestrator writes the list itself.

The rule of thumb in Chapter 11: “if you can write the subtask list before seeing the input, use the workflow.” Profiling every vendor in a market is the canonical case, because you cannot list the vendors until someone surveys the market. Each subagent works at a clean desk, which postpones context rot on every desk at once and keeps the dead ends sealed inside its own window.

Synthesis is where the final quality is won or lost, so resource it with your most capable model even when workers run on cheaper ones. Model tiering is also how the token count can multiply while the bill does not have to; the agent cost-per-task estimator lets you price the split. The post on the orchestrator–worker pattern is the build guide.

What goes in a worker’s brief?

A worker’s brief needs four things: an objective, an output format, guidance on tools and sources, and boundaries stating what belongs to a sibling. The worker knows nothing you did not write down, so Chapter 11 calls delegation quality “the variable that most separates multi-agent systems that work from those that embarrass you.”

The evidence is a failure from the Anthropic team: a lead agent issuing one-line instructions such as “research the semiconductor shortage” found that subagents “misinterpreted the task or performed the exact same searches as other agents.” The book’s test is to write each brief as a ticket for a contractor who has never seen the project and cannot ask questions. Its one-line summary: “The worker is exactly as good as the memo that summons it.”

Why do parallel coding agents hit a merge wall?

The merge wall is the point where parallel workers, branched from one baseline, try to integrate their changes and find the baseline has moved under them. Steve Yegge named it; Chapter 11 treats it as the single-writer rule collecting with interest. The field’s structural answer: keep writes single-threaded.

Coordination failures are measured, not imagined. A 2025 study built a taxonomy from 150 expert-annotated traces, identifying “14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification,” then applied it to a separate dataset of more than 1,600 traces across seven frameworks; it notes that multi-agent gains on popular benchmarks “are often minimal” (Cemri et al., 2025). What survives the wall is a serialized merge queue, deferring overlapping work, and pausing parallelism during sweeping changes. Chapter 11’s summary: “Adding agents adds hands and coverage; it does not add judgment.” The coordination failure modes and how to build a multi-agent system posts go further, and single agent vs multi agent covers the merge wall in full.

Where do humans belong in the loop?

Humans belong at three instruments: gates in front of consequential actions, review of intent and outcomes rather than every line, and a dial that sets each task’s autonomy. Chapter 12 frames all three with a signing limit, the company policy that says who may sign for what, calibrated to consequence and revised as trust accumulates.

The metaphor has one honest gap: an analyst carries earned trust in memory, while an agent starts every run new. Its trust lives on your side, in permission files, eval scores and run histories.

How do you place approval gates by consequence tier?

Place an approval gate by what an action costs when wrong, never by the agent’s claimed confidence. Classify every action into four tiers (read-only, reversible, externally visible, irreversible): run the first two freely with logs, queue the third for review, and require a signature for the fourth.

Confidence is excluded because the self-report is miscalibrated in the dangerous direction and a sycophantic model reports what you want to hear. Placement matters as much: the gate sits in the seam between the model proposing an action and code executing it, and Chapter 12 states the rule in bold: “the gate must live in your code, never in the agent’s judgment.” Otherwise a prompt injection can talk the agent out of asking. Package each escalation as a decision, with the action, the reason, what it touches and whether it can be undone: “Send a decision, not a transcript.” And spend signatures sparingly, because “Over-gating does more than annoy. It defeats the gate.” The consequence-tier guide to approval gates applies this to real tool lists.

What is review theater, and what replaces it?

Review theater is, in Chapter 12’s words, “diligence performed at a volume where it can no longer be real”: approving a four-hundred-line agent change after reading a quarter of it. The replacement is to “review intent and outcomes, not lines,” using artifacts a human can check in minutes.

Demand four things: success criteria stated before the run, a declared scope (so anything touched outside it is a flag), a walkthrough in the agent’s own words, and evidence of outcome such as test output or a reproduction. Cheaper still is reviewing the plan before any code exists, when a misunderstanding is still a sentence you can edit. The chapter’s distinction between understanding to verify and understanding to participate explains why: tooling keeps eating the first, while the second is what lets you steer the next loop. In the chapter’s words, “a signature you do not understand is a rubber stamp, whatever tier it guards.” The post on human-in-the-loop review works through the artifacts.

What is the autonomy dial?

The autonomy dial is how much an agent may do between moments of your attention, set per task rather than per system. Four positions cover practice: every consequential action waits for a signature; standing permissions for pre-approved action types; plan-level approval; and monitored autonomy against budgets, with a kill switch within reach.

Tasks move outward on evidence: clean runs, sensible escalations, measured error rates on the task class. They move back just as deliberately. Because a model upgrade can change competence overnight in different directions on different tasks, Chapter 12 adds a rule teams forget: “Re-earn the dial settings after every upgrade.” Steering only works if stopping is cheap, which is an engineering requirement, not a temperament: “interruption is only cheap if resuming is.” The same person on the same day should run settings from both ends, tight on core work and loose on background chores. The autonomy slider post walks the four positions.

How do you write the outer loop?

You write the outer loop by turning your mental backlog into a system that wakes on a trigger, assigns work to an agent in a fresh context, checks the result against an oracle, records what happened on disk, and decides whether to go again. The inner loop is the agent; the outer loop chooses its tasks.

Strip any outer loop and Chapter 13 finds the same five verbs: find, assign, check, record, decide. Three lessons sit under them: state lives on disk because the model forgets, windows stay fresh because a short context cannot rot, and verification is a gate because a loop that cannot reject bad work converges on nothing.

Two debts accrue when work happens while nobody watches. Verification debt is the gap between a green checkmark and your having confirmed the work; cognitive debt is the gap between merged changes and your understanding of the system. The brakes are code: per-pass and per-loop budgets, stuck-detection, least privilege (audit each loop for the lethal trifecta, with the lethal trifecta audit), human gates at the blast doors, and a tested kill switch. Chapter 13 ends on its refrain: “Build the loop. Stay the engineer.” The agent as a state machine post covers the mechanics.

What makes a good goal function?

A goal function pairs a goal held outside the model with a stopping condition a machine can evaluate after each pass. Chapter 13’s test: “A goal you can loop toward is a goal whose satisfaction a machine can check.” “Make the app better” fails it; “all tests under auth/ pass and lint is clean” passes.

The check needs an oracle, a source of truth outside the thing being judged, and “A loop is exactly as trustworthy as its oracle.” The model that did the work is a poor oracle for it: “the model’s ‘done’ is testimony; a green test is evidence.” So separate the checker from the maker, and pair every goal with a hard iteration cap for the case where “done” never comes true. If “done” is not machine-verifiable, wire in a human or a judge and accept the weaker guarantee.

When should you not build an agent at all?

Don’t build an agent when you can draw the flowchart before the request arrives, when correctness must be guaranteed or audited, when a person is waiting or margins are thin, when the task is a lookup, classification or conversion, or when stakes are high and verification is costly. Stay on the lowest rung that works.

Chapter 14 prices the ladder of Chapter 1 (plain code, a single call, a workflow, an agent) with a four-line quote per rung: what it costs to build, to run, to be wrong, and to know whether it worked. Running costs stay flat for a single call, add up for a workflow, and multiply for an agent. Failures move from words to deeds. The fourth line is the one teams drop, and at the top of the ladder “the proof is a second construction you build alongside the first.”

The ladder runs both ways: once an agent’s traces stabilize, freeze the stable stretch into workflow steps. The trap that corrupts the decision is agent-washing, and the cure is one question: “Does the model decide the next step, or does code?” The should this be an agent? tool walks the signs, agents vs workflows states the rule, and when not to use AI agents is the checklist. Chapter 14’s closing image: “The sticker price of an agent is a prompt. The cost of ownership is a harness, a ledger, and a standing claim on your attention.”

Worked example: one support desk, five patterns

Here is how the patterns compose on one invented system. A software company wants to “automate support,” which Chapter 14 would call a department wearing the grammar of a task. Decomposed honestly, it becomes a workflow shell with one agentic step.

A router sorts each ticket into refund, technical, or general, and its accuracy is measured on its own labeled set. In parallel, a sectioned guard call screens for abuse while the branch drafts. The refund branch is a chain: look up the order, check the policy, draft the reply, with gates that confirm the cited policy exists and the amount is under the branch’s limit. General questions are a single augmented call.

Only the technical branch gets an agent, because nobody can list in advance which logs a diagnosis needs. Its goal function is a reproduction that passes after the proposed fix, checked by a fresh read-only verifier rather than the agent itself.

Then the tiers. Order lookups and drafts run freely. Sending a reply is externally visible, so replies queue for review at first. Refunds are irreversible and always wait for a signature. After a few hundred boring general replies with no corrections, that action type earns a standing permission; refunds never do. No orchestrator appears anywhere, because no subtask list here depends on the input.

Where does each idea live in the book and on this site?

Each concept has one chapter where the book defends it and one page here that works it through.

Concept	Chapter	Go deeper	Glossary
Augmented LLM, chain, route, parallelize	Chapter 10	Agentic workflow patterns	routing
Evaluator–optimizer loop	Chapter 10	The evaluator–optimizer pattern	evaluator–optimizer
Orchestrator–worker, worker briefs	Chapter 11	Orchestrator–worker pattern	orchestrator–worker
Single vs multi, merge wall	Chapter 11	Single agent vs multi agent	subagent
Consequence tiers, approval gates	Chapter 12	Approval gates by consequence	approval gate
Review theater, autonomy dial	Chapter 12	The autonomy slider	review theater
Outer loop, goal function	Chapter 13	The agent as a state machine	goal function
Ladder revisited, agent-washing	Chapter 14	Should this be an agent?	agent-washing

What are the limits of these patterns?

These AI agent design patterns organize model calls; they make no call smarter, and every cost multiple here will move as models and pricing change. Read the multiples (about 15× the tokens of a chat, research time cut “by up to 90%”) for direction: one team’s workload, one point in time. Measure your own.

The patterns also share one blind spot: each is only as good as the check inside it. A gate certifies form, not substance. An evaluator–optimizer optimizes the rubric, gaps included. An outer loop trusts its oracle. Human review of a high-volume agent degrades into theater unless you change what you review. And multi-agent advice in particular is contested territory, where serious practitioners disagree in public; the workload framing reconciles the published positions, but it is a reading of the evidence, not a settled law.

The one question to keep

Keep the question that sorts all the AI agent design patterns in this guide: what signal tells you this step worked? Gate, test suite, verifier, signature, goal function: each puts that signal where the risk is. The chapters of Part IV are how you choose the pattern whose signal you can actually afford.