The distinction that decides everything else
The phrase gets used loosely. Automation vendors call almost anything with a model in it an AI workflow, and plenty of people use it to mean the way they personally use a chat assistant at work. This page uses the narrower engineering meaning, because it is the one that changes what you build, what it costs and what can go wrong.
Anthropic's engineering team draws the line in one sentence each. 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." In a workflow, you decide the steps and the model does some of them. In an agent, the model decides the steps.
Take the enquiry form on a studio website. A workflow version receives the message and asks a model one narrow question: is this a new project, a support request or spam? Code sends each answer down its own branch. For new projects, the model drafts a reply, and that draft goes in front of a person before anything is sent. The model never chooses what happens next. It answers a question and hands the result back.
An agent version would be given the inbox, a calendar and a send button, and told to handle enquiries. It might do the same things in the same order. It might also book a call, reply twice or skip the draft entirely, and the only way to find out which is to watch it.
Most of what a small business wants from AI is the first shape. The second is useful for a narrower set of problems than its popularity suggests, and the rest of this page is about telling the two apart.
Why a fixed path usually wins
The two most useful pieces of published guidance on this come from companies that sell models, and both still steer you toward the simpler option. Anthropic's post says agentic systems "often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense," and that the autonomy of agents means "higher costs, and the potential for compounding errors." OpenAI's guide sets out when an agent is worth building and then adds: "Otherwise, a deterministic solution may suffice."
The practical reasons are less abstract than they sound.
- You can test it. Each model step has one input and one expected kind of output, so you can run it against real past cases before anyone relies on it. A step that sorts enquiries can be checked against last year's inbox. An agent takes a different route on each run, so there is no single step to test.
- You can predict what it costs. A workflow makes a known number of model calls per run. An agent decides how many calls it needs, and a confused one keeps trying.
- A mistake stays where it happened. If the sorting step gets one wrong, the message goes down the wrong branch and a person meets it there. In an agent, an early wrong turn becomes the premise for every step after it, which is what compounding errors means in practice.
- You can explain it. When a customer asks why they received a particular reply, a workflow has a path you can point at.
None of this makes a workflow automatically correct. The model step can still be wrong, and the next two sections are about containing that. What changes is that the wrongness has a boundary you drew yourself.
The five shapes most workflows take
Anthropic's post names five patterns. They are worth knowing by name, because nearly every AI workflow a small business asks for turns out to be one of them, or two chained together. The phrases describing when each one fits are quoted from the post. The examples are ours, written for this page, and they are illustrations rather than client work.
| Pattern | What it does | When it fits | An example |
|---|---|---|---|
| Prompt chaining | Runs a task as a fixed series of model calls, each one working on the previous one's output | "the task can be easily and cleanly decomposed into fixed subtasks" | Turn rough meeting notes into a structured brief, then turn the brief into a first draft of a proposal |
| Routing | Sorts an input into a category and sends each category to its own handling | "complex tasks where there are distinct categories that are better handled separately" | Sort incoming enquiries into new work, existing clients and spam |
| Parallelization | Runs several model calls at the same time and combines what they return | "when the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed" | Check one product description for tone, factual accuracy and missing details in three separate calls |
| Orchestrator-workers | One model call breaks a task into pieces and hands each piece to another call | "complex tasks where you can't predict the subtasks needed" | Update every page on a site that mentions a service which has just been renamed |
| Evaluator-optimizer | One call produces a draft and another judges it against criteria, in a loop | "when we have clear evaluation criteria, and when iterative refinement provides measurable value" | Draft a reply, check it against a list of things a reply must never promise, and redraft if it fails |
Orchestrator-workers is the pattern closest to an agent. Anthropic still files it under workflows, but it is the one where a model decides how the work is divided, so it inherits some of an agent's unpredictability. If a proposed workflow is mostly this pattern, test it the way you would test an agent.
Where a person has to approve
The damaging failure in AI automation is rarely a wrong answer on its own. It is a wrong answer that was allowed to do something. OWASP, which maintains the best-known list of security risks for applications built on language models, calls this excessive agency and traces it to three causes: "excessive functionality", "excessive permissions" and "excessive autonomy". Its recommended control is "human-in-the-loop control to require a human to approve high-impact actions before they are taken."
OpenAI's guide names two situations that should hand control to a person. The first is exceeding a failure threshold: a limit on retries or actions, after which the system stops and escalates. The second is high-risk actions, meaning those that are "sensitive, irreversible, or have high stakes", and its examples are cancelling orders, authorising large refunds and making payments.
This is easier to get right in a workflow than in an agent, because you know in advance which steps act on the world. So the rule can be built into the structure rather than left to vigilance.
- Steps that only read or draft need no approval. Sorting a message, summarising a document and writing a draft change nothing until another step uses the result.
- Steps that send, publish, pay, delete or change a customer's record get a person in front of them, at least until that step has a long record of being right.
- Every workflow needs a way out. When the model is unsure, returns something malformed or fails more than a set number of times, the item goes to a person's queue instead of being retried forever or quietly dropped.
- The approval has to be real. A button that a busy person clicks on every item without reading is a delay, not a control. If nobody has time to read the drafts, that step is not ready to be automated.
What each step can reach in the first place is a separate design decision, covered in our guide to what an AI feature needs besides a model. The short version is that a step should hold the one permission its job needs and nothing broader.
When an agent genuinely earns its place
OpenAI's guide is specific about where agents beat conventional automation, and its three criteria make a good test before building one. The work involves complex decision-making, with "nuanced judgment, exceptions, or context-sensitive decisions". Or the rules have become hard to maintain, in systems that are "unwieldy due to extensive and intricate rulesets". Or the task relies heavily on unstructured data, which it describes as "interpreting natural language, extracting meaning from documents, or interacting with users conversationally".
Read those closely and the third one describes most workflow model steps too, since reading an email is unstructured data. What usually pushes a task into agent territory is the first criterion combined with the condition Anthropic attaches to orchestrator-workers: you cannot predict the steps in advance. Working out why a delivery went missing across three different systems is like that. Sorting a contact form is not.
Two more conditions matter before handing a model the wheel. Anthropic says agents suit "scaling tasks in trusted environments", and a customer-facing inbox is not a trusted environment, because anyone can type anything into it. And someone has to be able to review what the agent did afterwards, which means logging every step it took rather than only the final result.
Building the first one
The first workflow worth building is almost never the most impressive one. It is a task someone already does by hand every week, with a clear input and a clear finished state, where the judgement involved is about language rather than money.
- Write the process down as a person does it today, one step per line. Most of those steps turn out to be ordinary code: fetch a record, check a field, add someone to a list. Mark only the steps that need reading or writing language. Those are the model steps.
- Collect real past cases before building anything: a few dozen emails, forms or documents that went through the process, with what a person decided for each. That is the test set, and without it there is no way to know whether a model step works.
- Build each model step to draft, not to act. Run it alongside the person for a while and compare its output with theirs. Where the two disagree, find out why before changing anything.
- Decide the failure path before the success path. Know what happens to an item when the model is unsure, times out or returns nothing usable. If the answer is that nobody knows, it is not ready.
- Log the input and output of every model step. Not to read every line, but so that when something does go wrong there is a record of what the model was given and what it said.
- Only then take the person out of the steps that have earned it, one step at a time.
Tools matter less than this order. The same workflow can run in a no-code automation product or in ordinary code, and the choice between them is mostly about who maintains it afterwards. What decides whether it works is whether the steps were written down, tested against real cases and given a place to fail.
What this does not cover
- The words are not standardised. Vendors use workflow and agent loosely and sometimes interchangeably. This page uses Anthropic's engineering definitions because they separate two things that behave differently, not because the industry has agreed on them.
- The examples in the patterns table were written for this page. They are illustrations, not client work and not measured results.
- It gives no costs. Model pricing moves often enough that a figure here would be wrong within months, and the difference that matters for this decision is structural: a known number of model calls against an unknown one.
- It does not compare models, vendors or automation products, and it recommends none of them.
- What a model is allowed to reach is covered only briefly here. The companion guide on what an AI feature needs besides a model goes further, and neither page replaces a proper review of what a specific system can touch.
Sources
- Building Effective AI Agents, including the definitions of workflows and agents and the five workflow patterns, Anthropic. Retrieved 17 September 2026.
- A practical guide to building agents, including when to build one and when to hand control to a person, OpenAI. Retrieved 17 September 2026.
- LLM06:2025 Excessive Agency, from the OWASP Top 10 for LLM applications, OWASP GenAI Security Project. Retrieved 17 September 2026.
Revisions
- 17 September 2026 First published.
This page is revised in place rather than replaced, so its address does not change.