RPA vs. AI Agents: Which One Fits Which Work, With the Numbers

RPA did not become obsolete. Its territory got redrawn, which is a different thing and has a different answer.

Strip the vendor language and both machines are simple. RPA is a script that clicks buttons a person would click, in a fixed order, across screens that must not change. An AI agent reads whatever arrives, works out what it means, and either acts or hands the call to a human with context attached. Neither is a version of the other. A car is not a fast horse.

The mistake people make is treating this as a timeline instead of a fit question. Newer therefore better, so rip out the old thing. That framing has already cost companies real money in both directions: teams tearing out working bots to look modern, and teams pointing scripts at inboxes full of free text and then hiring two people to clear the exception queue the script generates. Both are the same error wearing different clothes. Somebody matched the machine to the calendar instead of to the work.

The honest version of the question is narrower and much easier to answer. What does your input look like when it arrives, how often does the same thing happen, and what does a wrong answer cost you? Answer those three and the choice is usually already made.

We build AI agents for a living, so read this part closely. There is a large class of work where a scripted bot beats us, and it is not some narrow edge case we are being gracious about.

Determinism is the whole argument. A script given the same input produces the same output on run one and run ten thousand. Not usually. Always. When a process is genuinely rule-bound, that property is worth more than intelligence, because intelligence is not what the job needs. Copying fields into a legacy ERP that has no API. Nightly batch reconciliation. Re-keying orders between two platforms that will never speak to each other. Each of those has exactly one correct output per input, and a script hits it every time for the cost of the license.

Auditability follows from the same property. In a regulated process where somebody has to show which rule produced which action, a script is its own documentation. You can read it. An agent's reasoning is reconstructable but not the same artifact, and if your compliance officer needs a rule they can point at, that difference matters more than any capability we can add.

And then there is the plain case of the mature program. If you already run governed RPA with a team that maintains it, ripping it out to feel current is money spent on a problem you did not have. Keep the bots. Point agents at the work the bots were never able to touch, which is almost certainly sitting in an exception queue somewhere in your building right now.

Here is where the conventional wisdom breaks, and it surprised us too. The usual claim is that RPA is the cheap option and agents are the expensive one. At the volumes most companies actually run, that is backwards.

The two cost shapes are completely different. An RPA bot costs a fixed amount whether it runs once or a million times. Microsoft publishes the number: Power Automate Process is $150 per bot per month for unattended runs, and $215 if Microsoft hosts the machine. That is your bill regardless of throughput. Most of the category will not tell you even that much. UiPath publishes $25 a month for its Basic tier and puts contact sales next to everything an enterprise would actually buy, which is worth noticing on its own. An agent costs per token, so its bill is a straight line through the origin and never amortizes. Anthropic publishes those numbers too: Claude Haiku 4.5 runs $1 per million input tokens and $5 per million output.

Do the division. A document-reading call of roughly 3,000 input and 500 output tokens costs about half a cent, every single time. The $150 bot costs 15 cents per run at 1,000 runs a month, and about a tenth of a cent per run at 100,000. The two lines cross somewhere near 27,000 runs a month. Below that the agent is cheaper per item. Above it the license pulls away and keeps going.

So the cost case for RPA is a high-volume case, not a general one. And it is softer than even that suggests, because the license was never the real bill. Forrester's Craig Le Clair put it at $3.41 of services for every $1 of RPA software back in 2019, which means the sticker price is under a quarter of what the program actually costs. Price the whole workflow, humans included, before you compare anything.

The argument for RPA is determinism. It was always determinism. The cost story is a nice-to-have that only shows up at scale.

The moment work arrives as language, a script is not degraded. It is out.

A bot cannot read a customer email. It cannot pull a total off an invoice layout it has never seen. It cannot tell whether a complaint is a refund request or a churn risk about to become a LinkedIn post. What it does instead is route the item to a human, and that is what an exception queue is: a list of everything the script gave up on. In plenty of businesses the exceptions are not the residue of the job. They are the job.

Agents are built for exactly that input. They read the email, extract the fields off the PDF, draft the reply, score the lead. And when the call is genuinely ambiguous, a well-built agent does the one thing no script can do, which is escalate on purpose with the reasoning attached. Judgment with escalation is the pattern that matters, and it is a design decision rather than a feature you switch on. The agent clears the routine ninety and hands the weird ten to a person who now has context instead of a raw ticket.

That failure behavior costs real money to build. What it buys is coverage over work no structured tool could reach: email triage, invoice processing, quoting from a half-formed request, support replies that sound like your company rather than a form letter.

None of that requires the agent to be clever. It requires it to handle input that has no schema, which is a different skill entirely, and the only one a script cannot fake.

Every article on this topic says agents are probabilistic and scripts are deterministic, then moves on as though that settles something. It does not. Probabilistic how, and by how much?

The answer exists and it is uncomfortable. The tau-bench paper from Shunyu Yao and colleagues in 2024 measured agents on realistic customer-service tasks and reported something more useful than an average. It ran each task eight times. A leading function-calling agent scored under 50% on a single attempt in the retail domain, and under 25% when the same task had to succeed on all eight runs. Getting it right once is a very different thing from getting it right every time, and the gap between those two numbers is the honest definition of probabilistic.

That gap is exactly what determinism buys you and exactly what you are giving up. A script does not have a pass-once number and a pass-eight number, because they are the same number.

The same year, the OSWorld benchmark from Tianbao Xie and colleagues set 369 real computer tasks in front of agents and humans. Humans finished 72.4% of them. The best model managed 12.2%, and the paper named GUI grounding as one of the two things it kept failing at. GUI grounding is the entire job description of an RPA bot, which is worth sitting with for a second.

Now the honest update, because a stale number is worse than none: the OSWorld leaderboard has moved a great deal since that paper, and the top entries have since passed the human baseline. The capability curve is steep. What has not moved nearly as fast is run-to-run consistency on the same task, and consistency is the property your finance team is actually buying when they buy a bot.

A comparison where only one column has problems is marketing. Here are both columns.

The agent side first. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, blaming escalating costs, unclear business value and inadequate risk controls. The same release named the reason the market feels frothier than it is: agent washing, meaning existing chatbots and RPA products relabeled as agents. Gartner reckoned roughly 130 of the thousands of agentic vendors were the real thing. If you are being pitched an agent this quarter, those odds are your starting prior.

The RPA side is no cleaner, and it has had longer to prove itself. In that same 2019 Forrester research, only 13% of enterprises had more than 100 bots in production and most had fewer than ten. Bots in production were running about 15% of the time. Deloitte's 2022 intelligent automation survey, 479 executives across 35 countries, found 74% of them implementing RPA, but named process fragmentation as the top barrier to scaling for the fourth survey running. More than half had never calculated the cost reduction they got. Around 70% had never calculated the revenue increase.

Read those two paragraphs next to each other and the pattern is the same on both sides. Neither technology fails because the technology is bad. Both fail when somebody buys a mechanism before understanding the shape of the work, which is the entire reason this comparison is worth writing down. It is also worth knowing how few companies have actually got either into production before the next pitch lands.

Stop reading vendor pages and go pull the last twenty real instances of the workflow you want to automate. Print them if you have to. Then ask four questions in order.

First, do the twenty look identical? Same fields in the same places, same screens, same steps. If yes, script it, and you are done. If each one has to be read before anyone knows what to do with it, no script will hold and you need something that can read.

Second, how many of the twenty needed a human to decide something rather than just to type? One or two is a rules process with some noise, and the noise can stay human. Six or seven was never a rules process, whatever the flowchart on the wall says.

Third, how often do the underlying screens change? A vendor portal that redesigns twice a year will break a selector-based bot twice a year, and each break costs a developer's week. That is a maintenance line item you should write down before you sign anything.

Fourth, what does a confident wrong answer cost? This is the one people skip and it decides more than the other three combined. If a wrong output posts to a ledger or goes out to a customer under your name, you want determinism, or you want an agent with a review checkpoint you have actually designed and staffed. If a wrong output means a draft email someone deletes, you can move much faster.

Most workflows split rather than resolve. The front half arrives as language and the back half is rules, and the answer is one of each.

A useful hybrid pattern is not either column. An agent sits at the front where the mess arrives, reads it, and turns it into structured data. Deterministic steps carry it the rest of the way. Anything genuinely ambiguous gets escalated with the reasoning attached, not dumped in a queue.

Concretely, in accounts payable: the agent reads whatever landed in the inbox, whether that is a PDF, a photographed receipt or three lines of email, and produces clean fields. From there a bot or an API call posts to the ERP exactly the way it always did. The bot stops seeing input it cannot parse, so its exception rate collapses. Your existing RPA investment gets more valuable, not less, because it finally gets fed properly.

That is a version worth evaluating before anyone replaces a working bot. Replacing deterministic automation with a probabilistic system is a downgrade with a modern paint job. Putting an agent in front of it is an upgrade, and it costs less than the rip-and-replace does.

Most automation service providers will quote you the rebuild, because the rebuild is the bigger invoice. Ask for the boundary instead, and ask them to defend where they put it.

This was never agents against scripts all the way down. It is judgment where judgment is needed, and rails everywhere else. Pick the boundary deliberately and both machines earn their keep.

AgentClaw's current audience is a non-software company where no employee writes software, firmware, or embedded code. Such a company can compare RPA, an AI agent, or no automation, but implementation must be externally delivered and governed by named internal process and risk owners. The comparison does not imply that an agent is the preferred answer.