AI automation vs RPA vs AI agents: what's actually different?

Three buzzwords, used interchangeably by vendors who benefit from the confusion. Here's a clear, opinionated breakdown - and which one fits which problem.

The 30-second version

If you only remember one thing: the difference is who decides what happens next. Rules, a fixed pipeline, or the model itself.

RPA: scripts pretending to be humans

Robotic Process Automation is software that mimics human clicks and keystrokes. UiPath, Automation Anywhere, Blue Prism - the classic stack. It's deterministic. You record (or define) the steps, and the bot repeats them.

Where it shines: legacy systems with no API, high-volume back-office work, regulated environments where every step needs to be auditable.

Where it falls apart: the day the UI changes, the form gets a new field, or the input arrives in a slightly different format. RPA is brittle by design.

RPA is not AI. There's no model deciding anything. Vendors who bolted "AI" onto their RPA marketing in 2023 are mostly selling the same thing with a new sticker.

AI automation: the pragmatic middle ground

AI automation is what most companies actually need today: a defined workflow where one or more steps are powered by a model.

A concrete example. An inbound RFP email arrives. The workflow:

1. Classify - is this an RFP, a support request, or spam? (model call)

2. Extract - pull out company name, budget, deadline, requirements. (model call)

3. Match - does this fit our ICP? (model call, with structured output)

4. Route - assigned to the right account exec in HubSpot. (deterministic)

5. Draft - first-draft reply for the AE to review. (model call)

6. Notify - Slack message to the AE with summary and draft. (deterministic)

The shape of the workflow is fixed; the model handles only the parts that need reading, judgement, or generation. This is where the real ROI lives in 2026. It's reliable enough to ship, measurable enough to improve, and bounded enough to debug when it breaks.

AI agents: the model decides

An AI agent is given a goal and a set of tools, and it figures out the steps. "Research the top 5 competitors of [company] and produce a positioning brief" - and it browses the web, calls APIs, reads pages, takes notes, writes the brief.

The pitch: infinite flexibility. No more rigid workflows. The model adapts.

The reality, today:

• Agents work well in narrow, well-instrumented domains (coding assistants, deep research, sales prospecting) where the tools and feedback loops are tight.

• Outside those, they drift. They take the wrong action, loop, or quietly produce plausible-but-wrong output.

• They're harder to debug, harder to evaluate, and harder to make economically viable than a well-designed AI automation workflow.

This will change. The frontier is moving fast. But if you're choosing between "build an agent" and "build an AI-augmented workflow" for a business-critical process in 2026, the workflow wins on every dimension except marketing.

What each one actually costs to own

Licence price is the number vendors lead with and the least useful one. What separates a cheap automation from an expensive one is almost never the software.

The third row of that table is the one that surprises people. An AI automation workflow with six model calls costs roughly six model calls every time it runs, so you can forecast it. An agent decides for itself how much work to do, which means a task that normally takes twelve calls can take two hundred when it gets confused. Budget for agents on worst case, not average, or set a hard call ceiling and treat hitting it as a failure.

The other line worth planning for is maintenance. RPA breaks when a screen changes, which is annoying but obvious. Model-based systems degrade quietly: an upstream API adds a field, a supplier changes their invoice layout, and output quality slips a few percent without anything erroring. That is why the evaluation set below matters more than any feature.

"We already have RPA. Should we rip it out?"

Usually no, and the vendors pushing hardest on this have an obvious interest.

Working RPA that runs a stable, structured, high-volume process is doing its job. It is deterministic, auditable and cheap per run. Replacing it with a model introduces variability into a process whose whole value is that it never varies.

The case for change is narrower, and it is about exceptions. Most RPA implementations handle the happy path and dump everything else into a queue that a person works through by hand. That queue is where the cost actually sits.

So the productive question is not "RPA or AI". It is "what percentage of runs fall out of the happy path, and what does clearing that queue cost us?" If 5% of 10,000 monthly runs fall out and each takes six minutes to fix by hand, that is 500 exceptions and 50 hours a month. Adding a model that reads the exception, decides what the bot should have done, and hands it back is a far smaller and safer project than replacing the bot.

Keep the deterministic spine. Add judgement at the point where the spine currently gives up.

Which one should you actually use?

A simple decision tree:

• Is the workflow stable, structured, and high-volume - but no API exists? RPA.

• Does the workflow involve reading messy text, making judgement calls, or generating drafts - but the steps themselves are knowable? AI automation.

• Is the task genuinely open-ended ("research X", "investigate why Y") and are you willing to accept variable quality? AI agent.

Most companies overestimate how much of their work is in the third bucket and underestimate the second. Start with AI automation, ship something useful in weeks, and let the agent stuff wait until the tooling matures. Whichever bucket you pick, the workplace-AI obligations under the EU AI Act apply - Does the EU AI Act apply to ChatGPT in your office? is the fastest way to find out where your team stands.

Where the categories blur

Modern stacks mix all three. An AI automation workflow might call an agent for one step (e.g. "research this lead"). An RPA bot might invoke a model to handle an exception. The categories are useful for thinking, not for buying.

What matters when evaluating a vendor or a build:

• Can I see exactly what the model decided and why?

• Can I measure quality on a fixed evaluation set?

• When it breaks, can I fix it without a vendor in the loop?

If the answer to any of those is no, you're buying a black box. Don't.

How to test before you commit

Whatever you buy or build, the same evaluation gets you an honest answer in about a week.

1. Take 50 real historical cases, including the ugly ones. Not 50 clean examples chosen by whoever is selling.

2. Write down the right answer for each, by hand, before you see any output. This is the boring step everybody skips, and it is the only thing that makes the result trustworthy.

3. Run all 50 through the proposed solution.

4. Count three numbers: how many were right, how many were wrong, and how many were wrong without any signal that they were wrong.

That third number decides the architecture. A system that fails loudly can be put in production behind a queue. A system that fails silently cannot be trusted with anything that is not reviewed, no matter how good the headline accuracy is. A 95% accurate process that gives no indication which 5% it got wrong is often less useful than an 85% one that flags its own uncertainty.

Keep those 50 cases. When you change a prompt, a model or a vendor, rerun them. Without a fixed evaluation set you are not improving a system, you are changing it and hoping.

What this means under the EU AI Act

Since 2 August 2026 the general obligations apply, and they cut across all three categories, because the law does not care which architecture you chose. It cares what the system does and who it affects.

Two things catch most companies:

• Article 4, AI literacy. If your staff operate these systems, they need to understand what they are working with. This is not a training-certificate exercise, but it is a real obligation and it applies to the small workflow as much as the impressive one. See Article 4: what European SMEs actually need to do.

• Article 50, transparency. If the output of any of these reaches a customer directly, for example an agent that answers email or a chat layer on your site, the person on the other end must be able to know they are dealing with a machine.

There is a practical wrinkle here that maps onto the three categories. Deterministic RPA is easy to document because the steps are fixed and auditable. Agents are hard, because "what did it decide, and why" is exactly the question they are worst at answering. If you are in a regulated environment, that documentation burden is a real argument for the middle option, independent of quality.

Which obligations land on you also depends on whether you built the system, bought it, or both. See provider, deployer, or both, and the broader EU AI Act guides if compliance is the deciding factor rather than a footnote.

Next reads

• What is AI automation? An operator's guide - the pillar overview.

• Alternatives to big AI consulting firms - when a Big Four engagement is the wrong shape.

• Or book a 30-minute call and we'll tell you, honestly, which of these three your problem is.