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 that's the part worth fixing. 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 a task actually decomposes into independent domains.

The rest are narrower than their billing. Reflection helps a little and is often applied to the wrong layer. Debate and ensemble voting both spend multiple model calls to catch a mistake a deterministic check would catch for one. Peer collaboration without a coordinator is the pattern most likely to leave you reading a transcript instead of finding the bug.

None of this is an argument against knowing the full catalogue. It's an argument against treating it as a buffet where every pattern deserves a seat in your architecture just because a paper described it.

The question that actually sorts them: does your task need one brain with tools, or does it decompose into pieces that genuinely don't need to talk to each other while they work. Everything else is a special case of one of those two answers.

Overview

Every list of agent design patterns tends to look the same: a diagram, a "when to use it," a handful of industry examples, repeated six or eight times with the names swapped out. Read enough of them and every pattern starts to sound equally reasonable, which is the problem. They aren't equally reasonable. Some of them are close to a default. Some of them are a specific answer to a specific shape of task, and using one outside that shape adds orchestration cost for no benefit.

Chain-of-thought, ReAct, tree-of-thought, and multi-stage planning already get a full treatment, including working code, in a companion guide on planning algorithms, so none of that gets rehashed here. What's left, and what actually needs an opinion attached, is the layer above that: 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 for it.

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. Most of the patterns below are different answers to the question of what happens between "read the claim" and "produce a disposition."

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, and whether the agent can reach anything beyond what this specific task needs, does. That's a permissions question more than a design-pattern one, and it gets its own treatment elsewhere on this blog rather than a paragraph here. The design point worth making 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 entire 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. It helps, and it helps less than the diagram suggests, because the thing doing the reviewing is the same model that produced the original answer, working from the same context that produced the mistake in the first place. A model checking its own reasoning without any new information is grading its own homework with the answer key it already got wrong.

Take the claims agent again. It denies a claim citing a policy exclusion that doesn't actually apply to this plan type, then reflects on its own answer and confirms it, because the reflection pass is reasoning from the same misread policy section, not from a fresh read of the document. Nothing about asking the model to double-check itself introduces new evidence, so the class of error most likely to survive reflection is exactly the class most worth catching.

We'd still use reflection, just not as the primary defense. It catches a real share of sloppy, low-effort mistakes cheaply, one extra model call, and it's worth having for that reason alone. What actually needs to change is what the reflection step is checking against: a policy lookup that runs again independently, a schema validator on the output, a second read of the source document rather than the model's summary of it. Self-review from memory catches typos. Grounded review catches the disposition that's wrong.

Manager-Worker

This is the multi-agent pattern we'd reach for first, because it's the one that maps cleanly onto how most real workloads are actually shaped: a request comes in, it needs to be routed to whichever specialist handles that kind of work, and the results need to be assembled into one answer. A claims intake system that splits auto, property, and liability claims across three specialist agents, with a manager that classifies the incoming claim and hands it off, is a manager-worker system whether or not anyone designed it that way on purpose.

The pattern earns its keep specifically when the subdomains genuinely don't need each other mid-task. The auto claims agent doesn't need to see what the liability agent is doing while it works; 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 a little.

The failure mode worth naming is a manager that keeps asking workers for another pass because their first answer wasn't quite right, turning a single dispatch into an open-ended negotiation. That's a different pattern wearing manager-worker's diagram, and it needs the loop-control machinery, budgets, rerun limits, a condition that actually terminates, covered in more implementation depth in the companion post on multi-agent workflow patterns.

Peer Collaboration and Debate

Peer collaboration drops the manager and lets agents with different specialties talk to each other directly until they converge on an answer. It's the pattern people reach for when the task genuinely needs several perspectives in the room at once, and it's also the pattern most likely to leave a team staring at a long transcript trying to figure out where things went sideways, because nothing in the structure says who's actually in charge of deciding the conversation is done.

We think peer collaboration is worth building only when the task truly can't be decomposed into independent pieces up front, design review is the honest example, where a decision genuinely benefits from more than one viewpoint arguing it out. For most claims-style workloads it's the wrong tool: the domains really are independent, so paying the coordination cost of open-ended peer conversation buys nothing that manager-worker doesn't already give you for less.

Debate is peer collaboration's narrower, more disciplined cousin: one agent proposes, another is explicitly assigned to attack the proposal, and something decides who wins. It's a legitimate technique for one thing specifically, adversarial evaluation of a claim someone wants extra scrutiny on. It is an expensive way to catch what a deterministic check would catch for a fraction of the cost. If the actual failure you're worried about is "the agent cited a policy clause that doesn't exist," a second agent arguing about it burns a model call to reinvent what a citation check already 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. The appeal is real: independent errors don't correlate perfectly, so an ensemble smooths out some of the noise any single run would carry.

For a claims agent that's auto-approving small, reversible payouts, ensemble voting is overhead without a matching benefit; a wrong small claim gets corrected on appeal at a fraction of what tripling every model call costs across a month of volume. For a claim that's about to deny coverage on a large, disputed loss, the math flips, and paying for three independent reads plus a verification step before anything ships is a reasonable trade. Reach for ensembles selectively, not as a default reliability tax on every request.

Choosing Among Them

Figure 1 — Two decisions, in order, get you to the right pattern faster than the full catalogue does: whether the task needs grounding in the real world, and whether it splits into pieces that can work without talking to each other.

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, this is a reasoning problem and belongs in the planning guide, not here. If it does, does the task decompose into pieces that can run without needing each other's intermediate state. If it does, manager-worker is the default and peer collaboration is the exception reserved for genuinely deliberative work. If it doesn't, the question becomes how much a second opinion is worth, and that's a cost question, not an architecture one: cheap and general gets reflection grounded in something other than the model's own memory, expensive and high-stakes gets ensemble or debate, applied to the specific decisions that justify it rather than to every request by default.

Conclusion

The catalogue is real and worth knowing. It's also mostly narrower than it looks once you ask what each pattern is actually buying and at what price. Tool use is the floor everything else stands on, not a choice to weigh. Manager-worker earns a default position because most enterprise workloads really do decompose into independent domains. Reflection, debate, ensemble voting, and peer collaboration are all real tools for real situations, and all four get reached for far more often than their situations actually occur.

Our honest answer for a claims agent, or most things shaped like it: tool use, manager-worker across the obvious domain split, and a reflection step that checks against fresh evidence rather than its own memory. Everything past that gets added only when a specific failure mode shows up that those three don't cover, not because the catalogue has four more entries left.