The CIO Case for Moving From RPA to Computer Use Agents

Why RPA breaks here

Traditional RPA works by binding to specific UI elements, selectors, xpaths, object IDs. When a vendor ships a new release, changes the layout, or tweaks a field name, the bot either fails or produces wrong data. Industry studies consistently show that the majority of RPA maintenance effort goes into rework rather than new development. One large enterprise found that 40 percent of its RPA effort was spent fixing broken bots after system changes. Another reported three to five developer hours per month per bot just to keep it running. These are real enterprise patterns, not hypotheticals. The cost compounds for every bot, every release, and every time IT changes an application. It adds up to a backlog of broken automations and a team that is constantly firefighting instead of building value.

What changes with computer use agents

• ●Agents see the screen like a human, so they survive UI updates without rebuilding.
• ●No brittle selectors or xpaths to maintain. The same agent works across apps as long as the workflow is visible.
• ●When an exception occurs, agents read the error state and try alternatives rather than halting.
• ●A standard operating procedure written in plain English is almost a prompt. Agents can follow it directly without a flowchart bot.
• ●Legacy systems, Citrix desktops, and virtualized environments that RPA struggles with are reachable because agents act like a human user.

The durability advantage

Computer use agents represent a shift from brittle, element-specific automation to durable, process-specific automation. When a UI changes, a selector breaks, but the agent still sees the same overall layout and can adapt. When a field is missing or an error appears, the agent can read the screen, decide how to proceed, and keep going. This is not theoretical. The latest benchmark results show that the Coasty model achieves 85.6 percent on the OSWorld computer-use benchmark with public results and 82.81 percent on the official OSWorld leaderboard at osworld-v1.xlang.ai. These numbers reflect real desktop control across browsers and terminals, not API-only simulations. The durability comes from seeing the same workflow, not from hard-coded paths. That durability translates into lower maintenance overhead, fewer failed runs, and the ability to automate processes that are too variable for traditional RPA.

How to move without the risk

A phased approach lets you move from RPA to agents without abandoning what already works. Start by identifying a high-pain process: one that runs frequently, has complex logic, or lives on legacy or virtualized systems. Run a pilot with a computer use agent. Measure the difference in uptime, maintenance effort, and time saved. Once you see the benefit, expand to similar processes. Keep a small set of RPA bots for high-volume, stable, backend tasks where they still make sense. Over time, you replace the brittle bots with agents that are more resilient and easier to maintain. This path respects the reality that RPA has a place in high-volume, predictable work, while agents handle the long tail of exception-heavy, SOP-driven processes.

Practical steps for your automation team

• ●Audit your current bots for rebuild frequency and maintenance cost.
• ●Map SOPs to visible work: open applications, forms, and dashboards.
• ●Select one SOP-driven process for a pilot with a computer use agent.
• ●Run the pilot in a controlled environment, then measure performance against the existing manual or RPA approach.
• ●Document lessons learned and adjust your roadmap before scaling.