Agent Design Patterns Across Anthropic, OpenAI and Google: The Five That Ship

Anthropic, OpenAI and Google have each published a guide to agent design patterns, and between them they name 21 patterns. Lay the three guides side by side and most of those names collapse into 9 underlying ideas. Only 5 of the 9 are endorsed by all three vendors. Those five are the ones with published deployments behind them, and they are where your team should start.

The short answer. All three major vendors agree on five agent design patterns. They are a single agent using tools in a loop, routing to specialists, an orchestrator delegating to workers, a generator checked by a critic, and a human checkpoint before irreversible actions. Start with the first. Add the others only when a measured failure demands one.

The cross-vendor agent design pattern map

Three documents set the vocabulary most teams now use for agentic workflows. Each comes from a company that sells the models underneath, so each has a reason to make agents look tractable.

I grouped every named pattern by its definition, not its label. Two patterns land in the same family when they describe the same control flow, even when the vendors name them differently. The grouping is my judgement, and the matrix below shows every call.

Anthropic: five workflows and one agent

Anthropic's Building effective agents, published on 19 December 2024 by Erik S. and Barry Zhang, draws one line first. Workflows are systems where "LLMs and tools are orchestrated through predefined code paths". Agents are systems where LLMs "dynamically direct their own processes and tool usage."

It then names 5 workflows: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer. The sixth entry is the autonomous agent, which the guide describes as "typically just LLMs using tools based on environmental feedback in a loop". I left out the augmented LLM, because the guide calls it a building block rather than a pattern.

OpenAI: one agent, then two ways to add more

OpenAI's A practical guide to building agents appeared in April 2025. It defines agents as "systems that independently accomplish tasks on your behalf." Its orchestration section has exactly 3 patterns: the single-agent system, the manager pattern and the decentralized pattern.

The guide is narrower than the other two by design. It spends its remaining pages on guardrails and human intervention, which the other vendors treat as patterns in their own right.

Google: twelve patterns, sorted by control flow

Google Cloud's Choose a design pattern for your agentic AI system, last reviewed on 28 May 2026, is the longest list. It covers single-agent, sequential, parallel, loop, review and critique, iterative refinement, coordinator, hierarchical task decomposition, swarm, ReAct, human-in-the-loop and custom logic.

Several of those are variants of one another. Loop, iterative refinement and review and critique all describe output that cycles until a check passes. Single-agent and ReAct describe the same loop at two levels of detail.

Google names 4 times as many patterns as OpenAI, yet both guides open with the same advice. More names do not mean more architectures. They mean finer slicing of the same few control flows.

Quoted fragments are verbatim from each guide. Google's coordinator could also sit in row three, and I placed it in row two because the guide describes it routing requests rather than decomposing them.

Pattern 1: the single agent in a loop

This is the only point on which all three guides speak in almost the same sentence. Anthropic recommends "finding the simplest solution possible, and only increasing complexity when needed". OpenAI's general recommendation "is to maximize a single agent's capabilities first". Google writes that "we recommend that you start with a single agent".

When three competitors selling more compute all tell you to use less of it, take the advice seriously. Every pattern after this one multiplies model calls. The single agent is the baseline you measure them against.

OpenAI gives the clearest rule for when to leave it. Split when prompts carry "many conditional statements," or when tool overlap causes selection errors. The guide adds that "some implementations successfully manage more than 15 well-defined, distinct tools while others struggle with fewer than 10 overlapping tools." Tool clarity is the variable, not tool count.

The case: 49% on SWE-bench with two tools

Anthropic's January 2025 SWE-bench Verified write-up is the cleanest published case for this pattern. The upgraded Claude 3.5 Sonnet scored 49%, ahead of the previous state of the art at 45%. The scaffold was deliberately thin: "a prompt, a Bash Tool for executing bash commands, and an Edit Tool".

The design rule was to "give as much control as possible to the language model itself, and keep the scaffolding minimal". The agent sampled until it decided it was finished or hit its 200,000 token context. No chain, no router, no critic.

The detail worth copying is where the engineering effort went. Anthropic's original guide says that while building this agent, the team "spent more time optimizing our tools than the overall prompt". The guide calls this the agent-computer interface, and it is the cheapest lever in the whole map. Before you add an agent, rewrite a tool description.

Pattern 2: routing and triage

A classifier reads the input and sends it to a narrower handler. Anthropic frames it as separation of concerns, so that tuning one kind of request does not degrade another.

OpenAI's decentralized pattern is the same idea with a twist. Instead of a router that stays in control, agents "operate as peers, handing off tasks to one another based on their specializations." The receiving agent takes over the conversation. Google's coordinator sits between the two, keeping a central agent that dispatches to specialists.

The practical difference is who owns the conversation after the handoff. In a router, the routing layer stays accountable. In a peer handoff, accountability moves with the user, which is simpler to build and harder to debug when a request bounces twice.

The evidence for this pattern is thinner than its popularity suggests. OpenAI's guide names no customer at all, and its triage examples are illustrative scenarios. Anthropic's appendix points instead to support vendors who price on "successful resolutions," which is a commercial signal rather than an architecture disclosure. Resolution pricing is covered in the breakdown of Intercom Fin's per-resolution pricing.

My position: route on a cheap classifier before you route on an agent. A routing decision is the easiest step in any system to evaluate offline, because the correct label is usually knowable. If you cannot measure routing accuracy, you are not ready for anything further down this list.

Pattern 3: orchestrator and workers, or the manager pattern

This is what most people mean by multi-agent. One model plans, delegates bounded jobs, and assembles the result. Anthropic calls it orchestrator-workers, OpenAI calls it the manager pattern, and Google calls the deepest version hierarchical task decomposition.

Anthropic's guide identifies the feature that separates it from plain parallel work. In orchestrator-workers, subtasks "aren't pre-defined, but determined by the orchestrator based on the specific input." That makes it the right pattern when you cannot know in advance how many pieces a task has.

The case: Anthropic's Research system

Anthropic's June 2025 post describes its Research feature as "an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel". With Claude Opus 4 leading Claude Sonnet 4 subagents, it outperformed single-agent Claude Opus 4 by 90.2% on an internal research evaluation.

Spinning up 3 to 5 subagents in parallel, each running several tools at once, cut research time by up to 90% on complex queries. The token bill is large, and the cost case is examined in the analysis of why multi-agent systems are overrated. Anthropic also wrote that most coding tasks involve "fewer truly parallelizable tasks than research."

The case: Google's AI co-scientist

Google Research published a second example in February 2025. Its AI co-scientist uses "a coalition of specialized agents" named Generation, Reflection, Ranking, Evolution, Proximity and Meta-review. A Supervisor agent "assigns the specialized agents to the worker queue and allocates resources."

The system is a manager pattern wrapped around a critic loop, which is why it appears again below. The human preference study covered "a smaller subset of 11 research goals," and the authors called the sample size small.

Pattern 4: generator and critic loops

Here one step produces output and another step judges it, and the loop repeats until the judge is satisfied or a limit is reached. Anthropic calls it evaluator-optimizer. Google gives it three names: review and critique, iterative refinement, and loop. OpenAI does not list it as an orchestration pattern, and instead files output validation under guardrails.

A critic that blocks bad output is a guardrail. A critic that sends output back for another attempt is a pattern. The code is nearly identical, and the risk profile is not, because only the second can loop.

Anthropic names the precondition that matters most. The pattern works "when we have clear evaluation criteria, and when iterative refinement provides measurable value." Without a checkable criterion, a critic loop just spends tokens agreeing with itself.

The case: AlphaEvolve in production

The strongest deployment evidence in this whole map belongs to this pattern. Google DeepMind's AlphaEvolve, announced on 14 May 2025, "pairs the creative problem-solving capabilities of our Gemini models with automated evaluators that verify answers". It then "verifies, runs and scores the proposed programs using automated evaluation metrics".

A scheduling heuristic it discovered had been in production for over a year at publication. It continuously recovers, on average, 0.7% of Google's worldwide compute resources. It also sped up a kernel in Gemini's architecture by 23%, which DeepMind says cut Gemini's training time by 1%.

I think this is the most underrated result in agent design. The winning ingredient is not more agents. It is an evaluator that can be run automatically and cannot be argued with. Code compiles or fails, and a schedule frees capacity or it does not.

The co-scientist shows the other side. Its ranking tournament produces an Elo score, and Google's own caption warns that "the Elo is an auto-evaluation and is not based on an independent ground truth". A critic that is another model's opinion is weaker than a critic that is a test. If you are building one, start with the guide to building an LLM evaluation suite, because the critic is only as good as the eval behind it.

Every case in this table was published by the vendor that built the system. None has been independently reproduced. The grade column ranks production use above internal evaluation above benchmark, and all three above guidance.

Pattern 5: human checkpoints on irreversible actions

All three vendors put a person back into the loop, and they disagree on where. Google treats human-in-the-loop as a named pattern that "integrates points for human intervention directly into an agent's workflow." OpenAI gives it a section with two triggers. Anthropic mentions it inside its coding appendix.

OpenAI's two triggers are the most usable rule written in any of these guides. The first is "exceeding failure thresholds," meaning limits on retries or actions. The second is "high-risk actions," which are sensitive, irreversible or high-stakes and "should trigger human oversight until confidence in the agent's reliability grows."

Anthropic's version is shorter. Even where automated tests verify a coding agent's output, "human review remains crucial for ensuring solutions align with broader system requirements." Passing the tests and doing the right thing are separate questions.

The phrase worth underlining is "until confidence grows." It implies the checkpoint is temporary and earned away with evidence. Most teams I have seen do the opposite: they add approvals in a panic after an incident and never remove them. The design work, including where a checkpoint costs least, is covered in the post on human-in-the-loop architecture.

No guide publishes a deployment figure for this pattern. It is the consensus pattern with the least measurement behind it, which is a strange position for the one meant to catch everything else.

Agent orchestration patterns only one or two vendors push

Four families fail the all-three test. Two of them fail on a single vendor.

Chains and parallel fan-out: OpenAI's deliberate gap

Anthropic and Google both name fixed sequential chains and parallel fan-out. Anthropic's parallelization comes in "two key variations," sectioning and voting. Google's Agent Development Kit ships the same ideas as workflow agents that run "without consulting an AI model for assistance with the orchestration," which it says gives "deterministic and predictable execution patterns".

OpenAI leaves both out on purpose. Its guide says applications that integrate LLMs but do not use them to control workflow execution are not agents. That is a definitional choice rather than a technical claim, and I think it is the wrong one for buyers. Deterministic chains are where most production value sits, precisely because they are predictable. Excluding them just keeps them out of the agent budget conversation.

The other single-vendor families are Google's. Its swarm pattern uses "a collaborative, all-to-all communication approach," and Google itself warns that "it represents the most complex and costly multi-agent pattern to implement." Custom logic is a catch-all for code-defined orchestration. When the vendor that documents a pattern also calls it the costliest, treat it as research, not architecture. If a vendor's framework pushes you toward it, read the case for building your own thin agent framework before committing.

Where this pattern map is weakest

Three problems, in descending order of how much they should worry you.

First, every case study here was written by the company that built the system and sells the model. The 90.2%, the 49% and the 0.7% are all self-reported. None of the three vendor guides names a single independent customer with outcome figures. OpenAI's guide refers only to "numerous customer deployments." A pattern map built on vendor evidence inherits vendor incentives, and this one does.

Second, the guides are ageing faster than the patterns. Anthropic's own page now carries a note that much of the tooling landscape it describes "has changed since December 2024". Google's Agent Development Kit documentation says that from ADK 2.0, template workflows "have been superseded by more flexible workflow structures, including graph-based workflows and dynamic workflows". The control flows survive. The names and the framework mappings do not.

Third, the grouping is mine. Placing Google's coordinator under routing rather than orchestration is a defensible call, and the opposite call is defensible too. Moving it would not change the five shared families, but it would change how strongly Google endorses each. Read the matrix as an argument, not a measurement.

There is also a case that the whole exercise misleads. Pattern catalogues encourage teams to pick an architecture first and fit the problem to it. The strongest result in this post came from a team that picked an evaluator first. If your pilot is already failing, the reasons are more often data, ownership and scope than pattern choice, as the analysis of agent pilot failure modes sets out.

Frequently asked questions

Where to start: one deletion, one measurement

Take the agent your team is building now and label every component with one of the 9 families in the matrix. If any component sits outside the five shared rows, write one sentence explaining what measured failure put it there. If you cannot write the sentence, that component is the first thing to delete.

Then find the step in your system that has a checkable answer, such as a test, a schema or a known label. Put an automated evaluator on that step before you add any agent. That is the move behind the strongest result in this post, and it costs a fraction of a new orchestration layer.

Related reading