Your finance team still runs a bot to upload vendor invoices into ERP. It worked for two years until the latest payroll update changed the button label from "Upload" to "Submit Invoice." The bot failed, the team patched it by hand, and now you have a backlog of half a dozen broken bots sitting in a ticket queue. This is the reality of selector-based automation: it works until the UI changes, then it breaks, and every fix adds to the maintenance treadmill.
Why RPA breaks here
Traditional RPA binds to explicit locators, XPaths, CSS selectors, UI Automation IDs, or accessibility names. When the application changes its layout, updates its styling, or reorders fields, those locators become stale. The bot stops clicking the right button, skips a step, or enters data into the wrong field. The cost of a single rebuild is often measured in days of developer time. In many organizations, RPA maintenance consumes 30 to 50 percent of the total automation budget, even for processes that were supposed to be "set and forget." This is not a problem of complexity. It is a problem of fragility. Every time developers chase selectors, the automation team is pulled away from building new value and forced into firefighting mode.
What changes with computer use agents
- Survives UI changes without retraining a bot. Computer use agents see the screen the same way a human does, so they can locate elements by visual context rather than brittle IDs.
- No brittle selectors or XPaths to maintain. Agents use the screen as the source of truth, so when the UI updates, the agent adjusts naturally.
- Recovers from exceptions instead of halting. If a popup appears, a field is blank, or a network error occurs, agents can read the screen, decide on a next step, and continue rather than crashing.
- Follows the SOP as written. A plain-English procedure like "Open the portal, select the customer tab, and click download" is already close to an agent instruction. No flowcharts or decision trees to build.
- Works on legacy and virtualized desktops. Agents control the mouse and keyboard directly, so they operate across browsers, legacy applications, and Citrix environments where traditional RPA struggles.
The selector approach ties automation to a specific layout. Computer use agents tie automation to what the human sees, making the automation durable across updates and platforms.
How to move without the risk
You do not need to rip out all RPA at once. Start by identifying a high-pain process with frequent UI changes or exception handling. For example, a procurement approval workflow where the supplier portal layout changes quarterly, or a customer onboarding process that runs across multiple legacy systems. Pilot a computer use agent on just that workflow. Measure the time saved compared with the current manual or RPA approach. Use the insights to adjust your SOPs and agent prompts. Once you see the benefits, expand to related processes. Use agents for the long tail of work where UI changes are common and exception handling is critical. RPA will still be the right choice for high-volume, deterministic back-end tasks that rarely change. The goal is not to replace RPA everywhere. The goal is to reduce the portion of your automation budget spent on maintenance and to shift focus to new automation opportunities.
The durable path forward
The maintenance treadmill is a symptom of a selector-based architecture. By moving to computer use agents, you stop rebuilding automation every time the UI changes and instead build automation that adapts. This reduces the cost of change and frees your team to build more automation faster. You can run agents in the cloud, on a desktop app, or through our /v1 computer use API. Parallel execution with agent swarms lets you scale across processes. A free tier is available to start. If you are ready to see how agents can handle your highest-pain workflows without the rebuild cycle, book a demo with the Coasty team.
Book a demo with the Coasty team at https://cal.com/coasty/15min to explore how computer use agents can reduce your RPA maintenance burden and extend automation to processes that were previously out of reach.
Want to see this in action?
View Case Studies