From RPA to agents: what changes when the bot reads
Published
Every RPA vendor now has an agentic product and every agent vendor now has an RPA replacement story. Both are selling the same claim from opposite directions: that a language model in the loop makes the old problems go away.
It does not, and the reason is more interesting than either pitch. Agents change exactly one thing, and everything else that is different follows from it.
The one difference
RPA decides at build time. An agent decides at run time.
That is the whole distinction. A robot is a recorded sequence: click here, type this, wait for that. The decisions were made by whoever built it, encoded as coordinates and selectors, and replayed identically forever. An agent is given an objective and works out the sequence as it goes, from what the screen currently shows.
Everything else — the cost profile, the testing problem, the governance question, the failure modes — is downstream of that single relocation.
Notably, what does not change is the interface. Both drive the same portal through the same browser. Both are automating something that was designed for a person because no other way in exists. The integration problem is identical; only the authorship of the steps has moved.
The vocabulary problem
Before going further it is worth disarming three terms, because they are used to mean incompatible things in the same conversation and the confusion is not accidental.
Agentic process automation is usually RPA vendors' name for adding a model to their existing product. Sometimes it means a model chooses between branches at run time, which is genuinely agentic. Often it means a model classifies a document at one node of an otherwise fixed graph, which is a workflow with a classifier in it. Both ship under the same phrase.
Intelligent automation predates language models entirely and originally meant RPA plus optical character recognition plus a rules engine. Its meaning has drifted twice and it now signals very little.
Hyperautomation is an analyst category rather than a technical one. It describes a programme, not a capability.
The test that cuts through all three is the one worth applying in a demo: does the sequence of steps get decided before the run starts, or during it? If the answer is before, it is a workflow regardless of how many models are inside it. This is not pedantry — the two have different cost profiles, different failure modes and different testing requirements, and buying one while planning for the other is where programmes go wrong.
Where the money actually goes
The pricing conversation is usually about licences, and licences are rarely the largest line in either world.
In RPA, the recurring cost is maintenance engineering: the people who fix robots when screens move. Licence cost is visible and budgeted; maintenance is diffuse and lands on whichever team owns the process. This is why RPA programmes look cheap in year one and expensive in year three, and why the total is so often a surprise — the expensive part was never on the invoice.
In agent deployments, the recurring cost is inference, and it is concentrated in a place people do not look: the page representation. Every turn resends a description of the current screen. A dense portal page rendered as an accessibility tree is a large amount of text, and it is sent again on every single turn. The reasoning tokens are usually the smaller half.
Three consequences that follow directly:
Trimming the representation is the highest-leverage optimisation available. Sending the relevant region rather than the whole document routinely cuts the bill by more than half, and it usually improves accuracy at the same time because there is less to be distracted by.
Capping turns per task is a budget control, not a safety net. Without a ceiling, the tail of your cost distribution is unbounded, and it is populated entirely by runs that were going wrong.
Cost per successful outcome is the only honest metric. Cost per run flatters you by counting the cheap failures. If a fifth of runs fail after twenty turns, they are in the budget whether or not they are in the dashboard.
What follows from it
Adaptation, which is the whole case
A recorded step is a bet that a screen will not move. When the portal redesigns, the bet loses and the robot stops. In a mature RPA programme this is not an occasional annoyance — it is the dominant cost. Teams that ship twenty robots spend their second year maintaining twenty robots and shipping none, and this is the single most common way an automation programme stalls.
An agent reading the page fresh each turn is largely indifferent to a redesign. The button moved; it reads the new page and finds the button. This is genuine and it is the strongest argument in the category. If you maintain automation against many portals that each change on their own schedule, this alone can justify the migration.
Cost inverts
RPA has high build cost and near-zero marginal cost. Once the robot exists, running it is a rounding error, and the hundredth run costs the same as the first.
Agents invert this. Building the first flow is dramatically cheaper — often a prompt and an afternoon instead of a fortnight of recording and exception handling. But every run spends tokens, on the page representation and on the reasoning, and a page that needs forty turns costs forty times a page that needs one.
The practical consequence: RPA gets cheaper with volume and agents get cheaper with variety. Ten thousand runs of one flow favours the robot decisively. One run each of a thousand different flows favours the agent just as decisively. Most real portfolios contain both, and the mistake is picking one technology for the whole portfolio because a vendor's pricing model made it look uniform.
Determinism is gone, and your test strategy assumed it
An RPA robot does the same thing every time. That is not merely convenient — it is the foundation of how these things are tested, signed off and audited. Run it in staging, watch it work, promote it.
An agent may take a different route on each run and both routes may be correct. This breaks record-and-replay testing outright, and it breaks the sign-off model that says "we verified the process".
What replaces it is assertion on outcomes rather than paths:
| RPA assertion | Agent assertion |
|---|---|
| Step 7 clicked element X | The invoice exists in the ledger |
| The flow completed 12 steps | The extracted total reconciles |
| No exception was raised | The record passed validation |
| Screenshot matches baseline | The correct account was debited |
The left column is cheaper to write and tells you almost nothing about whether the work was done correctly. The right column is what you actually care about, and it was worth asserting under RPA too — the difference is that with agents you no longer have the option of pretending the left column is sufficient.
Governance gets harder before it gets better
An RPA robot's behaviour is fully specified by its definition. You can read it, diff it, and know what it will do. An agent's behaviour is specified by a prompt, a model version and whatever it encounters, and only the first is under your control.
Three concrete consequences worth stating:
A model version change is a behaviour change. Pinning versions matters more than teams expect, and "we upgraded to the newer model" is a change that belongs in a change log alongside code.
The page becomes an input channel. A robot that encounters hostile text on a page does not read it. An agent does, and may act on it. This is a new class of risk with no RPA equivalent, covered properly in the piece on securing browser agents.
Guardrails have to sit outside the model. An instruction in a prompt is a request. A permission check in the code that executes the action is a control. Anything that must not happen has to be impossible rather than discouraged — and this is a discipline RPA never needed, because a robot could only do what it was recorded doing.
What does not change
Half the value of this comparison is in the rows that stay put, because they are where migration projects find their surprises.
The interface is still the integration. If there is no API, there is no API. An agent driving a portal is doing exactly what the robot did, with a different author for the steps. Nobody has removed the underlying problem, which is that the system you need to talk to was built for a person.
Authentication is still the hard part. Sessions expire, multi-factor prompts appear, portals notice logins from new addresses. This is unchanged and is frequently the single largest source of failures in both worlds.
The audit obligation is unchanged. A regulated process needs a record of what was done, by whom, when and on what basis, and a model in the loop does not relax that. If anything, non-determinism raises the bar: with a robot the definition doubles as documentation, and with an agent it does not, so the run record has to carry the whole weight.
Exception handling is still most of the work. The happy path was never the expensive part. Duplicate records, timeouts mid-submit, a portal in maintenance, a field that appears only for certain account types. Agents handle some of these gracefully and invent plausible-looking wrong answers for others, which is not obviously an improvement over stopping.
Somebody still has to run the browsers. Whether the decisions come from a recorded script or a model, a browser has to be started, supervised, isolated, recycled and observed. That layer is identical and it is not free either way.
What a Fachbereich actually notices
The technical comparison above is the part engineers argue about. The part that decides whether a migration succeeds is different, and it is worth naming because it rarely appears in vendor material.
The person who owned the robot loses the ability to read it. An RPA definition is inspectable. Someone in the business could open it, follow the steps, and say whether it matched the process they had in their head. A prompt plus a model is not inspectable in the same way, and the reassurance that came from being able to look is gone. Replacing it takes work: run records that show what happened in business terms rather than in clicks.
"It worked yesterday" stops being evidence. With a deterministic robot, a successful run genuinely predicted the next one. With an agent it predicts less than people assume, and the first time a familiar flow behaves differently, confidence drops further than the actual failure justifies. Setting that expectation early is cheaper than repairing it later.
Exceptions become a queue rather than an alarm. RPA exceptions were failures — something stopped and someone had to fix it. Agent escalations are a normal operating outcome with volume, and somebody has to own the queue. Deployments that skip this end up with an escalation path that routes to a mailbox nobody reads, which is functionally the same as no guardrail.
None of these is a reason not to migrate. They are the difference between a migration that lands and one that technically works and is quietly abandoned.
The pattern that actually works
The most effective deployments we see are not agentic. They are hybrid, and the split is principled rather than aesthetic:
Script the deterministic parts. Login, navigation to a known section, pagination, download. These are stable, high-volume, and cheap to encode. Using a model here spends tokens on decisions that were already made.
Invoke the model where the script cannot resolve what it is looking at. A selector missed. The page is not the expected shape. An unexpected dialogue appeared. A new field is present. This is the judgement call, and it is worth paying for.
Return to script once resolved. The agent's output is a decision, not a takeover. It says which element, and the script clicks it.
async function findSubmit(page) {
// The fast, cheap, deterministic path -- correct the overwhelming majority of the time.
const known = page.locator('[data-testid="submit-invoice"]');
if (await known.count()) return known;
// Only when it misses do we pay for judgement.
const candidates = await page.locator('button, [role=button]').all();
return await resolveWithModel(candidates, 'the control that submits this invoice');
}
This structure gives you the robot's cost profile on the ninety-five per cent and the agent's adaptability on the five per cent that used to require a maintenance ticket. It is also considerably easier to reason about in an audit, because the deterministic parts are still readable and the non-deterministic parts are localised to identifiable decision points.
The reason this pattern is under-sold is that it does not fit either vendor's story. It is not an agent product and it is not an RPA product.
A migration order that does not blow up
If you have an RPA estate and want to move parts of it, the sequencing matters more than the technology choice.
Start with the flows that break most often, not the ones that run most often. The value of adaptability is proportional to maintenance pain. A robot that has needed six fixes this year is a good candidate; one that has run untouched for two years is a bad one, and moving it converts a working, free, deterministic process into a paid, non-deterministic one for no benefit.
Keep the robot running in parallel. Run both against the same inputs and compare outcomes for a few weeks. This is the only honest way to find out whether the agent's version is actually correct, and it is cheap because the robot already exists.
Instrument the two new failure modes before you need to. Turn-count distribution and escalation rate. Both are silent, both are new, and both are much easier to add on day one than during an incident. The failure taxonomy covers what to watch.
Do not migrate the audit trail last. If the process is regulated, the record of what was done is the deliverable, and an agent that works perfectly but cannot evidence what it did has not replaced anything.
In one line
Agents did not make RPA obsolete. They moved the decision from build time to run time, which is a genuine improvement for varied and unstable work and a genuine regression for uniform and stable work.
The teams getting the most out of this are not choosing. They are putting the model where the judgement is and leaving the script where it never needed one — and paying for judgement only where judgement is required.