AI Agentic Workflows: Design Patterns for Enterprise Teams

Most teams ask the wrong question first. They ask whether to go agentic, as if it were a single switch for the whole system. The useful question is narrower and you have to answer it process by process: which parts of this job get a fixed path, and which parts get to reason?

Get that split right and an agentic workflow is the most reliable thing you'll ship this year. Get it wrong in either direction and you either hard-code a process that needed judgment, or hand an open-ended model a job that had one correct sequence all along.

What Is an Agentic Workflow

An agentic workflow is a process where a language model makes some of the control decisions at runtime, rather than following a path you drew in advance.

The clearest definition of the boundary comes from Anthropic's engineering write-up on building effective agents. 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, maintaining control over how they accomplish tasks."

That is the whole distinction, and most real systems land somewhere between the two poles rather than at either end. What people call an agentic workflow is usually a structured process with reasoning at specific points. The model decides which branch to take, which tool to call, or whether the output is good enough to return. The surrounding sequence stays fixed.

Three properties separate this from ordinary automation:

• The path isn't fixed. The number of steps to a resolution isn't known when the conversation starts.
• Tool use is a decision, not a step. The model chooses whether to query the knowledge base, hit an API, or ask a clarifying question.
• Output can be judged before it ships. A second pass can evaluate the first, and loop.

Anything that has all three is agentic. Anything missing all three is a flowchart with a language model bolted on, which is fine, and often the right answer.

Agentic Workflows vs Traditional Workflows

A traditional workflow encodes the decisions at design time. You know the branches because you wrote them. An agentic workflow defers some of those decisions to runtime, which buys flexibility and costs you predictability.

The row that catches teams out is the failure mode. A deterministic flow fails loudly, in a place you can find. An agentic one fails quietly and fluently, which is why observability stops being optional the moment you let a model choose its own steps.

Anthropic's own guidance is worth repeating here, because it runs against the marketing in this category: start simple, and add complexity only when the simpler version demonstrably underperforms. A single well-prompted call with good retrieval beats a five-agent architecture more often than anyone selling five-agent architectures will tell you.

The Five Agentic Workflow Patterns

Almost everything shipped in production is one of five patterns, or a composition of them. Learning them by name is the fastest way to stop designing from scratch.

1. Prompt chaining. Each call handles the output of the last. Draft, then critique, then rewrite. Use it when the task decomposes cleanly into fixed stages and you want to check the work between them. The steps are fixed; only the content varies.

2. Routing. Classify the input, then send it to a specialist downstream. A support agent that reads a message and decides whether it's a billing question, a technical fault, or a cancellation is routing. This is the single highest-value pattern in customer experience, because it lets you keep specialised, tightly-scoped handlers instead of one prompt that tries to be good at everything.

3. Parallelization. Run several calls at once, either by splitting the work into sections or by asking the same question several times and voting on the answer. Sectioning is for speed. Voting is for confidence on a call you can't afford to get wrong.

4. Orchestrator-workers. A central model breaks the job into subtasks it didn't know about in advance, delegates them, and assembles the results. Reach for this when the decomposition genuinely can't be written down ahead of time. If you can write it down, use prompt chaining, which is cheaper and easier to debug.

5. Evaluator-optimizer. One call produces, a second critiques against explicit criteria, and the loop repeats until the critique passes or you hit a cap. Always set the cap. This pattern is where runaway costs live.

Patterns 1 through 3 are workflows in the strict sense: the code path is predefined, and the model fills in the reasoning. Patterns 4 and 5 hand real control to the model. Knowing which side of that line you're on tells you how much evaluation and monitoring the thing needs before it touches customers.

Prompt quality matters more in the routing and evaluator patterns than anywhere else, because in both cases the model's output is a decision rather than a sentence. A vague router description produces confidently mis-routed conversations, and no amount of downstream quality recovers a conversation that went to the wrong handler. Treat those prompts as interface contracts and write them with the same care, using the practices in our guide to prompt engineering.

Single-Agent vs Multi-Agent Architectures

A single agent handles the whole job with one set of instructions and one toolset. It's simpler to build, simpler to debug, and it's where you should start.

Multi-agent architectures split the work across specialists that hand off to each other. They earn their complexity when the sub-jobs need genuinely different tools, different models, or different guardrails. A billing specialist that can issue refunds shouldn't share a toolset with a general FAQ handler, and separating them is a security decision as much as a design one.

The anti-pattern is fan-out for its own sake. Splitting one coherent job across five agents multiplies the places where context can be dropped. Every handoff is a chance to lose the thread of what the customer actually said. If you can't name what each agent knows that the others don't, you have one agent wearing five hats.

Once you have more than one specialist, the composition of the team becomes its own design problem, which we cover in building an AI agent team for customer service. The same reasoning applies when you narrow an agent to a single domain, the approach behind vertical AI agents.

How To Decide: Workflow or Agent

Run each process through these four questions before you build anything.

Can you write down every step? If yes, build a deterministic workflow. Payment collection, identity verification, and compliance disclosures have exactly one correct sequence, and a model that improvises inside them is a liability rather than a feature.

Does the number of steps depend on what the user says? If yes, you need reasoning. Troubleshooting is the clearest case: the third question depends entirely on the answer to the second.

What happens when it's wrong? Wrong answers that cost money, leak data, or create a regulatory obligation belong on fixed paths, with the model advising rather than acting. Wrong answers that cost a follow-up question can be left to reason.

Can you tell whether it worked? If you can't measure the outcome, you can't safely give the model control, because you won't find out it drifted. Get the measurement in place first. Our breakdown of what ticket deflection rate actually means is a good illustration of how easy it is to measure the wrong thing here.

Most real processes split. Triage is agentic, the refund is a fixed path, and the handoff between them is where the design work lives. Planning that boundary deliberately is most of the job, and it's the part teams skip.

What This Looks Like in Voiceflow

Voiceflow builds the distinction into the product rather than leaving it to prompt discipline, which means the architectural choice above maps onto two concrete primitives.

Workflows are deterministic directed graphs of nodes and edges. You author the sequence, and it executes in that order. Node types cover the usual work: ask a question, branch on a choice, set a variable, call an API, call a function, query the knowledge base, transition, end. This is the primitive for payment collection, KYC, appointment booking, and anything with a compliance obligation attached.

Playbooks are LLM-driven sub-agents, each with their own instructions, tools, and model. The agent routes to a playbook based on its description, and the playbook reasons toward a goal rather than following a path. This is the primitive for triage, qualification, and open-ended troubleshooting.

The part that matters architecturally is that the two mix. A playbook can hand control to a workflow through an auto-injected transfer tool, and the transition preserves session variables and conversation history. So a customer can be triaged by a reasoning agent, dropped into a deterministic refund flow once the intent is clear, then returned to the agent. The conversation keeps its state at both boundaries. That is the workflow-or-agent decision made per-step instead of per-system.

Three constraints worth designing around from the start:

• Keep workflows shallow. Past about ten nodes, split into sub-workflows. Past twenty, it stops being maintainable by anyone who didn't write it.
• Always set the default branch on a choice node. Unmatched input with no default leaves the session stuck. It's the most common way a deterministic flow strands a customer.
• Declare all three API branches. Success, error, and timeout. The timeout branch is the one everyone forgets and the one that fires during an incident.

Choosing between build approaches more broadly? Our comparison of AI agent frameworks covers the code-first options, and what an AI agent framework is covers the underlying concepts. Model choice is a separate decision from architecture, and one worth keeping open, as we argue in which platforms let you choose your own LLM.

Agentic Workflows in Customer Support

Customer support is where most enterprises meet this technology first, because the volume is high, the tasks are repetitive, and the outcome is measurable.

Gartner predicts that agentic AI will autonomously resolve 80% of common customer service issues without human intervention by 2029, and that this will produce a 30% reduction in operational costs. That's a forecast rather than a measured result, and it's worth reading it as one. It tells you where a large analyst house expects the category to land, not what your deployment will do next quarter.

For something closer to an instrumented number, the useful examples come from operations rather than conversation. DISH generates over two petabytes of data a day. Quoted in ServiceNow's October 2024 announcement of Workflow Data Fabric, it reported a "97% improvement in our mean time to repair vs our legacy processes" after using Stream Connect to ingest that data in real time. The stakes are in the same quote: telecom outages "can cost around $6,000 per minute." Mean time to repair is genuinely instrumented, which is why that figure is worth more than most of the percentages in this category.

Note what it actually demonstrates, though. That result came from unifying data so the right information reached the right workflow, not from autonomy. It's a useful reminder that the hard part of an agentic workflow is usually the plumbing underneath it. An agent reasoning beautifully over stale or partial data produces confident, well-written wrong answers, and the reasoning layer is rarely the bottleneck.

The support patterns that hold up in production are unglamorous. Route the conversation to the right specialist, resolve what's genuinely self-serviceable, and hand off to a human cleanly, with full context, when it isn't. Broader deployment patterns are covered in our guide to implementing AI across an enterprise. The range of jobs teams point these systems at is catalogued in AI agent use cases.

Before You Put One in Front of Customers

Four things need to exist before an agentic workflow touches a real customer, and none of them are the agent.

A measurement baseline. You cannot detect drift against a number you never took. Capture current resolution rate, handle time, and escalation rate first.

A staged path to production. Changes to a reasoning system need somewhere to prove themselves before they meet live traffic, which is the argument for environments.

Trace-level visibility. When an agent takes a strange path, you need to see which tools it called and in what order. Aggregate dashboards won't tell you.

A governance boundary. Decide up front which actions the model may take and which require a deterministic path or a human. Write it down. The security and compliance guide covers what that boundary needs to include for enterprise deployment.

Teams that put these in first ship slower for a fortnight and then keep shipping. Teams that skip them ship quickly once, hit an incident nobody can explain, and spend the next quarter rebuilding trust rather than features.

Where To Start

Pick one process. Map the steps you can name and the decisions you can't. Everything you can name becomes a workflow, everything you can't becomes a reasoning step, and the boundary between them is your architecture.

Then build the smallest version that resolves one real case end to end. You'll learn more from a narrow agent handling one intent against live traffic than from a multi-agent design document, and the parts that need to reason will announce themselves. For a fuller walkthrough of that first build, how to build AI agents covers the mechanics. Training an agent on your own knowledge covers the retrieval side, which most first attempts underestimate.