Board Level Questions About Replacing RPA with Computer Use Agents
At a recent automation strategy session, a CFO asked a blunt question: "Is our RPA platform a durable asset or a growing line of technical debt?" The answer touched on two things. First, the bot backlog is real. Global studies show that enterprises spend 30 to 45 percent of their automation budget just keeping existing bots running, not building new ones. Second, the processes that most teams want to automate are shifting from stable backend tasks to anything with a human interface, forms, portals, legacy apps, and workflows that sit on Citrix or virtual desktops. Traditional RPA handles the first category well. It struggles with the second.
Why RPA breaks here
Traditional RPA relies on brittle selectors. An automation built on a UI element ID, XPath, or CSS class works until the vendor releases a patch, the web framework changes, or the application is upgraded. Then the bot stops working. In many organizations, a single UI change cascades into a rebuild ticket, a re-qualification cycle, and a week of developer time. Industry surveys indicate that 20 to 30 percent of RPA incidents stem directly from UI and application changes. That is the rebuild-on-every-change cost. It is also why many teams find themselves maintaining more bots than they are running. The platform becomes a treadmill rather than an asset.
What changes with computer use agents
- ●Survives UI changes: Agents see content on the screen and infer next actions instead of relying on a fixed selector. A new button, a changed field label, or a different layout does not break the automation.
- ●No brittle selectors: Once the agent can read and act on the screen, it does not need a repository of XPaths, CSS classes, or object maps. That removes a whole class of maintenance and testing work.
- ●Recovers from exceptions: When a bot halts on an unexpected error, RPA must be stopped and restarted by a human. Computer use agents can read the error message, decide on a recovery step, and continue without human intervention.
- ●Follows the SOP as written: A standard operating procedure expressed in plain English is already close to a prompt. Agents can interpret the steps directly, without building a separate flowchart bot.
- ●Works on legacy and Citrix: Agents interact with the screen like a human, so they run on legacy desktops, virtualized environments, and systems where traditional RPA cannot reliably bind to UI elements.
Computer use agents see the screen and act like a human, so they survive UI updates, need no brittle selectors, and recover from exceptions instead of halting.
How to move without the risk
You do not need to rip out all your RPA at once. A pragmatic path starts with a single high-priority process that combines three characteristics: high variation, frequent UI changes, and a clear written procedure. For example, invoice entry from a supplier portal that adds a new field every quarter, or a support intake form that changes layout each release. Pilot the process with a computer use agent. Measure the time it saves, the number of incidents, and the amount of time your developers spend on rebuilds. If the agent reduces manual effort by 40 percent and cuts rebuild tickets by half, you have a proof point. Then expand to similar processes across departments. Use the wins to fund a larger pilot in a different line of business. This phased approach lets you learn, validate, and scale while keeping your existing RPA portfolio stable.
Where RPA still fits
RPA remains a strong fit for high-volume, stable, backend processes where the user interface does not change and the steps are deterministic. Think large-scale data entry into a fixed ERP module, batch file processing, or integration flows that operate at the system level. These workflows are predictable and benefit from the reliability and governance that mature RPA platforms provide. The real shift is to use computer use agents for the long tail of work that is human-facing, process-heavy, and constantly evolving. That combination gives you the best of both worlds: stability where it matters most, and durability where the old model fails.
The question is not whether to move, but when. A phased pilot can show you the difference between a platform that needs constant rebuilding and an agent that sees the screen and adapts. The Coasty team can walk you through a practical example for your environment. Book a demo at https://cal.com/coasty/15min to see how computer use agents can reduce rebuilds, handle variation, and free your team from the maintenance treadmill.