Agentic Workflows Explained: 5 Patterns That Work in 2026

Last updated: May 2026 · By Ignacy Kwiećień, founder & editor-in-chief, DecodeTheFuture.org

What is an agentic workflow?

An agentic workflow is a system in which a large language model and its tools are coordinated through predefined code paths that a developer wrote, not paths the model chose at runtime. The term and its precise definition come from Anthropic’s December 2024 engineering essay Building Effective Agents, which has since become the most-cited reference in production agent design. The same essay defines an agent as the opposite: a system “where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” Everything else in the agentic AI vocabulary — orchestration, planning, tool use, reflection — sits on top of that one line.

The distinction matters because the two designs trade off in opposite directions. A workflow gives you predictability, lower token costs, deterministic audit trails, and a graph that a compliance officer can read. An agent gives you adaptability to inputs you did not anticipate, at the cost of higher latency, higher token spend, and a control loop that can drift. In 2026 nearly every shipping system that calls itself “agentic” is in fact a workflow with one or two agentic nodes embedded inside it — the open-ended decision making is bounded to the small region of the graph that genuinely benefits from it.

The other reason workflows dominate production right now is mathematical. Even a 95% reliable single step compounds badly: a ten-step end-to-end agent at 95% per-step success runs at 0.95¹⁰ ≈ 60% overall success, and at 85% per-step it drops to 0.85¹⁰ ≈ 20%. Gartner reported in mid-2025 that over 40% of agentic AI projects will be canceled or fail to reach production by 2027, and the dominant root cause is precisely this compounding problem. Workflows beat agents in most settings because each predefined edge is verified, retried, and instrumented; the few edges that need open-ended reasoning are scoped tightly enough that compound failure stays bounded.

Agentic workflow vs AI agent — the only distinction that matters

Most articles online treat “agent” and “agentic workflow” as synonyms or as marketing-driven labels. They are not. The cleanest test is the question: who draws the next edge of the graph — the developer or the model?

This is also why teams that started with “let’s build an autonomous agent” in 2024 ended up shipping graphs in 2026. The market converged on workflows for the same reason it converged on type-safe languages a decade earlier: production cost is easier to control when the structure is explicit. For a deeper read on the agent side of the distinction, see our What is an AI Agent? Complete Guide for 2026 and AI Agent Architecture Explained; for orchestration when multiple agentic nodes coordinate, our Multi-Agent Systems Explained.

The 5 canonical agentic workflow patterns

Anthropic’s Building Effective Agents identifies five composable patterns. Eighteen months later they have become the de-facto vocabulary across LangGraph, Microsoft Agent Framework 1.0, Pydantic AI v1, CrewAI, OpenAI Agents SDK, and academic literature. The patterns are not exclusive; production systems chain them. The diagram below shows the canonical shape of each.

1. Prompt chaining

Prompt chaining decomposes a task into a fixed sequence of LLM calls in which each step processes the output of the previous one, optionally with a deterministic gate in between that validates intermediate state and short-circuits on failure. Use it when the task naturally splits into ordered subtasks with crisp boundaries: outline then draft then translate; extract entities then resolve them then summarise; generate code then check it compiles then deploy. The gain over a single prompt is precision (each step has one job and a fitted prompt) and verifiability (the gate catches drift before the next call burns tokens).

from pydantic_ai import Agent
from pydantic import BaseModel

class Outline(BaseModel):
    sections: list[str]

class Draft(BaseModel):
    text: str
    word_count: int

outliner = Agent("claude-opus-4-7", output_type=Outline,
                 system_prompt="Produce a 5-section outline.")
writer   = Agent("claude-opus-4-7", output_type=Draft,
                 system_prompt="Expand outline to 800 words.")
editor   = Agent("claude-opus-4-7", output_type=Draft,
                 system_prompt="Tighten prose; remove filler.")

async def chain(topic: str) -> Draft:
    outline = (await outliner.run(topic)).output
    if len(outline.sections) < 3:           # deterministic gate
        raise ValueError("outline too thin")
    draft   = (await writer.run(outline.model_dump_json())).output
    return  (await editor.run(draft.text)).output

Best fit: long-form content generation, code transformation pipelines, multi-step extraction. Avoid when the gate cost — running a classifier or schema check between calls — exceeds the cost of a single longer prompt; for very simple two-step tasks, prompt chaining is overengineering.

2. Routing

Routing classifies an input and dispatches it to one of several specialised downstream paths. The classifier can be an LLM, a small fine-tuned model, a rules engine, or a hybrid. Each downstream path is itself a workflow or a single LLM call — routing is the canonical way to combine a cheap general model with expensive specialists. Use it for customer-support triage (refund vs technical vs billing), model-tier routing (Haiku for simple queries, Opus for hard ones), language routing, and risk-band routing in compliance pipelines.

from typing import Literal, TypedDict
from langgraph.graph import StateGraph, END

class State(TypedDict):
    query: str
    route: Literal["billing", "tech", "refund"]
    answer: str

def classify(s: State) -> State:
    s["route"] = small_model.classify(s["query"])   # cheap classifier
    return s

def billing(s):  s["answer"] = haiku.run(s["query"]); return s
def tech(s):     s["answer"] = opus.run(s["query"]);  return s
def refund(s):   s["answer"] = handoff_human(s);      return s

g = StateGraph(State)
g.add_node("classify", classify)
g.add_node("billing", billing); g.add_node("tech", tech); g.add_node("refund", refund)
g.set_entry_point("classify")
g.add_conditional_edges("classify", lambda s: s["route"],
    {"billing": "billing", "tech": "tech", "refund": "refund"})
for n in ("billing", "tech", "refund"): g.add_edge(n, END)
app = g.compile()

Best fit: heterogenous input streams that benefit from specialisation, cost optimisation across model tiers, and any pipeline where input classes have meaningfully different SLAs. The watch-out is classifier drift — route distributions need monitoring, because a silent shift toward the expensive path is how routing pipelines blow their token budget.

3. Parallelisation

Parallelisation runs multiple LLM calls concurrently and aggregates the results. Two sub-flavours: sectioning — the task splits into independent subtasks (summarise each chapter in parallel, then merge); and voting — the same task is run N times with different prompts or temperatures and the answers are combined (majority vote, confidence-weighted, or LLM-judged). Voting is the cheapest reliability lever you have: three independent runs with majority vote often beats one run of a stronger model on safety-critical classification at lower latency.

import asyncio
from collections import Counter

async def vote(query: str, n: int = 3) -> str:
    prompts = [
        f"Classify strictly by policy. Input: {query}",
        f"You are a senior reviewer. Classify: {query}",
        f"Be conservative. Classify: {query}",
    ][:n]
    results = await asyncio.gather(*(llm.run(p) for p in prompts))
    return Counter(r.label for r in results).most_common(1)[0][0]

Best fit: content moderation, safety classification, fact-checking, code-review style tasks where catching false negatives is critical. The cost is N× tokens per decision — tune N based on the recall floor you need rather than chasing a round number.

4. Orchestrator-workers

Orchestrator-workers is the first pattern where the model dynamically decides what to do — the orchestrator is itself an agentic node. A central LLM reads the task, splits it into subtasks at runtime (not statically in code), delegates each subtask to a worker, and synthesises the worker outputs. The number and shape of the subtasks are unknown in advance. This is the pattern Anthropic uses internally for coordinated multi-file code edits, and it is the dominant production shape for research-style tasks where the task graph cannot be drawn ahead of time.

from langgraph.graph import StateGraph, END

def plan(state):
    state["tasks"] = orchestrator_llm.plan(state["goal"])  # list[Subtask]
    return state

def dispatch(state):
    results = []
    for t in state["tasks"]:
        results.append(worker_llm.run(t, tools=t.allowed_tools))
    state["results"] = results
    return state

def synthesise(state):
    state["final"] = orchestrator_llm.merge(state["goal"], state["results"])
    return state

g = StateGraph(dict)
g.add_node("plan", plan); g.add_node("dispatch", dispatch); g.add_node("synthesise", synthesise)
g.set_entry_point("plan")
g.add_edge("plan", "dispatch"); g.add_edge("dispatch", "synthesise"); g.add_edge("synthesise", END)

Best fit: code agents that touch multiple files, research agents that need to assemble information from many sources, document-processing pipelines where the structure of the work depends on the document. Watch-out: the orchestrator is the central point of failure — budget tokens for retries, log every plan it produces, and gate the plan size with a hard upper bound. This is also the pattern most often confused with multi-agent systems; see our Multi-Agent Systems Explained for the difference.

5. Evaluator-optimizer

Evaluator-optimizer separates generation from criticism. One LLM produces a draft. A second LLM — with a different prompt, often a different model — evaluates the draft against explicit criteria and either accepts or rejects it. On rejection the evaluator’s feedback flows back into the generator, which produces a revised draft. The loop terminates on accept or on max iterations. The pattern is the cheapest path to consistent quality on tasks where “good” is hard to specify but easy to recognise: literary translation, document writing, structured search, code review.

def evaluator_optimizer(prompt: str, max_iters: int = 4) -> str:
    draft, feedback = generator.run(prompt), ""
    for _ in range(max_iters):
        verdict = evaluator.judge(draft, criteria=CRITERIA)  # ACCEPT / REVISE
        if verdict.label == "ACCEPT":
            return draft
        feedback = verdict.feedback
        draft    = generator.run(prompt, prior=draft, feedback=feedback)
    return draft  # fallback after max_iters

Best fit: anything where you can write down evaluation criteria more easily than the answer. Watch-out: pick an evaluator model that is at least as capable as the generator for the criterion you care about — an evaluator weaker than the generator just adds latency without lifting quality.

When do you actually need an agent instead of a workflow?

The honest answer is: less often than the vendors imply. Reach for an agent only when at least one of the following is true.

• The task graph cannot be drawn ahead of time. If the steps required to solve the task depend on intermediate findings that you genuinely cannot enumerate, an orchestrator-workers shape or a full agent is the right call.
• The action space is open-ended. Free-form research, exploration of an unknown codebase, debugging an unfamiliar production incident — environments where the next useful tool is decided by what was just discovered.
• Latency budget tolerates iteration. Agents commonly take 30–120 seconds and many tool turns. If your product is a chatbot replying in 2 seconds, a workflow with cached intermediate results is the only viable shape.
• The cost of a wrong action is bounded. Agents make mistakes the developer did not anticipate. If a wrong tool call can move money, change production state, or send irreversible messages, you need a workflow with explicit human gates — or the OWASP LLM-08 (excessive agency) attack surface gets you.

The compound reliability math nobody warns you about

Single-step LLM reliability looks excellent in marketing decks. End-to-end agent reliability looks much worse, because errors compound multiplicatively across steps. If your per-step success probability is p and the task requires n independent steps, the end-to-end success probability is pⁿ. The table below makes the curve concrete.

Three operational consequences follow. First, a 95% per-step model is not enough for any agent over ~5 hops. Second, the cheapest reliability lift is usually fewer steps, not a smarter model — halving the number of LLM calls in a workflow tends to beat upgrading from Sonnet to Opus. Third, durable execution (a checkpointer that survives crashes, retries from the last good state, and lets a human resume a paused graph) is not a nice-to-have; it is the only way to push effective per-step reliability up to where the compound math works at 10+ steps. This is the technical reason every major orchestration framework — LangGraph, Microsoft Agent Framework, Pydantic AI, CrewAI — converged on durable execution as a first-class primitive between 2024 and 2026.

How EU AI Act Article 14 reshapes agentic workflow design

From 2 August 2026, the EU AI Act becomes fully applicable. Article 14 requires that high-risk AI systems be designed and developed in a way that allows them to be “effectively overseen by natural persons during the period in which the AI system is in use.” For agentic workflows operating in the EU — or for any workflow whose deployer is established in the EU — this is no longer a research topic. It is a shipping constraint.

In practice, four specific design choices satisfy Article 14 for agentic workflows, and each maps to a concrete graph primitive in modern frameworks.

• Explicit human-in-the-loop checkpoints at high-stakes nodes. Any node whose action is irreversible (payments, deletions, public messaging) pauses by default and resumes only after human approval. LangGraph’s interrupt() and Pydantic AI’s HumanApprovalRequired are direct implementations of this requirement.
• Stop and override controls. Operators must be able to halt or correct the system. In workflow terms this is the kill-switch edge that every node has access to and the rollback path the checkpointer enables. Microsoft Agent Framework’s pause / resume API is built specifically for this clause.
• Technical documentation of decision logic. Article 13 sits next to Article 14: deployers must be able to interpret the system’s output. A predefined graph is far easier to document than an open-ended agent trace — this is one of the strongest practical reasons workflows are winning regulated deployments.
• Logged and inspectable runs. Each node’s input, prompt, tool calls, output, and timing land in a durable trace. OpenTelemetry GenAI semantic conventions, finalised in 2025, are now the de-facto target schema; frameworks emit them natively.

The deeper consequence is architectural. An agentic workflow whose every state transition is named in code is, by construction, much closer to Article 14 compliance than an agent whose control flow lives in a model’s context window. EU enforcement in the second half of 2026 will surface this gap in publicised cases — the AI Act Service Desk has already been running pilot consultations since Q1 2026. Expect a new generation of “compliance-shaped” workflows in regulated finance and healthcare to dominate procurement RFPs by Q4 2026.

The 2026 production reference architecture for agentic workflows

Public production write-ups from Klarna, Uber, LinkedIn, and Anthropic itself, plus the architectural patterns crystallised in the arXiv December 2025 practical guide, converge on the same broad shape. The reference architecture has eight layers; almost every shipping agentic workflow in 2026 has all of them.

1. Trigger layer — HTTP, queue, scheduler, or event bus that initiates a run.
2. Orchestration framework — LangGraph, Microsoft Agent Framework, Pydantic AI, or CrewAI. Defines the graph, owns control flow.
3. Model layer — one or more LLMs accessed through vendor SDKs (Claude, OpenAI, Google). Usually mixed-tier: cheaper model for classification, frontier model for hard nodes.
4. Tool layer — MCP servers, retrieval, code execution, browser, internal APIs. Tool calls happen via the Model Context Protocol or vendor-native tool calling; both interoperate now that MCP is governed by the Linux Foundation.
5. Memory layer — short-term scratchpad inside the graph state, long-term vector store, episodic summary memory written by an evaluator node.
6. Durable execution & checkpointing — Postgres or Redis checkpointer that snapshots state after each node. The single most-leveraged primitive for both reliability and Article 14 compliance.
7. Human-in-the-loop edges — explicit interrupts at high-stakes nodes; resume tokens that survive sessions; reviewer dashboards that show the paused state and accept structured input back.
8. Observability & eval — OpenTelemetry GenAI traces, per-node assertions, regression evals on a golden set. Logfire (Pydantic), LangSmith (LangChain), and W&B Weave are the dominant 2026 stacks.

The combinatorics of picking a framework, a vendor SDK, and a deployment surface are the topic of our Best AI Agent Frameworks 2026; benchmark methodology and which leaderboards are credible are covered in AI Agent Benchmarks 2026.

Common failure patterns and how to avoid them

Across the public post-mortems of agentic systems published in 2025 and 2026, the same five failure shapes appear over and over. None of them are exotic. All of them are preventable.

• Step explosion. An orchestrator-workers run that plans 30+ subtasks burns through its token budget before producing anything useful. Cap the plan length in code — not in the prompt — and fail loudly when the cap is hit.
• Silent classifier drift. A routing pipeline starts sending 70% of traffic to the expensive path because the input distribution shifted. Monitor route distribution and alert on deviation from the historical baseline.
• Evaluator that is weaker than the generator. An evaluator-optimizer loop reinforces mediocrity if the judge cannot tell good from bad. Match evaluator capability to the criterion, not to the cost target.
• Tool-call shape leakage. The model invents tools that don’t exist or passes wrong-shaped arguments. Validate tool calls against typed schemas (Pydantic AI does this natively); reject and revise rather than silently failing.
• Missing human gate on irreversible actions. The agent sends a refund email or deletes a row before anyone approved it. Treat any irreversible action as a hard interrupt by default; require an explicit override to make it auto-resume. This is also the most common OWASP LLM-08 finding in 2026 third-party audits.

What changes for agentic workflows in the next 12 months

Three near-certainties for the rest of 2026 and into 2027, none of which require speculation about new model capabilities.

• Workflow shapes get serialised. Today every framework has its own graph syntax. By late 2026 expect a portable agentic-workflow schema (probably born inside the Linux Foundation’s Agentic AI Foundation) that lets you describe a graph once and run it on LangGraph, Microsoft Agent Framework, or Pydantic AI. The pressure is coming from EU procurement: a workflow that cannot be exported is a workflow that cannot be audited by a third party.
• Cost-aware routing becomes a standard primitive. Routing in 2024–25 was about specialisation; in 2026 it becomes about token economics. Frameworks will ship router nodes that take a budget per request and route to the cheapest model that meets the SLA, falling back to a stronger model only when the cheap one fails an explicit check.
• Article 14 compliance becomes a feature flag. Expect orchestration frameworks to ship “EU mode” toggles that enforce mandatory human-gate nodes, full OpenTelemetry GenAI trace emission, and stop-control guarantees out of the box. Vendors that ship this first will win regulated-finance and healthcare procurement through 2027.

None of these changes the May 2026 recommendation: design the simplest workflow that solves the problem, gate the irreversible nodes, instrument every edge, and only escalate to dynamic agent control where the workflow genuinely cannot express the task.

FAQ