Agentic Design Patterns: Pick the Smallest One That Works

Last month I burned through a credit pool in four days. The task was dull, reconcile two CSV exports and flag mismatches, and I had reached for an orchestrator with three subagents because that was the shiny pattern I wanted to practice. A single augmented LLM call with one tool would have done it in a tenth of the tokens. That mistake is the whole reason this guide exists, and it is the reason I am going to argue something unfashionable: the value of agentic design patterns is not in the patterns. It is in the rule that tells you to use fewer of them.

Agentic design patterns are named control structures for arranging LLM calls and tools. Anthropic's *Building Effective Agents* and the Claude Agent SDK give us a clean vocabulary for them, and everything here is model-agnostic, the shapes work whether you run Claude, an open-weight model, or something else behind your harness. What I want you to leave with is not a catalog to memorize. It is a decision procedure: match a task to the *minimum* structure that solves it, and treat every layer above that minimum as a cost you have to justify. There is a real production gap behind this, by one 2026 collection, 79% of organizations have adopted AI agents while only about 11% have them running in production workflows. In my experience the teams stuck on the wrong side of that line are not under-engineering. They are over-engineering, then drowning in the bill.

The split that decides everything: workflow or agent

Anthropic divides agentic systems into two categories, and the choice between them governs every downstream tradeoff. A workflow orchestrates LLMs and tools through predefined code paths, *your code* holds control. An agent lets the model dynamically direct its own process and tool usage, maintaining control over how it accomplishes the task, *the model* holds control. Workflows win when you can pre-map the decision tree and you want accuracy, control, and lower cost. Agents win when the task is open-ended and you genuinely cannot predict how many steps it will take.

Both categories are built from one unit Anthropic calls the augmented LLM: a model enhanced with retrieval, tools, and memory, generating its own queries, selecting tools, and deciding what to keep. Here is the part people skip. If a single augmented LLM call solves your task, you are done. No pattern. The escalation rule is the entire game: find "the simplest solution possible, and only increasing complexity when needed," which "might mean not building agentic systems at all." Agentic systems trade latency and cost for task performance, so you escalate only when a specific failure mode forces it, not when a tutorial makes orchestration look fun.

I will be blunt about the contrarian read, because the source supports it and the field resists it. Most content on this topic is a tour of clever multi-agent architectures. The source's own emphasis runs the other direction: it spends its strongest language telling you *not* to build the complex thing. That asymmetry is deliberate, and I have come to trust it. The expensive failures I have shipped were never "I used too simple a pattern." They were always "I used a flexible agent where a deterministic workflow would have been cheaper and more reliable."

The agent loop, and why verification is the only beat that matters

For genuinely open-ended tasks, every agent runs the same four-beat loop: gather context, take action, verify the work, repeat. Gather means reading files or running agentic search, `grep`, `find`, `tail` to pull the relevant slice instead of the whole file, or delegating to subagents with isolated context windows. Take action means executing through tools: shell commands, code generation, file edits, MCP servers. Verify means checking the result against ground truth from the environment, test output, tool results, a render, before declaring done. Repeat means a failed verification loops back to the action step with the specific error in hand.

Strip out verification and you do not have an agent. You have a script that guesses, and worse, one that compounds its guesses. The model takes an action, never checks it against reality, takes another action premised on the unverified first, and the errors stack. The verify beat is the single feature that separates a reliable production agent from an experimental chatbot wearing a loop. When I review someone's "agent" that misbehaves in production, nine times out of ten the gather-act-repeat scaffolding is fine and the verify step is either missing or fake, a second LLM call rubber-stamping the first.

The Claude Agent SDK makes the discipline concrete. You constrain the toolset to what the task needs (read, edit, a shell, search), and you make "verify" a deterministic rule the model cannot wriggle out of. A working setup for a red test looks like this in plain terms: allow the agent the file and shell tools, and write a system prompt that says fix the failing test, run `pytest -q` after every edit, stop only when it passes, and never edit or delete the test to force a pass. The loop then runs itself, gather the failing context, act with an edit, let `pytest` be the verifier, repeat until green. The point is the shape, not the SDK: a deterministic pass-or-fail rule wired into the loop is what makes the thing trustworthy.

Three ways to verify, cheapest first

Not all verification is equal, and the ordering matters more than the menu. Prefer the cheapest signal that can actually catch your failure mode.

The trap is reaching for LLM-as-judge first because it feels general-purpose. It is the most expensive and least reliable option, and it should be the last thing you try, reserved for genuinely fuzzy criteria where no rule and no render apply. For structured-data work, an LLM judge adds cost without adding accuracy. The payoff from deterministic checks is concrete: structured planning and verification scaffolding has been shown to lift multistep tool-calling accuracy from 41% to 96% in enterprise settings. That jump comes from rules, not from a second model's opinion.

There is a quieter failure mode worth naming here, because it eats agents from the inside: silent tool failures. A function returns `null`, the agent does not notice, and it proceeds as if the call succeeded, compounding the error through every subsequent step. Build explicit error handling and structured error messages into every tool definition. An agent that cannot tell success from silence is not verifying anything, no matter how many judge calls you bolt on.

The four workflow patterns, and the line that separates them from agents

When one augmented LLM call is not enough but the path is still predictable, you reach for a workflow pattern. There are four worth knowing.

Prompt chaining runs a fixed sequence where each LLM call processes the previous output, with optional programmatic gates between steps. Use it when a task decomposes cleanly into fixed subtasks, outline a document, gate-check that the outline meets the brief, then write it. Routing puts a classifier (an LLM or a classical one) in front, sorting input into distinct categories that are better handled separately, then dispatching to a specialized handler. A support desk splitting general, refund, and tech requests is the canonical case, and routing lets you send easy inputs to a cheap model and hard ones to a frontier model. Parallelization, sectioning breaks a task into independent subtasks run at once for speed, like one model answering while another screens the output for policy. Parallelization, voting runs the same task several times for diverse outputs and votes with a threshold, several prompts reviewing code for vulnerabilities, flagging if any of them trips.

Now the distinction that confuses everyone: parallelization versus orchestrator, workers. Both fan work across multiple LLM calls. The difference is *who draws the subtasks*. Parallelization runs pre-defined subtasks, you decided the branches in code before the model ran. Orchestrator, workers is model-driven: a central LLM "dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results," and "the subtasks aren't pre-defined, but determined by the orchestrator based on the specific input." Anthropic's own example is a coding agent making complex changes across multiple files each time. The rule writes itself. If the subtasks are fixed, hardcode them and parallelize. If they vary per input, let the orchestrator decide. Reaching for an orchestrator when your subtasks are actually fixed is the single most common over-build I see.

What the multi-agent payoff actually costs

The case for orchestrator, workers rests on one striking number, and you have to read it with the cost attached. In Anthropic's research system, a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on their internal research eval. That is real, and it is the headline everyone quotes. The sentence that follows is the one that should govern your architecture: "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens" than a chat. Multi-agent only pays off for valuable, parallelizable, breadth-first work that genuinely exceeds a single context window.

The lead prompt's own scaling rule is the most practical sizing guide I have found, and I now apply it before spinning up any subagent. Simple fact-finding gets one agent with three to ten tool calls. Direct comparisons get two to four subagents with ten to fifteen calls each. Only complex research that needs broad, parallel investigation gets more than ten subagents. If your task does not clearly sit in the top tier, the 15× multiplier is not buying you 90.2%, it is buying you a bigger bill. My reconciliation job from the opening did not need ten subagents. It needed one call and the discipline to stop.

A related cost hides in the protocol layer. Wiring in MCP servers gives you reach, but shared tool definitions and schemas consume the context window fast, and every server is a separate process adding latency to each interaction. None of that is an argument against MCP. It is an argument for counting the tokens before you add a layer, because the context you spend on plumbing is context you cannot spend on the task.

Evaluator, optimizer, plan-and-execute, and ReAct: when the model gets to think

Three more shapes cover the cases where iteration or planning earns its keep.

Evaluator, optimizer (the literature also calls it reflection, same shape, different name) has one LLM call generate a response while another evaluates it and feeds back, in a loop. It is "particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value." Two signals tell you it fits: a human articulating feedback demonstrably improves the output, and the model can produce that same critique itself. With fuzzy criteria you get an expensive loop that polishes nothing, so put deterministic verification in front of it. And cap the loop. An evaluator that never signals success will drain a credit pool while you are at lunch, I cap retries and escalate to a human review on the third miss rather than letting the loop run free.

Plan-and-execute versus ReAct is the question of when the model thinks. Plan-and-execute generates a full multi-step plan up front; executors, often smaller, cheaper models, carry out each step; a replanning step decides whether to finish or write a follow-up plan. Three wins: speed, because intermediate steps skip the big model; cost, because the large model is called only for re-planning; and quality, because the planner has to think through all the steps explicitly. The footgun is specific and painful, with no replanning trigger, a wrong initial plan executes faithfully to a wrong answer. ReAct goes the other way: the model plans one sub-problem at a time in a think → act → observe loop, one tool call per turn, adapting to each observation. It wins on simple, dynamic tasks solvable in a few tool calls where each step depends on the last. It also costs more per step and can drift or loop if you do not bound it. Static plans give you speed; adaptive loops give you durability against a changing environment. Pick the failure you can afford.

For long-horizon work, Anthropic's harness operationalizes this as a planner / generator / evaluator structure with durable artifacts that survive a context reset. An initializer writes an `init.sh` script, a progress file, and an initial commit; a coding agent makes incremental progress against a feature list of 200-plus granular, testable features marked passing or failing; and it verifies the way an engineer would, marking a feature done only when it actually works. One rule is absolute, and I treat it as load-bearing: never let an agent delete or edit its own tests, because "this could lead to missing or buggy functionality." The test suite is immutable ground truth. An agent allowed to rewrite its own grader will always pass and never work.

A decision table you can read top to bottom

Here is the procedure I actually use. Read it from the top and stop at the first row that fits your task. That stopping discipline is the point, every row you skip past is latency and cost you are choosing to take on.

Patterns compose, and that is where it gets interesting in production. A real coding agent might route a request, hand the hard ones to an orchestrator, and have each worker run its own gather → act → verify loop with rules-based checks. Layer only as far as the task demands, and no further.

The framework tax, and the bill that taught me to count

Frameworks "make it easy to get started," and they also "create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug." I learned this the expensive way. When an agent built on a heavy framework misfires, the framework often swallows the very trace you need, the raw prompt, the exact tool call, the moment it entered the loop. You are left debugging a black box that is spending money. My standing advice, which the source states plainly: start with raw API calls, understand the shape of the pattern, and add a framework only once you know what it is hiding from you.

This stopped being academic on June 15, 2026, when Anthropic split Agent SDK, headless `claude -p`, and GitHub Actions usage into a separate monthly credit pool billed at standard API rates. For workloads that previously leaned on near-unlimited subscription usage, the effective price increase landed somewhere between 12x and 175x. Whatever the exact multiplier for your usage, the lesson is the same one this whole guide is built on: a flexible agent that loops without a verifier and reports nothing useful when it fails is now a direct, metered cost. The framework that hides your prompts also hides the moment your bill started climbing. Strip the abstraction, log every tool call, cap your retries, and keep the verifier deterministic, not as best practices on a poster, but because each one is now a line item.