AI Agent Workflow Patterns: 7 Patterns and When Each One Actually Wins (2026)

AI Agent Workflow Patterns: 7 Patterns and When Each One Actually Wins (2026)

AI agent workflow patterns finally have numbers attached: in January 2026, Google Research evaluated 180 agent configurations and found the same coordination change lifted parallelizable financial reasoning by 80.9% while it crushed sequential planning by up to 70% on PlanCraft. Same lever, opposite outcomes. The variable that decides is task decomposability, not agent count, and the seven patterns below get judged against published data rather than vendor diagrams.

• Seven patterns matter: sequential, routing, parallelization, orchestrator-workers, reflection, ReAct, plan-and-execute.
• Task decomposability decides the winner. Parallelizable work gains; sequential work degrades.
• Start with one agent. Add a second only when a single agent stalls below ~85% accuracy.

AI Agent Workflow Patterns at a Glance: What the Data Says

The seven AI agent patterns are sequential (prompt chaining), routing (handoff), parallelization (fan-out/fan-in), orchestrator-workers, reflection (evaluator-optimizer), ReAct, and plan-and-execute. Five vendor docs name them differently, but these seven shapes cover every taxonomy Anthropic, OpenAI, Vercel, Microsoft, and Google Cloud currently publish. Human-in-the-loop is not one of the seven: it is a control layer that wraps any of them.

Read the measured column skeptically. Three rows carry real numbers; four carry "no public measurement," which is the honest state of the field in 2026. Five vendors publish five different names for what are really three or four underlying shapes. The last column exists so you can map any of those names back to the shape underneath, which the rest of the post unpacks one family at a time.

Two columns nobody on the SERP discusses are token cost and latency budget. Sequential and routing spend the least of both; orchestrator-workers spends the most of both; parallelization trades token spend for wall-clock time. Pick the pattern by the resource your task actually constrains, not by the diagram that looks impressive.

What Are AI Agent Workflow Patterns (and What Are the 4 Stages of an AI Workflow)?

AI agent workflow design patterns are reusable shapes for arranging LLM calls, tool use, and control logic into a system. The seven that recur across every vendor taxonomy are sequential, routing, parallelization, orchestrator-workers, reflection, ReAct, and plan-and-execute. Each one trades token cost, latency, and accuracy differently, so the right pick depends on the task's structure rather than the framework you happen to use.

A typical AI agent workflow runs four stages, in a loop:

1. Plan: the model decides what to do next, given the goal and history so far.
2. Act: it calls a tool, which in 2026 usually means an MCP server or a function call. Model Context Protocol (MCP) standardizes that tool layer across models.
3. Observe: the tool result goes back into context as a new message.
4. Reflect / loop: the model judges whether the result is good enough, then loops or stops.

Every pattern in this post is a different way of wiring those four stages. Sequential fixes the order in code. ReAct lets the model pick the next stage each turn. Orchestrator-workers splits the loop across several models.

One distinction matters before the catalog. A workflow is predetermined code paths; an agent hands control to the model. Anthropic draws the line this way in Building Effective Agents: "Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale."

If you arrived looking for the classic types of agents in AI (simple reflex, model-based, goal-based, learning), that taxonomy predates LLMs; the seven patterns above are the ones that decide whether your build ships.

The Deterministic Patterns: Sequential, Routing, and Parallelization

Three patterns keep control in your code rather than the model. They are the cheapest to run and the easiest to debug, and the Claude team's guidance from March 2026 is blunt about where to start: "Start with the simplest pattern that solves your problem. Default to sequential."

Sequential (prompt chaining)

One call feeds the next. You split a hard task into ordered steps, and each step gets the previous step's output as its input. The win is legibility: you can inspect every intermediate result and cache each step. Avoid it when the subtasks are independent, because you are paying latency for ordering you do not need. If state has to survive between steps or across sessions, that is a memory problem, not a chaining problem; see our agent memory guide for the split. Its only published endorsement is a default: no study measures a gain from chaining itself, because it is the baseline every other pattern pays extra to beat.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (handoff)

A cheap classifier reads the input and dispatches it to a specialist prompt or model. OpenAI frames it in the Agents SDK docs: "A triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn." Avoid routing when the classifier is less reliable than just running one general path, because every misroute is a silent wrong answer. The named failure mode here is context loss across the handoff: the specialist only sees what the router forwards. Carrying the full trace is a context engineering decision, and getting it wrong is why routed systems feel forgetful. The token math favors routing anyway: the classifier runs on a small model (gpt-4o-mini above), so a router adds a few hundred cheap tokens per request rather than a second expensive call.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelization (fan-out/fan-in)

Independent subtasks run at once, then a merge step combines them. Anthropic splits this into sectioning (divide the work) and voting (run the same task several times and compare). This is the shape Google Research measured at +80.9% over a single agent on parallelizable financial reasoning in January 2026, precisely because the task decomposed cleanly. Avoid it the moment step n+1 depends on step n's output; parallelizing a dependency chain just reorders the wrong answers faster. Latency is the other half of the gain: independent calls run concurrently, so wall-clock time falls roughly with the number of workers while total token spend stays flat.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs Plan-and-Execute: Which Reasoning Pattern Should You Use?

ReAct interleaves reasoning with action: the model thinks, calls a tool, observes the result, and only then decides the next step. Plan-and-execute writes the full plan before any tool runs, then executes the steps in order. ReAct adapts to surprises mid-run; plan-and-execute pays for one large planning call up front and trusts the route.

ReAct decides its next step after every observation; plan-and-execute commits to the whole route before the first tool call.

ReAct comes from Yao et al. (arXiv 2210.03629, v1 October 2022, v3 March 2023), which reported +34% absolute success on ALFWorld and +10% on WebShop over imitation and reinforcement-learning baselines, using just one or two in-context examples. It is the default loop behind most tool-using agents, and it is a gap in the #3 SERP result: Microsoft Learn's 7,133-word orchestration doc omits ReAct entirely. That observe-decide cadence is why ReAct handles open-ended tasks ("browse until you find X") better than any up-front plan: the plan would have to guess what the pages contain before reading them.

Plan-and-execute comes from Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), which first devises a plan dividing the task into subtasks, then carries them out. The paper reports beating zero-shot chain-of-thought across all ten evaluated datasets; we quote no single figure because the paper's abstract publishes none. Use it when the route is predictable and replanning after every step would waste tokens. The tradeoff is brittleness: if step three fails, a plan-and-execute loop needs an explicit replan hook, whereas ReAct replans by construction.

The measured-evidence row is the honest tell. ReAct has a 2022 paper with task-level numbers; plan-and-execute has a ten-dataset sweep and no headline figure, which is one reason it gets cited more often than it gets benchmarked.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

That iteration cap is not optional. A ReAct loop with no exit burns tokens until your budget does; max_steps is the cheapest guardrail in this whole post. Plan-and-execute needs the same guard one level up: cap the replans, not just the steps, or a failing plan will regenerate itself indefinitely.

The Quality Patterns: Reflection, Evaluator-Optimizer, and Human-in-the-Loop

Quality patterns spend extra tokens to raise output quality, and they only pay off when quality is measurable. Reflection (Anthropic calls it evaluator-optimizer) runs a generator and a critic in a loop: one model drafts, another critiques, the draft improves. If you cannot score the output with a test, a rubric, or a grader model, the critic is just extra tokens arguing with itself. Building that scorer is the hard part; our guide to evaluating agents in production covers what a usable score function takes. Where the precondition holds, the pattern is cheap insurance: Anthropic describes evaluator-optimizer as two LLM calls in a loop, one generating and one critiquing, which buys a measurable quality lift for a few extra seconds of latency.

The failure mode nobody diagrams is runaway reflection: the critic and generator loop forever, or worse, oscillate. The fix is a hard iteration cap plus a no-improvement break, written in code rather than requested in the prompt:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop is a control layer, not an eighth pattern. It wraps any of the seven: a human approves before an irreversible step runs. Only 2 of the 6 top SERP results cover it at all. Place the gate at irreversible actions, real spend, and anything that leaves your system as external communication. Everything else should run unattended or not run. The gate itself should be dumb code, not another LLM: an approval queue, a spend threshold, a domain allowlist. Putting a model in charge of deciding whether a human should look defeats the purpose.

Is Multi-Agent Worth 15× the Tokens? What the Benchmarks Actually Say

Orchestrator-workers is the seventh pattern: a lead agent decomposes a task, delegates pieces to worker agents, and merges what they return. "Multi-agent" is this pattern taken to its extreme, not a separate shape, so the question is really when the orchestrator earns its overhead.

When should you use multi-agent instead of a single agent? Only when a single agent stalls below about 85% accuracy on the task. That rule of thumb circulated on r/AI_Agents (2026-04-23) alongside the Google Research study, and it matches the measured data: above that bar, added agents add cost and error amplification without adding accuracy.

Here is every published number we could verify, side by side:

One caveat before you click through: every Google Research figure above comes from the 2026-01-28 blog post, and the paper behind it (arXiv 2512.08296) has been revised since, so its current version reports 260 configurations and R² = 0.373 rather than the blog's 180 and 0.513. The direction holds either way; the exact figures depend on which version you are reading.

Two of these rows are routinely misquoted, so here is the arithmetic. Anthropic's 15× figure is measured against a chat interaction, and its single-agent figure is 4×. So multi-agent costs roughly 15 / 4 = 3.75× a single agent's tokens, not 15×. And Google Research's error amplification of 17.2× for independent agents versus 4.4× for centralized ones means an orchestrator contains roughly 17.2 / 4.4 = 3.9× less error amplification than letting agents run unsupervised.

Reading Anthropic's write-up against the Google Research numbers, our read is that decomposability, not agent count, is the variable that decides. Anthropic's research task split cleanly into parallel sub-searches, so more agents helped. Google's sequential planning tasks did not split, so more agents got in each other's way.

That matches what practitioners say once systems hit production. On r/AI_Agents, a thread titled "Multi agent systems are a total nightmare in production" (2026-04-23, 56 points, 68 comments) came from an OP who has shipped 20+ client systems: "The ones that actually stay running… are almost embarrassingly simple," and "every time one agent talks to another, you lose context. It's like that game of Telephone." The top comment distills the whole section: "try to solve your problem with a single agent. If this agent has >85% accuracy a multi agent system will not add any more value."

Before you add an agent, try the cheap fixes Anthropic measured: one improved tool description produced a 40% drop in task-completion time, and parallel tool calling cut research time by up to 90%. Both beat a second agent on cost. If you do go multi-agent in a real tool, Claude Code subagents are orchestrator-workers you can inspect line by line.

Same Pattern, Five Names: A Framework Rosetta Table

The same four shapes appear under different names in every vendor's docs, and the naming does not transfer between frameworks. Microsoft's "magentic" and "group chat" mean nothing in the OpenAI SDK until you translate them, and that translation tax is a real cost this table removes.

Five vendors, five vocabularies, three or four real shapes. The practical cost shows up when you switch frameworks: a team moving from Microsoft's Agent Framework to the OpenAI SDK has to re-map "magentic" onto agents-as-tools and "group chat" onto a handoff graph before a single line of code transfers. Google Cloud's eleven-name taxonomy is the longest, Anthropic's seven-name list is the most cited, and the Claude blog's three names are the ones you will implement first. Read the shape, then read the SDK. The column headers are the docs themselves: Anthropic, the Claude blog, the OpenAI Agents SDK, the Vercel AI SDK, Microsoft Learn, and Google Cloud. Once you see the shapes, picking a framework is a separate decision; our rundown of the best AI agent frameworks in 2026 and the LangGraph vs CrewAI vs the OpenAI Agents SDK comparison cover that one.

When Should You NOT Use an Agent Workflow at All?

Often, you should not. The most-upvoted decision ladder on r/AI_Agents (2026-03-09) puts it plainly: "If if…then statements will work use that. Then if traditional workflows will work use that. Otherwise use agentic AI." Two of the top three SERP results are cloud documentation that structurally cannot tell you to build less. We can. The data in this post points the same direction: the two biggest measured gains (+80.9% and +90.2%) both came from tasks that decomposed cleanly, and the worst measured loss (−70%) came from forcing agents onto a task that did not.

The failure modes are named, and each one now has a number attached:

• Context loss across handoffs: every agent-to-agent message drops state (the r/AI_Agents "Telephone" complaint, 2026-04-23).
• Error amplification: 17.2× for independent agents versus 4.4× centralized (Google Research, 2026-01-28).
• Runaway reflection loops: cap iterations and break on no improvement, as in the code above.
• Sequential-task degradation: 39–70% worse when you parallelize work that does not decompose (Google Research, 2026-01-28).
• Cost blowout: roughly 15× chat tokens for a multi-agent system (Anthropic, 2025-06-13).

Every one of those failure modes has a cap you can write in ten lines of code, and the cap is always cheaper than the agent you were about to add.

Cognition's Walden Yan made the same case from the builder's side in Don't Build Multi-Agents (2025-06-12): "Share context, and share full agent traces, not just individual messages," and "Actions carry implicit decisions, and conflicting decisions carry bad results." The r/AI_Agents comparison is the one we keep coming back to: "multi agent starts looking a lot like microservices. powerful when the boundaries are real, painful when they're invented."

How Techsy Approaches Pattern Selection

The ladder below is our reading of the Google Research and Anthropic findings plus the practitioner threads, not a measured result of our own. We run it top to bottom and stop at the first row that fits:

Three things follow from the data in this post. Start sequential, because Anthropic says to and nothing on the SERP disproves it. Parallelize only what decomposes, because the same coordination change measured at +80.9% also measured at −70%. And treat a second agent as a last resort, because the token bill is real and the error amplification is measured. The through-line is that adding agents is a scaling move, not a quality move: the benchmarks reward it only where the work splits, and the practitioner threads confirm it everywhere else. If you want a second opinion on an architecture before you build it, Get a free consultation.

Frequently Asked Questions

What are the 7 AI agent patterns?

The seven are sequential (prompt chaining), routing (handoff), parallelization (fan-out/fan-in), orchestrator-workers, reflection (evaluator-optimizer), ReAct, and plan-and-execute. They recur under different names in every vendor taxonomy, from Anthropic to Google Cloud. Human-in-the-loop gets discussed alongside them but is a control layer that wraps any of the seven, not an eighth pattern.

What are the 4 stages of an AI agent workflow?

Plan, act, observe, reflect. The model plans a next step, acts by calling a tool, observes the tool's result entering context, then reflects on whether the goal is met and loops or stops. Every pattern in this post is a different way of wiring those four stages together.

What's the difference between an AI workflow and an AI agent?

A workflow follows predetermined code paths; an agent lets the model direct its own control flow. Anthropic's rule: workflows for predictability on well-defined tasks, agents for flexibility when model-driven decisions are needed at scale. Most production systems are workflows with a few agent steps inside them.

ReAct vs plan-and-execute: which should I use?

Use ReAct when the next step depends on what the last tool returned and the route can change mid-run. Use plan-and-execute when the route is predictable up front and replanning after every step would waste tokens. ReAct measured +34% on ALFWorld (Yao et al., 2022); plan-and-execute beat zero-shot CoT on ten datasets (Wang et al., 2023).

Do I need a framework like LangGraph to use these patterns?

No. Every code block in this post is a plain SDK call, and the patterns predate the frameworks that name them. A framework earns its keep at state persistence, retries, and tracing, not at the pattern itself. If you are choosing one, our frameworks comparison covers the tradeoffs.

How do I stop a reflection loop from running forever?

Two guards, both in code: a hard iteration cap (we use 4 rounds) and a no-improvement break that stops the moment the critic's rewrite scores no better than the current draft. Do not trust the prompt to end the loop; the model has no idea what things cost.

When is a single agent enough?

When it clears roughly 85% accuracy on the task. That heuristic, circulated on r/AI_Agents (2026-04-23) alongside the Google Research study, matches the benchmarks: above that bar, extra agents add cost and error amplification without adding accuracy. Measure the single-agent baseline before you design anything bigger.

Where can I find AI agent workflow pattern examples with code?

The five Python blocks above cover sequential, routing, parallelization, ReAct, and reflection, all as plain SDK calls you can lift directly. For vendor-flavored examples, the Vercel AI SDK ships runnable TypeScript per pattern and the OpenAI Agents SDK docs cover handoffs and agents-as-tools. Links to both sit in the Sources list below.

Sources

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); paper: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (updated 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)