Agent Design Patterns: Which Ones Are Actually Worth Building

TL;DR

Most catalogues of agent design patterns read like a menu with no opinions attached, and the measurements that would settle the argument are already published. Of the patterns that keep showing up in these lists, we'd reach for two on a normal project: tool use, which isn't really optional, and manager-worker, when the task genuinely decomposes into independent domains.

Here is the number that sorts the rest. On GSM8K, three ChatGPT instances running two rounds of debate scored 83.0. Plain majority voting over the same nine responses scored 88.2. The debate spent the same budget and finished lower.

Reflection comes out worse. Asked to review its own answer with no new evidence, GPT-3.5 went from 75.9 to 74.7 on GSM8K and from 75.8 to 41.8 on CommonSenseQA. Self-review is not a free safety net. It has a sign, and the sign is often negative.

This isn't an argument that more than one agent never pays. Anthropic reported its multi-agent research system beating single-agent Claude Opus 4 by 90.2% on an internal research eval, at roughly 15 times the tokens of a chat interaction. When the work is genuinely parallel and the answer is worth that much, pay it.

The sorting question is narrow: does the task need one brain with tools, or does it split into pieces that don't need to talk to each other while they work. Ask that before you open the catalogue.

Overview

Every list of agent design patterns looks the same: a diagram, a "when to use it," a few industry examples, repeated six or eight times with the names swapped out. Read enough and every pattern sounds equally reasonable, which is the problem. They aren't, and for several of them somebody has already run the experiment.

Chain-of-thought, ReAct, tree-of-thought and multi-stage planning already get a full treatment, with working code, in a companion guide on planning algorithms for agents. What's left is the layer above: whether an agent should reach for a tool at all, whether it should check its own work, and how a task gets split across more than one agent when a single loop stops being the right shape.

Take a claims-processing agent as the running example. It reads an incoming claim, checks it against a policy document, decides on an initial disposition, and either resolves it or routes it to a human. Microsoft's own orchestration guidance frames the choice as a ladder and tells you to climb it reluctantly: a single agent with tools is "often the right default for enterprise use cases," and each rung above it "introduces coordination overhead, latency, and cost."

Tool Use Isn't Optional

Calling tool use a "pattern" undersells it. An agent that can only reason over what's in its training data and a prompt isn't an agent doing claims processing; it's a chatbot guessing at policy language it half remembers. The moment the task depends on a real policy document, a real claim record, or a real decision that has to land somewhere, tool use stops being optional and becomes the baseline every other pattern sits on top of.

Whether an agent calls tools barely varies from one to the next. How tightly those tools are scoped varies enormously, and that's a permissions question more than a design-pattern one; it gets its own treatment elsewhere. OWASP's entry on excessive agency is the compact version: the risk decomposes into excessive functionality, excessive permissions, and excessive autonomy, and its first two mitigations are to minimise the extensions an agent is offered and to limit the functions inside each one.

The design point here is narrower. Treat the tool call as the place uncertainty gets grounded against the real world, not as a convenience for fetching data the model could have guessed at. An agent that calls a tool and then narrates around the result defeats the point of having called it.

Reflection and Self-Critique

Reflection sounds like exactly the fix a claims agent needs: generate a disposition, review it, catch the mistake before it ships. Huang and colleagues at Google DeepMind stripped out the oracle labels that earlier self-correction papers had quietly relied on, then ran intrinsic self-correction on three benchmarks. Accuracy went down.

Table 1 — Intrinsic self-correction on reasoning benchmarks, from Huang et al. (ICLR 2024). Every row below a standard-prompting row costs more calls and scores lower.

The mechanism is the useful part. On GSM8K, "74.7% of the time, GPT-3.5 retains its initial answer," and when it does change, it more often turns a correct answer into an incorrect one than the reverse. The paper's conclusion is blunt: "LLMs cannot properly judge the correctness of their reasoning." A model reviewing its own work with no new information is grading its own homework with the answer key it already got wrong.

Take the claims agent. It denies a claim citing an exclusion that doesn't apply to this plan type, then reflects and confirms the denial, reasoning from the same misread section. The class of error most likely to survive reflection is exactly the class most worth catching.

Which does not mean reflection loops are useless. Reflexion reported 91% pass@1 on HumanEval against 80% for the GPT-4 baseline of the time, and it got there by keeping reflections in an episodic memory buffer across trials. The thing to notice is where the signal came from: unit-test results, an external verdict the model didn't author. Huang's paper lists Reflexion under "use of oracle labels" for exactly that reason.

Manager-Worker

This is the multi-agent pattern we'd reach for first, because it maps cleanly onto how most real workloads are actually shaped: a request comes in, it needs routing to whichever specialist handles that kind of work, and the results need assembling into one answer. Anthropic calls it orchestrator-workers. Microsoft splits the same idea into handoff orchestration, where an agent decides who takes the task next, and sequential orchestration, where the order is fixed in the workflow rather than chosen by a model. A claims intake system that splits auto, property, and liability across three specialists, with a manager that classifies the incoming claim and dispatches it, is this pattern whether or not anyone designed it that way on purpose.

The pattern earns its keep when the subdomains genuinely don't need each other mid-task. The auto claims agent doesn't need to watch the liability agent work; it needs the claim, the relevant policy section, and a place to send its answer. That independence is what makes manager-worker tractable to debug: a wrong answer traces back to one worker and one input, not to a conversation between three agents that each nudged the outcome.

Figure 1 — Manager-worker on the claims example, with the failure mode that turns a dispatch into an open-ended negotiation.

That failure mode has a name and a frequency now. The MAST taxonomy, built from 150 hand-annotated traces across seven multi-agent frameworks and extended to a dataset of more than 1,600, puts "unaware of termination conditions" at 12.4% of observed failures and "step repetition" at 15.7%. Both are managers that keep asking for another pass because the last answer wasn't quite right. The loop-control machinery that prevents it, budgets, rerun limits, a stop condition that actually terminates, gets more implementation depth in the companion post on multiagent patterns.

Peer Collaboration and Debate

Peer collaboration drops the manager and lets agents with different specialties talk to each other directly until they converge. Microsoft's catalogue calls this group chat orchestration and lists "multiagent debate" as one of its aliases, which tells you how thin the line between the two is in practice. Its guidance is specific: keep it "to three or fewer agents," and avoid the pattern entirely when the coordinator "has no objective way to determine whether the task is complete."

Debate is the disciplined cousin: one agent proposes, another attacks the proposal, and something decides who wins. It also has the most surprising measurement attached to it. Huang's group replicated the original three-instance, two-round debate setup on the full GSM8K test set rather than the 100-example subset the original used, and compared it against self-consistency at matched response counts.

Table 2 — Debate against plain majority voting at equal cost, from Huang et al. Matched on responses, voting wins by 5.2 points.

The paper's reading of that result is the one we'd adopt. Rather than calling it debate or critique, "it is more appropriate to perceive it as a means to achieve 'consistency' across multiple model generations," where the only real difference from majority voting is that the vote is model-driven instead of counted. Model-driven voting is the expensive way to do it and, on this benchmark, the worse way.

So we think peer collaboration is worth building only when the task truly can't be decomposed up front. Design review is the honest example. For most claims-style workloads the domains really are independent, and paying the coordination cost of open-ended conversation buys nothing manager-worker doesn't give you for less. If the failure you're worried about is "the agent cited a policy clause that doesn't exist," a second agent arguing about it burns calls to reinvent what a citation check does directly.

Ensemble and Voting

Ensemble patterns run the same request through multiple agents independently and combine the answers: by majority, by a scoring aggregator, or by picking the most internally consistent response. Unlike most of this catalogue, the headline version has a clean published effect size. Self-consistency, which is majority voting over sampled chain-of-thought paths, reported gains over greedy decoding of "GSM8K (+17.9%), SVAMP (+11.0%), AQuA (+12.2%), StrategyQA (+6.4%) and ARC-challenge (+3.9%)."

Those are real numbers and they come with a real bill. Every point costs a full extra generation, and the gains compress as k rises: in Table 2 above, going from three responses to nine bought 5.7 points. Anthropic's figure for the general case is that agents run about 4 times the tokens of a chat interaction and multi-agent systems about 15 times, which only makes sense where "the value of the task is high enough to pay for the increased performance."

For a claims agent auto-approving small, reversible payouts, ensemble voting is overhead; a wrong small claim gets corrected on appeal for less than tripling every model call costs across a month of volume. For a claim about to deny coverage on a large, disputed loss, the math flips.

What Actually Breaks

The patterns above are usually argued about on the basis of accuracy. In deployment they fail for duller reasons, and the MAST work is the first published attempt to count them. Three categories cover the distribution, with inter-annotator agreement reported at kappa 0.88.

Table 3 — Where multi-agent systems actually fail, from the MAST taxonomy across seven frameworks.

Almost half the failures are specification and control problems, the kind a stop condition or a clearer role boundary fixes, and they're cheap to engineer once you know to look. The inter-agent bucket is the one that should make you cautious about reaching for conversation: the authors note that fixes "focused on context or communication protocols are often insufficient" there.

Reliability is also not accuracy, and multi-run metrics are where that shows. τ-bench introduced pass^k, success on all k attempts, and reported agents that "succeed on <50% of the tasks" being "quite inconsistent (pass^8 <25% in retail)." A pattern that lifts single-attempt accuracy and leaves pass^8 alone has not made the system dependable, just luckier on average.

What Each One Costs

Putting the two axes side by side, calls spent and effect measured, is what the usual catalogue leaves out.

Table 4 — The catalogue priced. Blank cells in the effect column are the honest answer, not an omission.

Everything on that table with a positive number attached is buying independence: independent samples, or independent subtasks, or an external verdict. Nothing buys anything by having the same model look at the same context a second time.

Choosing Among Them

Figure 2 — Three decisions in order get you to the right pattern faster than the full catalogue does.

Two questions do most of the sorting. Does the task touch the real world, a record, a document, an action that has to land somewhere. If not, it's a reasoning problem and belongs in the planning guide. If it does, does it decompose into pieces that can run without each other's intermediate state. If so, manager-worker is the default and peer collaboration is the exception for genuinely deliberative work.

The third question only fires on the left branch, and the reflection literature reframed it for us: not "is a second opinion worth the extra call" but "is there anything other than the model available to form that opinion." If there is, use it. If there isn't, sample more and count.

Frequently Asked Questions

Which agent design pattern should I use? For most enterprise workloads, a single agent with tools, and manager-worker once the task splits along obvious domain lines. Microsoft's guidance says the same thing in more careful words: use "the lowest level of complexity that reliably meets your requirements," and a single agent with tools is "often the right default."

Does reflection actually improve accuracy? Not on its own. Without external feedback, GPT-3.5 fell from 75.9 to 74.7 on GSM8K and from 75.8 to 41.8 on CommonSenseQA over two rounds, and GPT-4 fell from 95.5 to 89.0 on GSM8K. Reflection helps when the review step has a signal the model didn't produce, which is why Reflexion's HumanEval result rests on unit-test feedback.

Is multi-agent better than single-agent? For parallel, wide-search work, sometimes substantially: 90.2% over single-agent Opus 4 on Anthropic's internal research eval. For work where agents "share the same context or involve many dependencies," including most coding tasks, Anthropic says don't. The MAST numbers are the other half of the answer, with 44.0% of observed multi-agent failures traced to system design rather than model quality.

Is debate better than majority voting? At equal cost, no. Nine responses through two rounds of debate scored 83.0 on GSM8K; nine responses through majority voting scored 88.2.

How many agents in a group conversation is too many? Microsoft's orchestration guidance puts the practical ceiling at three. Beyond that, keeping the conversation terminating gets harder, which lines up with termination failures being 12.4% of the MAST distribution.

What's the difference between orchestrator-workers and manager-worker? Nothing substantive. Anthropic says orchestrator-workers; Microsoft splits the space into handoff and sequential orchestration depending on whether a model or the workflow picks the next agent. Pick one name and keep it.

What is the magentic pattern? Microsoft's name for an orchestration where a manager agent builds and revises a task ledger for an open-ended problem instead of following a fixed plan. Its own guidance says to avoid it when the solution path can be made deterministic or when the work is time-sensitive, "not optimizing for speed" being the explicit tradeoff.

Conclusion

The catalogue is real and worth knowing. It is also narrower than it looks once you put the published numbers next to the diagrams. Tool use is the floor. Manager-worker earns a default because most enterprise workloads really do decompose into independent domains, and because a failure traces to one worker instead of a transcript. Self-consistency earns a conditional slot where a decision is expensive and hard to reverse.

Intrinsic reflection and debate are the two we'd stop reaching for. Both spend extra calls to have the model evaluate the model, and on the benchmarks where someone actually controlled for cost, both lost to the cheaper alternative. Replace reflection with a check that knows something new, and replace debate with counting.

Our honest answer for a claims agent, or most things shaped like it: tool use, manager-worker across the obvious domain split, and a review step grounded in a fresh retrieval or a validator. Add anything else when a specific failure shows up that those three don't cover.

Sources

All URLs read 2026-09-29.

• Building Effective Agents, Anthropic — prompt chaining, routing, parallelisation, orchestrator-workers and evaluator-optimizer; "we recommend finding the simplest solution possible".
• How we built our multi-agent research system, Anthropic — the 90.2% result over single-agent Opus 4, the 4× and 15× token multipliers, and when not to use multiple agents.
• Large Language Models Cannot Self-Correct Reasoning Yet, Huang et al., ICLR 2024 — Tables 1, 3 and 7 here; intrinsic self-correction degradation and debate against self-consistency at matched cost.
• Self-Consistency Improves Chain of Thought Reasoning in Language Models, Wang et al. — the +17.9% GSM8K figure and the rest of the benchmark set.
• Reflexion: Language Agents with Verbal Reinforcement Learning, Shinn et al. — 91% pass@1 on HumanEval with external test feedback and an episodic reflection buffer.
• Why Do Multi-Agent LLM Systems Fail?, Cemri et al. — the MAST taxonomy, 14 failure modes, the 44.0/32.3/23.5 category split and kappa 0.88.
• τ-bench: A Benchmark for Tool-Agent-User Interaction, Yao et al. — pass^k, sub-50% success rates and pass^8 below 25% in retail.
• AI agent orchestration patterns, Microsoft Azure Architecture Center — the complexity ladder, sequential, concurrent, group chat, handoff and magentic patterns, and the three-agent ceiling on group chat.
• OWASP LLM06:2025 Excessive Agency — excessive functionality, permissions and autonomy, and the mitigations for tool scoping.