Computer-Use Agents vs RPA: Why a Decade of Enterprise Automation Kept Breaking

Almost every operations team I've talked to has a pile of RPA bots that worked for a while and then stopped. When I ask what happened, the answer is nearly always the same: something on the screen changed. A vendor moved a button, a form added a field, a date format shifted, and the bot kept doing exactly what it was recorded to do, which was now the wrong thing.

I don't think that means RPA was a bad idea. It did the thing it was built to do, which was repeat the steps it had been shown. The catch is that those steps only work while the screen stays the same, and screens rarely stay the same for long.

Key takeaways

• RPA repeats recorded clicks, so it breaks whenever the screen it runs on changes.
• The failure rate is high: EY puts RPA implementations at 30 to 50% failed, and Forrester says deterministic tools aren't powerful enough for autonomous operations.
• A computer-use agent reads the screen and works toward the goal, so a moved button or renamed field doesn't stop it.
• RPA still has a place: high-volume tasks on screens that genuinely don't change. It struggles with anything that varies.
• Financial back offices feel this first, because so much work lives behind login-walled portals with no API.

what RPA got right

RPA made sense, and for some work it still does. A lot of back-office work is repetitive and tied to a screen, so recording the clicks and playing them back was a reasonable way to take it off people's plates, with no API to wait for and no engineering team rewriting core systems. On a process that doesn't change, it works and it saves real time. That's why so many teams bought it by the thousands of seats.

why it broke

The catch is in the word "replay." A bot keys off the exact spot of a button, the exact name of a field, the exact shape of a file. When any of that moves, and in real software it moves all the time, the bot doesn't notice. It keeps clicking where the button used to be. Usually it fails quietly, overnight, on the workflow nobody was watching, and someone finds out the next morning.

The numbers back this up. EY has put the failure rate of RPA implementations at 30 to 50 percent, and "breaking bots" come up over and over as the main complaint. Forrester now says plainly that deterministic workflow engines and RPA "are not powerful enough to implement the complexities required for autonomous operations," and has started naming a successor category. The maintenance is the part people underestimate. You automate a person's worth of clicking, then spend a chunk of it back keeping the bots alive.

what's different about computer-use agents

A computer-use agent doesn't memorize coordinates. It looks at the screen, works out what it's seeing, and picks the next action toward what you asked it to do, closer to how a new hire would. If the button moves, it finds the button. If a field gets renamed, it still understands what the field is for. Because it's reading the screen by meaning, a redesign that would have broken a bot is just a slightly different screen to read. a16z makes the same point: what lets these agents slot into existing workflows is that they operate through the interface itself, logging in and working with legacy software, without an IT overhaul.

where it's still hard

None of this makes RPA pointless, and it doesn't make agents magic. For a high-volume task on a screen that really doesn't change, a deterministic bot is cheap and predictable, and that's worth something.

And a computer-use agent is probabilistic, which means it can be wrong, and small errors add up over a long task. If each step is 90 percent reliable, a ten-step workflow only finishes cleanly about a third of the time. So you don't get to skip the hard part. Instead of maintaining brittle bots, you're now deciding what the agent is allowed to touch, where a human signs off, and how you can show afterward what it did. We wrote that part up on its own, in the agent trust framework.

where each one fits

Which one you reach for is fairly practical:

• If there's a stable, documented API, use it. It's faster and more reliable than driving a screen at all.
• If it's a repetitive task on a screen that genuinely doesn't change, RPA can be enough.
• If it's a legacy or login-walled system with no real API, and the work varies, that's where a computer-use agent earns its place, as long as you put the right controls around it.

why finance feels it first

Financial operations is full of that third case, which is why I keep coming back to it. So much of the work happens behind a portal someone logs into by hand, with no API on the other side: carrier and custodian portals, policy-admin systems, reconciliation across tools that can't agree on the same number. These are exactly the systems RPA struggled with, because they change and they're messy. Vision-based agents that read a portal by meaning have taken 20-carrier insurance quoting from more than six hours down to under twenty minutes, and they keep working through the redesigns that used to take the bots down.

If you're weighing this for your own back office, the companion piece on enterprise computer use goes deeper on how the agents work and where they fit. And if you're building in this space, I'd love to compare notes.

FAQ

What is the difference between computer-use agents and RPA? RPA repeats a fixed set of recorded clicks, so it breaks when the screen changes. A computer-use agent reads the screen, works toward the goal, and adjusts when the interface moves.

Is RPA still useful? Yes, for high-volume tasks on screens that don't change. It struggles with variation, exceptions, and anything that shifts often, which is where computer-use agents fit better.

Are computer-use agents more reliable than RPA? They handle change far better, but they're probabilistic, so they can make mistakes, and small errors add up over long tasks. The reliability you get in production comes from the controls and engineering around the agent, not the model on its own.