If your inputs look the same every time and the rules are written down, use a deterministic automation. If the inputs vary, the rules live in someone's head or handling the exceptions is most of the work, use an AI agent. Most real workflows have both, and the build that fits them is an automation with an agent on the exception path.
The rest of this page shows how to tell which case you are in before you spend money on the wrong one.
Why the comparison is confusing
People use three terms as if they were interchangeable, and each one means something different.
Rule-based automation is software that follows a path you defined. A trigger fires, steps run in order, and the same input always produces the same output. Zapier, Make, Power Automate and the automation rules inside your CRM all work this way.
Robotic process automation (RPA) is one kind of rule-based automation. IBM describes it as rule-based software that combines APIs and user interface interactions to perform repetitive office tasks such as extracting data, filling in forms and moving files. What sets it apart is that it works through the front end, clicking and typing the way a person would, which lets it reach legacy systems that have no usable API. IBM states the difference plainly: RPA is process-driven where AI is data-driven, and "RPA bots can follow only the processes defined by an end user."
AI agents are a different kind of system. OpenAI's practical guide to building agents defines them as "systems that independently accomplish tasks on your behalf," and it explicitly excludes things people often mistake for agents: applications that use a language model without letting it control how the workflow runs, such as simple chatbots or classifiers. Anthropic draws the same boundary in Building effective agents, separating workflows, "where LLMs and tools are orchestrated through predefined code paths," from agents, "where LLMs dynamically direct their own processes and tool usage."
Without the marketing, the difference comes down to who decides the order of the steps. In an automation, you decide in advance. In an agent, the model decides as it works, inside limits you set.
The dividing line is the shape of the work
Vendors present this as a technology comparison because the newer technology wins that comparison. The workflow should decide the type of tool, and three properties of the workflow tell you which one fits. A fourth question sits before all of them, which is whether the work needs anything standing at all or whether the chat seats you already pay for would do; the handoff test for an AI assistant settles that in four lines.
The first is how much the inputs vary. A hundred invoices in the same template from the same supplier are uniform, while a hundred inbound emails from a hundred customers are not. Deterministic automation is built for uniform inputs.
The second is whether the rules are written down or live in someone's head. If you can hand a new hire a one-page document and they do the job correctly, the rules are explicit and a machine can follow them literally. If the honest instruction is "you will pick it up after a few months," the rules are tacit, and there is nothing to encode.
The third is whether exceptions are a nuisance or the job itself. Every process has exceptions; what matters is their share of the volume and how much judgment each one takes. When exceptions are two percent of cases and each one is obvious, route them to a person and automate the rest. When they are thirty percent and each needs context, the exceptions are the process.
OpenAI's guide reaches the same three signals from the engineering side. It prioritizes workflows with complex decision-making, difficult-to-maintain rules and heavy reliance on unstructured data, then adds a sentence most vendor content leaves out: "Before committing to building an agent, validate that your use case can meet these criteria clearly. Otherwise, a deterministic solution may suffice."
Anthropic goes further. It recommends finding the simplest solution possible and adding complexity only when needed, which "might mean not building agentic systems at all."
Two of the largest model providers are telling you not to buy an agent for work that does not need one. That advice is worth more than any vendor's comparison table, ours included.
Decision table
| Rule-based automation | RPA | AI agent | |
|---|---|---|---|
| Decides the sequence | You, in advance | You, in advance | The model, at run time, within your limits |
| Best input | Structured and uniform | Structured, reachable through a screen | Unstructured or variable |
| Rules must be | Written down | Written down | Describable in plain language |
| Typical failure | Stops and errors visibly | Breaks when the screen changes | Proceeds and is sometimes wrong |
| How you catch failure | Alert on the failed run | Alert on the failed run | Review of the output and the reasoning |
| Reaches legacy systems | Only with an API | Yes, through the interface | Through APIs and tools you approve |
| Handles a case nobody anticipated | No | No | Sometimes, and it should escalate |
| Cost per run | Lowest | Low | Higher |
| Maintenance lands on | Whoever wrote the rules | Whoever wrote the rules, on every UI change | Whoever operates the agent |
| Good sign you picked right | It has run unattended for months | It reaches a system with no API | Someone was reading and deciding, and now they review instead |
The routing test
Run this test on one workflow at a time rather than on your whole company.
- Write down the trigger and the finish line. If you cannot say where the work starts and what "done" looks like, you have several workflows rather than one, and the first job is to separate them.
- Look at the last twenty real cases rather than the ideal one. Count how many took the standard path and how many needed someone to think. If nineteen were standard, you are looking at an automation with an exception queue. If eight needed thinking, you are looking at agent work.
- Try to write the rules as a checklist. If the checklist covers the twenty cases, build the automation and stop reading. If it runs to forty branches and still misses cases, you have found what OpenAI calls difficult-to-maintain rules. That tells you to use an agent rather than write branch forty-one.
- Name what has to stay with a person. Anything that commits money, changes access, sends something a customer will treat as a promise or affects someone's employment stays behind human approval, whichever tool you pick. If that list covers the entire workflow, neither tool helps you yet. We wrote separately about what access an AI agent should have to your business systems and where those approval lines belong.
Where automation wins
An agent is the wrong purchase when the work is already deterministic. It costs more per run, runs slower and adds a failure mode the automation did not have.
That failure mode matters more than the cost. A rule-based automation that breaks usually stops and tells you. An agent that misreads a situation keeps going, produces a plausible output and gives no sign that anything went wrong. Anthropic describes the same tradeoff from the other side: autonomy brings higher costs and the potential for compounding errors, which is why it recommends extensive testing and guardrails. For a process where a wrong answer is expensive and hard to spot, a deterministic path with an auditable log is the better engineering choice, and you should not think of it as a legacy compromise.
Automation also wins in two other cases. When volume is high and the margin per run is thin, cost per run decides it. When you need to prove afterwards exactly why each case was handled the way it was, a fixed path gives you that record without extra work.
Where an agent is the only thing that works
An agent is worth its cost when the work cannot be reduced to a fixed path in advance.
The clearest signal is that a person currently reads something and makes a decision about it: what a customer email is about, whether a vendor response answers the question, whether a project update changes the plan. That is unstructured input plus judgment, the combination OpenAI names, and no amount of branching covers it.
The second signal is a ruleset that can no longer be maintained. Teams often turn to agents because the automation became too complicated to change, even though the work itself did not get harder. When updating one rule risks breaking three others, the rules are costing you more than they save.
The third signal is a process that spans systems that do not talk to each other, with a person retyping and reconciling data between them. Agents help there because they can carry context across steps instead of passing a fixed payload from one step to the next.
The build that fits most real workflows
Most workflows do not fall cleanly into either case. They have a large uniform middle and a variable tail, so the build that fits them has layers.
Automate the deterministic majority with the cheapest reliable mechanism you have, and put an agent on the exception path. The cases that would otherwise wait in a queue for a person get read, classified and researched there, then either resolved within approved limits or escalated with the context already assembled. Keep consequential actions behind a person.
Most teams arrive at this pattern eventually, usually after buying one tool for the whole job and finding that it fits half of it. Starting with the layered build saves you that cycle.
It also changes what you should ask a vendor. Every vendor now says yes to "do you use AI agents," so ask instead "which parts of my workflow are you proposing to make deterministic, which parts need judgement, and what happens on the cases neither of us has thought of yet." A vendor who gives the same answer for every workflow is selling you a type of tool rather than a solution to your problem.
What this means for scoping
Once you know the shape of the work, the scope gets concrete. Instead of buying "AI," you are naming a workflow, the systems it touches, its volume and exception rate, its owner and its approval line. Those inputs decide whether an implementation succeeds or stalls, and we cover them in detail in how to implement an AI agent in your business.
The remaining questions are who builds and operates it, which we work through in build your own AI agents or buy a managed service, and what the work costs, which we break down in how much AI agent development costs. If you are still deciding which part of the business to start with, AI agent use cases for business maps the common starting points.
Frequently asked questions
Is RPA the same as AI automation?
No. RPA is rule-based and process-driven. It follows only the steps a person defined for it and usually reaches systems through their user interface. "AI automation" is a loose marketing term that can mean anything from a model call inside a fixed workflow to a full agent, so ask a vendor which one they mean before you compare prices.
Is an AI agent just a smarter Zapier?
No. The difference is structural rather than a matter of intelligence. In a Zapier-style automation, the sequence is fixed and the tool runs it. In an agent, the model chooses the next action based on what it found in the previous one. That is the capability you are paying for, and it is also why an agent needs oversight that a fixed automation does not.
Can an AI agent replace our RPA bots?
Sometimes, but replacing RPA that works is rarely the best first move. RPA that runs reliably against a stable screen is cheap and auditable. It usually makes more sense to leave it in place and put an agent on the cases it drops, the ones that land in someone's inbox today because the bot could not handle them.
Our process already works. Do we need an agent at all?
Not if it works, runs unattended and nobody spends judgment on it. A useful test is how many hours a week a person spends reading, deciding and re-entering data. If the answer is close to zero, you do not need an agent.
How do we tell which one our workflow needs?
Run the four-question routing test above on one workflow. If the result is mixed, as it usually is, use the layered build rather than either tool on its own.
Decide the shape before you buy the tool
The most expensive mistake is choosing a technology before anyone has described the work precisely enough to tell which one applies. Uniform inputs and written rules point toward automation. Variable inputs and tacit judgment point toward an agent. Most workflows have both, which is a reason to design a layered build rather than a problem to solve.
If you want us to look at a specific workflow, that is what our discovery session is for. It starts with 30 minutes on your workflows, and if you do not need an agent, we will tell you.
