AI agentic workflows: the 5 patterns, business examples and when to use each

"Agentic workflow" gets used for everything from a chatbot with a search button to a system that runs a business process end to end. That vagueness costs teams money: they build an autonomous agent where a three-step pipeline would have been faster, cheaper and easier to trust, or they bolt AI onto a process that a simple rule already handled.

This guide gives you a working definition, the five workflow patterns that most real systems are built from, a business example and a failure mode for each, a decision checklist, and a short Python example that combines two patterns. If you want the bigger picture of how agentic AI relates to chat-style AI, start with our agentic AI vs generative AI explainer. This piece goes one level deeper.

What are agentic workflows?

An agentic workflow is a process in which a language model works through a task in several steps, uses tools such as search, databases or APIs, and checks or revises its work along the way, instead of answering a prompt once. Atlassian sums up the loop as "observe, think, and act" (opens in a new tab).

Andrew Ng explained the idea with an analogy in The Batch (opens in a new tab) in March 2024. Using a model zero-shot is like asking someone to compose an essay from start to finish with no backspacing allowed. An agentic workflow lets the model plan an outline, decide which web searches it needs, write a draft, read it over for weak arguments and revise, much the way a person actually writes.

Two definitions you will see, and why they differ

Sources use the term at two different levels, which is the main reason articles on this topic contradict each other:

• The broad definition. IBM (opens in a new tab) defines agentic workflows as "AI-driven processes where autonomous AI agents make decisions, take actions and coordinate tasks with minimal human intervention." Here, any process run by agents counts.
• The engineering definition. Anthropic's Building effective agents (opens in a new tab) splits agentic systems in two. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths." Agents are systems where the model dynamically directs its own process and tool use. The LangGraph documentation (opens in a new tab) uses the same split.

The engineering split is the more useful one when you are building, because it answers the question that drives cost and risk: who decides the next step, your code or the model? The rest of this guide uses it.

Workflow vs agent: an autonomy ladder

It helps to think of autonomy as a ladder rather than a switch. Each rung hands the model more control, and each one costs more to run and to test.

Anthropic's advice is to find the simplest solution that works and add complexity only when it is needed, noting that for many applications, optimizing a single model call with retrieval and good examples is enough. Climb the ladder one rung at a time.

The 5 agentic workflow patterns, with business examples

Anthropic's guide names five patterns, and LangGraph's docs implement the same five, so they have become the common vocabulary. The examples below are illustrations of how each pattern maps onto ordinary business work, not case studies of specific companies.

1. Prompt chaining: fixed steps in sequence

How it works: the task is split into steps, and each model call works on the output of the one before. You can add a programmatic check, a gate, between steps to stop a bad output from flowing on.

• Use it when the task breaks cleanly into the same subtasks every time. LangGraph's docs describe it as suited to well-defined tasks that can be broken into smaller, verifiable steps.
• Business example: a product team turns release notes into a customer email. Step one extracts the changes customers will notice, a gate checks that every item links to a ticket, step two writes the email, step three translates it into the languages you support.
• Watch for: errors that carry forward. If step one misses a feature, every later step inherits the gap, so put the gate where mistakes are cheapest to catch.

2. Routing: classify, then send to the right path

How it works: a first call classifies the input, and code sends it to a specialized prompt, tool or model. Anthropic's examples include sending refund requests, technical questions and general questions down separate paths, and sending easy questions to cheaper models.

• Use it when inputs fall into distinct categories that are better handled separately.
• Business example: an accounts payable inbox. The router labels each message as invoice, payment query, vendor onboarding or other. Invoices go to an extraction step, payment queries go to a lookup in the finance system, and "other" goes straight to a person.
• Watch for: misroutes. Always include a fallback category that lands with a human, and log the router's choices so you can measure how often it is wrong. Routing easy cases to a cheaper model is also how teams cut inference costs with small language models.

3. Parallelization: split the work or vote

How it works: several calls run at once and code combines the results. There are two variants: sectioning, where independent subtasks run side by side, and voting, where the same task runs several times and you compare answers.

• Use it when subtasks are independent and speed matters, or when you want more confidence than one answer gives.
• Business example (sectioning): a legal operations team reviews an incoming contract. One call checks payment terms, one checks liability and indemnity, one checks data protection clauses, and the results merge into one summary for the lawyer.
• Business example (voting): a content team screens user posts. Three differently worded checks look for policy violations, and a post is flagged if any two agree.
• Watch for: cost. Every parallel branch is a full model call, so voting on every input multiplies your bill.

4. Orchestrator-workers: the model plans, workers execute

How it works: a central model reads the task, decides which subtasks are needed, hands them to worker calls and combines the results. The difference from parallelization is that the subtasks are not fixed in advance. The orchestrator chooses them for each input.

• Use it when you cannot predict the subtasks. Anthropic's examples are coding changes that touch several files and research that pulls from multiple sources.
• Business example: a sales team asks for a briefing before a meeting with a prospect. The orchestrator decides it needs the account's history from the CRM, recent support tickets and the company's latest public news, sends a worker for each, and writes a one-page brief.
• Watch for: plans that sprawl. Cap the number of workers and the total budget per request, and give workers narrow, read-only tools.

5. Evaluator-optimizer: draft, critique, revise

How it works: one call produces an output, another evaluates it against criteria and gives feedback, and the loop repeats until the output passes or you hit a limit. Andrew Ng calls the single-model version of this reflection.

• Use it when you have clear evaluation criteria and revision measurably improves the result. Anthropic's examples include literary translation and complex search.
• Business example: a support team drafts replies to complaints. The evaluator checks that the reply answers the actual question, makes no promise the policy does not allow and stays under a word limit. Failing drafts go back with the evaluator's reason.
• Watch for: endless loops and a too-lenient judge. Set a maximum number of rounds, escalate to a person when it is reached, and spot-check what the evaluator passes.

Andrew Ng's four agentic design patterns

You will also see a second list in many articles. In Agentic Design Patterns Part 1 (opens in a new tab), Ng grouped agentic techniques into four design patterns: reflection, tool use, planning and multi-agent collaboration. These are capabilities rather than workflow shapes, and they map onto the five patterns above:

Ng's case for these patterns rested on a striking result. On the HumanEval coding benchmark, he reported that GPT-3.5 answered 48.1% of problems correctly zero-shot and GPT-4 67.0%, while GPT-3.5 wrapped in an agent loop reached up to 95.1%. Treat the exact numbers as a 2024 snapshot with models that have since been replaced, but the lesson has held: how you structure the work can matter as much as which model you use.

How to choose the right agentic AI workflow

Work down this checklist and stop at the first rung that solves the problem:

1. Could a rule do it? If the input is structured and the decision is fixed, use ordinary automation. McKinsey's lessons from a year of agentic AI work warn that for low-variance, highly standardized work, agents built on nondeterministic models can add more complexity and uncertainty than value.
2. Is one good model call enough? Try a single, well-prompted call with the right context first. Our prompt engineering guide and the RAG guide cover how to give a model better instructions and data.
3. Are the steps always the same? Use prompt chaining, with gates between steps.
4. Do inputs fall into clear types? Add routing in front.
5. Are there independent parts, or do you need extra confidence? Use parallelization.
6. Is there a clear quality bar a reviewer could check? Add an evaluator-optimizer loop with a round limit.
7. Are the subtasks different every time? Use orchestrator-workers.
8. Is the number of steps genuinely unknowable, and can mistakes be contained? Only then build a full agent, which our guide on how to build an AI agent walks through.

An agentic workflow in about 50 lines of Python

You do not need a framework to build an agentic workflow. The example below combines routing and evaluator-optimizer for a support inbox: classify the email, draft a reply, check it against rules, revise up to three times, and hand anything unclear or still failing to a person. It uses only standard Python 3.9 or later. Replace the body of llm() with a call to your model provider's SDK.

# A routing workflow with an evaluator-optimizer step.
# Plain Python: plug any model into llm(). No framework needed.

MAX_ROUNDS = 3

def llm(prompt: str) -> str:
    """Replace with a call to your model provider's SDK."""
    raise NotImplementedError

def route(email: str) -> str:
    label = llm(
        "Classify this customer email as exactly one word: "
        "billing, technical or other.\n\n" + email
    ).strip().lower()
    return label if label in {"billing", "technical", "other"} else "other"

def draft_reply(email: str, category: str, feedback: str = "") -> str:
    prompt = f"Write a short, polite reply to this {category} email.\n\n{email}"
    if feedback:
        prompt += f"\n\nRevise to fix this feedback: {feedback}"
    return llm(prompt)

def evaluate(email: str, reply: str) -> str:
    return llm(
        "Check the reply against these rules: answers the question, "
        "promises no refund amounts, under 120 words. "
        "Reply PASS, or FAIL: <reason>.\n\n"
        f"Email: {email}\n\nReply: {reply}"
    ).strip()

def handle(email: str) -> dict:
    category = route(email)
    if category == "other":
        return {"category": category, "action": "send to human queue"}
    reply, feedback = "", ""
    for round_no in range(1, MAX_ROUNDS + 1):
        reply = draft_reply(email, category, feedback)
        verdict = evaluate(email, reply)
        if verdict.startswith("PASS"):
            return {"category": category, "reply": reply, "rounds": round_no}
        feedback = verdict.removeprefix("FAIL:").strip()
    return {"category": category, "action": "send to human queue",
            "last_draft": reply, "reason": feedback}

What makes it a workflow, not an agent

• Your code owns the path. The model makes judgments (a label, a verdict), but handle() decides what happens next.
• Every exit is defined. The function either returns an approved reply or hands off to a human. It cannot wander.
• The loop is bounded. MAX_ROUNDS caps cost and latency per email.
• Bad labels fail safe. Any label the router was not asked for becomes "other" and goes to a person.

How we tested it: we ran the control flow on Python 3.13 with a scripted stand-in for llm(), covering three cases: a billing email that passes on the second draft, an unexpected router label that falls back to the human queue, and a reply that fails all three rounds and is escalated with the evaluator's reason. All three behaved as described. Output quality with a live model will depend on the model and on your prompts, so test it on a sample of real emails before you trust it.

Guardrails every agentic workflow needs

Workflows are safer than open-ended agents, but once a step can act in another system, the security questions are the same. The OWASP Top 10 for LLM Applications (opens in a new tab) calls the core risk excessive agency: damaging actions taken in response to unexpected, ambiguous or manipulated model output. It traces this to excessive functionality, excessive permissions or excessive autonomy. In practice:

• Give each step only the tools it needs, and make those tools narrow. A step that reads a mailbox should not also be able to send or delete.
• Use least-privilege credentials, such as read-only database roles where nothing needs writing.
• Require human approval for high-impact actions like payments, refunds, deletions and external emails.
• Enforce permissions in the downstream system, not by trusting the model to behave.
• Log every step and its inputs and outputs. McKinsey's lesson here is to verify performance at each step of the workflow, not only the final outcome, so errors can be found and fixed early.

When your workflow needs to reach many internal systems, a standard connector layer such as the Model Context Protocol makes those tool connections easier to manage and audit.

Where agentic workflows are heading

Adoption forecasts are aggressive. In August 2025 Gartner predicted (opens in a new tab) that up to 40% of enterprise applications will include integrated task-specific agents by 2026, up from less than 5% in 2025, and that by 2027 one-third of agentic AI implementations will combine agents with different skills.

The teams doing the work urge caution alongside the optimism. McKinsey's six lessons from a year of agentic AI (opens in a new tab) put the workflow first, not the agent: value comes from redesigning the process, investing in evaluations and keeping people responsible for accuracy, compliance and edge cases. The pattern-by-pattern approach in this guide is a practical way to follow that advice.

The bottom line

AI agentic workflows are the practical middle ground between a single prompt and a fully autonomous agent. Learn the five patterns, map each part of your process to the simplest one that works, bound every loop, and keep a human on the high-impact steps. Reach for a full agent only when the path truly cannot be drawn in advance. For more guides on agents, models and tools, browse our AI guides.