RPA exception handling is broken: how AI agents recover on their own

Why RPA breaks here

Traditional RPA works by binding actions to selectors, xpaths, and object IDs. When the application author changes a class name, the order of elements, or adds a new control, the bot can no longer find the target. The bot halts and reports an error. In many enterprises, the failure rate for new bots is above 30 percent within the first month of production. Maintenance can consume 40 to 60 percent of the RPA budget, according to a 2024 industry survey. The cost is not just the developer time to rebuild. There is also the risk of missed deadlines, compliance gaps, and the perception that automation is brittle. The same bot that worked yesterday may stop working tomorrow.

What changes with computer use agents

• Survives UI changes because agents SEE the screen instead of relying on brittle selectors.
• No brittle selectors means the bot keeps running when applications update or reorganize themselves.
• Recovers from exceptions by reading the error state and choosing a next action instead of stopping.
• Follows the SOP as written, turning a human-readable procedure into a direct instruction set.
• Works on legacy systems, Citrix, and virtualized desktops where traditional RPA struggles.

How to move without the risk

You do not need to rip out all RPA at once. Start with a high-pain, exception-heavy process. Identify workflows where the UI changes often, where errors are common, or where humans are required to interpret the screen. Run a pilot with a computer use agent on one process. Measure the time to handle unexpected states, the number of rebuilds needed, and the total maintenance cost. If the agent handles changes and exceptions with less human intervention, expand it to related processes. Use RPA for high-volume, stable, backend tasks where the UI rarely changes. Keep both approaches running, but shift the long tail to agents.