The Agent Tax: Why Replacing Your RPA Bots with AI Agents Could Blow Up Your Automation Budget

Replacing a deterministic RPA bot with an AI agent converts a fixed automation cost into a variable one that scales with transaction volume. The per-task inference price is the smallest line in that bill. Retries, evaluation, human review and reconciliation of plausible-but-wrong actions are the rest, and most migration business cases omit all four.

The pitch has become difficult to avoid. Your robotic process automation estate is brittle. Bots break when a supplier changes a screen, the exception queue never empties, and every new process needs a developer. Agents, the argument goes, adapt where bots shatter. So replace them.

Some of that critique is fair, and this article will make the case for it rather than against it. What the pitch leaves out is what happens to the shape of the bill. Gartner's June 2025 forecast put more than 40% of agentic AI projects on course to be cancelled by the end of 2027, and the first reason it named was escalating costs — ahead of unclear business value and inadequate risk controls.

That ordering is worth sitting with. These programmes are not mostly failing because the technology cannot do the work. They are failing because somebody signed off a number that turned out to describe a different cost structure entirely.

#What the Agent Tax Actually Is

The phrase gets used loosely to mean nothing more than "AI is expensive". That is not a useful claim, and as stated it is becoming less true every quarter.

The precise version is narrower. The agent tax is the cost of supervising a non-deterministic process in a place where a deterministic one used to run. An RPA bot given the same input produces the same output, every time, and when it cannot, it stops. That property is the reason the automation was cheap to operate: it needed no judgement in the loop, no sampling, no second opinion.

An agentic system gives that property up deliberately, in exchange for handling inputs the bot could not. Everything you now have to build to compensate — the retry logic, the evaluation harness, the review step, the detection of wrong-but-plausible output — is the tax. It is not a penalty for choosing badly. It is the running cost of the flexibility you bought, and it belongs in the business case at the point of purchase.

#Fixed Cost Becomes Variable Cost

What this means for you: the automations with the strongest RPA business case are usually the weakest agent candidates, and the reason is arithmetic rather than judgement.

An RPA bot's cost is dominated by things you pay once or pay annually: the licence, the build, and the maintenance when something upstream changes. Run it ten thousand times or ten million and the compute barely registers. Cost therefore scales with the number of processes you automate, which is why RPA programmes are usually budgeted per process.

An agent inverts this. The build is often cheaper — that is a genuine advantage and part of why the pitch lands. But every execution calls a model, and a proportion of executions call it more than once. Cost now scales with volume, and volume is the axis your highest-value automations are furthest along.

The bots with the strongest business case are the worst agent candidates, for precisely the reason that made them strong.

This is why the migration conversation so often starts in the wrong place. The natural instinct is to pick the biggest, most painful, highest-volume process and move it first, because that is where the value is. On an agent cost curve, that is the process where the bill grows fastest and where determinism was worth the most.

#The Four Line Items Nobody Budgets

What this means for you: the quoted price per call is real, and it is usually the smallest of the five numbers that make up your actual run cost.

The first two are measurable before you commit, and almost nobody measures them. The retry multiplier in particular is treated as a rounding error when it is a direct multiplier on the largest variable cost you have.

The scale of that multiplier is easy to underestimate from a demo. The Carnegie Mellon and Salesforce study published in 2025, which ran leading models through simulated multi-step office work, found the best performers completing roughly 30–35% of multi-step tasks, with accuracy on simple single-step tasks sitting far higher than on chained ones. Enterprise agents on narrow, well-instrumented processes do considerably better than an open-ended benchmark. The point is not the specific figure; it is that the multiplier is not one, and that it compounds with every step you chain.

The fourth line is where the comparison stops being about technology at all. It is the same question as who signs off before an agent acts: once software can commit the organisation to something, somebody owns the consequence, and owning a consequence has a running cost.

#Where the Crossover Actually Sits

What this means for you: the crossover is computable with numbers you already hold, and we are deliberately not going to print a price per task for you to copy.

Any figure we published here would be stale within a quarter and wrong for your estate in ways we cannot see. What does not go stale is the shape, so here is the shape with the variables named. Fill them from your own contracts and your own logs.

Your bot's annual cost is roughly its licence, plus its build amortised over the years you will run it, plus the maintenance it actually consumes — that last term being the one nobody tracks honestly, because it arrives as fragments of developer time rather than as an invoice.

Your agent's annual cost is transaction volume, multiplied by the cost of one successful path, multiplied by the retry multiplier, plus the evaluation harness, plus the reviewer's time. Two of those five terms scale with volume and three do not, which is the whole argument in one sentence.

Two things fall out of this that are worth stating plainly. Low volume and high variability is where agents are straightforwardly the better economic answer. High volume and stable paths is where a bot that already works is very hard to beat, and where the conversation should probably be about fixing the bot's maintenance burden instead.

#The Bot You Are Replacing Was Not Free Either

What this means for you: if the migration case compares an agent's projected cost to the bot's licence line, it is comparing against a number that was never the real cost.

Everything above could be read as a defence of the existing estate. It is not, and the data does not support one. Deloitte's 2022 intelligent automation survey, covering 479 executives across 35 countries, found only 13% of organisations running 51 or more automations — the band it classes as genuinely scaling — against 37% still piloting with ten or fewer. Most RPA estates never reached the scale their own business cases assumed.

The reason is usually maintenance. Bots couple tightly to interfaces they do not control, so every supplier release, every screen change and every field rename lands as unplanned work. That cost is real and it is chronically under-recorded, because it arrives as a developer's afternoon rather than as a line item.

You are not choosing between a cheap option and an expensive one. You are choosing which tax to pay, and on which axis it grows.

So both sides of the comparison get mispriced, in opposite directions and for the same underlying reason: the costs that are easy to see are the ones that go into the model. The bot's maintenance disappears because it is diffuse. The agent's supervision disappears because it has not happened yet.

#When Replacing the Bot Is the Right Call

There is a class of process where the agent wins on cost, not just on capability, and it is recognisable from the outside.

It is the process whose exception queue is the process. Where the happy path was automated years ago and the remaining work is the twenty per cent the bot was never able to do — the unstructured email, the supplier who sends a PDF in a different layout every month, the claim that needs three systems read and a judgement made. That work is currently being done by people, at people prices, and it is genuinely variable in a way a deterministic bot cannot absorb.

On that shape, every term flips. Volume is modest, so the variable cost stays small. Variability is high, so the flexibility is worth paying for. And the comparison is not agent-versus-bot at all — it is agent-versus-headcount, which is a completely different and usually much more favourable sum.

The pattern to avoid is the one that makes the decision look tidy: retire the bot, move the whole process, report a single migration. It converts the cheap, stable, high-volume part of the workload onto the expensive cost curve in order to get the exception handling, when both could have run side by side.

#What to Do Before the Business Case Goes In

What this means for you: five pieces of arithmetic, none of which need a pilot, and all of which are cheaper to do now than to discover in month eight.

First, price the bot properly. Not its licence — its licence plus the developer hours it consumed last year. If nobody logged those hours, that absence is itself a finding, and it is the number the whole comparison turns on.

Second, measure the retry multiplier on real data, not on the curated sample from the vendor session. Take a few hundred genuine historical transactions, including the awkward ones, and record how often the path completes without intervention.

Third, put evaluation in the capital cost, not the run cost. An eval harness is not overhead to be trimmed; it is the only instrument that will tell you whether the thing still works after the next model version lands, and it is the same harness the production agentic patterns depend on.

Fourth, name the reviewer and cost their time. "Human in the loop" with no name attached is not a control, and at scale it is the line that quietly consumes the saving the migration promised.

Fifth, decide the reversal cost per class of action before anything is wired to a system of record. An action you can undo cheaply and one you cannot are different risks wearing the same interface, and they justify different amounts of supervision spend.

None of this is operating-model change yet, and none of it requires committing to a direction. It requires that both columns of the comparison be filled in honestly, which is the part that usually does not happen — and it sits naturally alongside the wider AI readiness questions rather than after them. If the estate work underneath is unfinished, our agentic AI practice will usually say so before it says anything about agents; the readiness framework sets out what has to be true first, and what to automate and what to keep under review covers the same judgement inside data operations. The same discipline that makes platform FinOps work applies here: a cost you cannot attribute is a cost you cannot govern.

#Frequently Asked Questions

#Is an AI agent always more expensive to run than an RPA bot?

No. On low-volume work with variable inputs, an agent is frequently cheaper, because the alternative is a person rather than a bot. The comparison inverts at high volume on stable paths, where a deterministic automation's negligible marginal cost per execution is very difficult to beat. Volume and variability, not the technology, decide which side you are on.

#How do we estimate the retry multiplier before building anything?

Take several hundred real historical transactions, including the awkward ones your current exception queue collects, and run them through a narrow prototype. Record how often the path completes without human intervention. That ratio, not the vendor demonstration, is what multiplies your per-execution cost across every future transaction, so it is worth measuring properly.

#Should we keep RPA bots we have already built?

Usually yes, where they still run. A working bot on a stable, high-volume process is an asset with a very low marginal cost, and retiring it converts cheap capacity onto a more expensive cost curve. The better question is whether its maintenance burden can be reduced, and whether the exception queue beside it is the real opportunity.

#What makes a process a poor fit for an AI agent?

High transaction volume, stable and well-defined inputs, tight latency requirements, and actions that are expensive or impossible to reverse. Each of those either raises the running cost or raises the consequence of a wrong-but-plausible output. Processes with several of them together are where deterministic automation continues to be the correct engineering answer.

#How should we budget for evaluating an agent?

Treat it as capital expenditure attached to the build, and as a recurring cost at every model change. Evaluation means running representative tasks repeatedly to measure behaviour, which consumes inference that produces no business output. Budgeting it as optional overhead is how teams end up unable to tell whether a model update has altered results.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing whether to move a working automation onto an agent, book a discovery call and we will work through it with you.