RPA automates the interface, not the system behind it
A robot repeats a recorded sequence of clicks and keystrokes against software that offers no other way in. That is its strength and the source of every complaint about it.
What people are actually trying to do when they buy RPA
- We have a system with no API and no budget to replace it
- This is the honest core of RPA and it remains valid. When the vendor is gone, the source is lost or the integration project is three years out, driving the interface is the only integration available. Nothing about agents changes this.
- The work is repetitive and the volume justifies automation
- Also valid, with a caveat worth stating plainly: the automation is only cheaper than the person if the interface stays still. Total cost of ownership is dominated by maintenance, not by the build, and that ratio surprises people.
- We want the automation built by the team that does the work
- The recorder-based pitch. It works for simple flows and degrades quickly, because exception handling is programming regardless of whether it is expressed in a canvas, and exceptions are most of what a real process consists of.
- We need an audit trail of what was done
- A genuine strength, and one worth keeping when you move on. A robot that logs every step produces better evidence than a person working the same screen, and any replacement should be held to that same standard.
RPA and agents on the axes that decide
| Classic RPA | Browser agent | |
|---|---|---|
| Adapts to a changed screen | No, the step fails | Often, it reads the page fresh |
| Behaves the same way twice | Yes, by construction | Not guaranteed, assert on outcomes |
| Cost per run | Near zero after the build | Tokens per decision, meaningful at volume |
| Cost to build the hundredth flow | Similar to the first | Much lower, the model generalises |
| Explains why it failed | A step index and a screenshot | A reasoning trace, though not always a true one |
| Handles an unexpected dialogue | Stops, unless someone anticipated it | Usually continues, sometimes wrongly |
As of 2026-08-31 · Competitor details come from each vendor's published pricing page on that date.
Common questions
Is RPA dead?
No, and predictions that it is tend to come from people selling the replacement. Deterministic replay is genuinely better than a model for a high-volume flow through an interface that does not change. What has died is the assumption that RPA is the default answer for every process with no API.
What is the difference between RPA and agentic automation?
Where the decisions live. RPA decides at build time and replays; an agent decides at run time from what it observes. That single difference produces every other difference in the table above, including the cost profile.
Why do RPA programmes stall?
Maintenance overwhelms the build capacity. Each new robot adds a permanent obligation to fix it when a screen moves, so a team that ships twenty robots spends its second year maintaining twenty robots and shipping none.
Can the two be combined?
Usefully, yes, and this is where most mature deployments end up. Script the deterministic parts, invoke a model only where the script cannot resolve what it is looking at. You pay for judgement only where judgement is required.
The browser layer under either approach
Whether the decisions come from a script or a model, something has to run the browser. That part we do.