You have an IDP layer that extracts data from invoices, contracts, and claims, then hands that data to an RPA bot that populates downstream systems. The process looks clean on paper, but in practice the bots break every time the ERP or ERP-adjacent screens change. Your developers spend half their time rebuilding bots and the other half explaining why the automation is only 70 percent reliable. You still have a pile of documents that humans must touch because the bots cannot handle the exceptions that are baked into your workflows.
Why RPA breaks here
Traditional RPA relies on selectors, xpaths, and object IDs that are tightly coupled to the UI elements of each screen. When a vendor updates a web application, moves a button a few pixels, or changes the class names of input fields, the bot stops working. Gartner estimates that up to 30 percent of RPA maintenance effort goes into rebuilding or tweaking bots after even minor UI changes. In document-heavy processes, the failure surface is larger: you have multiple screens, legacy systems, and occasional errors where the bot reads a field incorrectly or gets stuck in a loop. The bot halts and requires manual intervention, not because the process is complex but because the automation cannot adapt to the state it sees.
What changes with computer use agents
- Survives UI changes
- No brittle selectors
- Recovers from exceptions
- Follows the SOP as written
- Works on legacy and Citrix
With a computer use agent, you replace fragile selectors with a single, persistent policy: follow the SOP as written and recover when the environment surprises you.
Selectors vs. seeing the screen
RPA bots bind to specific UI locators. If the locator becomes invalid, the bot fails. Computer use agents see the screen as a human does: they read text, identify buttons by their appearance and context, and type or click accordingly. They do not need selectors, xpaths, or object IDs. When a screen changes, the agent simply reinterprets the new layout and continues. This removes the rebuild-on-change cycle that consumes engineering time and introduces drift between the bot and the actual application.
Halt on exception vs. recover
In a typical RPA scenario, if the bot encounters a missing field or an unexpected error message, it stops and logs an exception. A developer must diagnose the issue, update the bot, and redeploy it. Computer use agents are designed to handle exceptions at runtime. They can read error messages, retry operations, or escalate to a human when the situation is ambiguous. They do not halt the entire process because of a single unexpected state. This recovery capability reduces manual intervention and keeps document workflows moving even when the environment is unstable.
Follow the SOP, not the bot
SOPs are already written in plain language. A computer use agent can read and follow them directly. You do not need to translate an SOP into a flowchart, then into a bot script. You simply write the steps in natural language, and the agent executes them on the screen. This makes automation accessible to business analysts and reduces the barrier between process design and implementation. It also makes the automation more transparent: you can see exactly how the agent interprets each step and adjust the language to correct any misunderstandings.
How to move without the risk
You do not need to rip out all your RPA at once. Start with a single, high-pain document workflow that has frequent UI changes, many exceptions, and a well-documented SOP. Pilot the workflow with a computer use agent. Compare the reliability, the time to fix, and the operational burden of the agent against your existing RPA. Once you see a clear improvement, expand the agent to additional workflows. Over time, you can replace or augment the brittle bots with agents that are more resilient and easier to maintain. RPA still fits well for high-volume, stable, backend tasks where you need deterministic, low-overhead automation. Computer use agents excel at the long tail of processes that are exception-heavy, UI-volatile, and driven by SOPs.
The durability of your automation depends on how well it handles change. Computer use agents survive UI changes, recover from exceptions, and follow SOPs as written. If you want to move beyond the rebuild-on-change treadmill, book a demo with the Coasty team.
Want to see this in action?
View Case Studies