What the RPA Vendors Will Not Tell You About Computer Use Agents
Every VP of automation I talk to eventually hits the same wall. They build bots to handle invoice processing or order fulfillment. The bot works in the test environment. It works in production for a few weeks. Then the finance team rebrands an invoice field or shifts to a new ERP module. The bot fails. The team rebuilds it. Three months later, the UI changes again. The cycle repeats. The backlog of broken bots grows. The real cost is not line items for licenses. It is the time engineers spend rebuilding bots that should have been durable. That is the pain RPA vendors rarely highlight. The underlying model of binding to selectors and object IDs is brittle. It works for stable, backend processes. It breaks for anything that touches the UI or follows an evolving SOP.
Why RPA breaks here
Traditional RPA tools like UiPath, Automation Anywhere, and Power Automate rely on selectors: XPath patterns, CSS selectors, object IDs, or UI element names that identify buttons, fields, and tables. When the application changes an element, the selector becomes invalid. The bot halts. A developer must open the workflow, locate the broken step, and rebuild the selector. If the change is subtle, the bot might not fail immediately. It might fill the wrong field or ignore a required step. Errors like that hide in production until they cause a compliance issue or a data mismatch. Industry research shows the average RPA project incurs a 30 percent to 50 percent cost overrun, with a significant portion attributed to maintenance and rework. When an application updates its UI every quarter, the rebuild cost compounds. The maintenance treadmill is not a bug. It is baked into the design. You can stabilize a process with a rigid UI, but you cannot automate one that evolves.
What changes with computer use agents
- ●Survives UI changes because the agent sees the screen like a human
- ●No brittle selectors or object IDs to maintain
- ●Recovers from exceptions and unexpected states instead of halting
- ●Follows the SOP as written, not a flowchart bot
- ●Works on legacy applications and virtualized desktops where RPA struggles
The one line a VP of automation should remember: if your process changes more than once a year, RPA is not durable. Computer use agents are.
How to move without the risk
Do not rip out all your existing RPA. You still have stable, high-volume backend tasks that RPA handles well. Start with one high-pain process that is UI-heavy, SOP-driven, and frequently updated. For example, an onboarding workflow that moves a new hire through HR systems, payroll setup, and IT provisioning. Write the process as a plain English SOP. Capture screenshots of the UI at each step. Use those screenshots as a reference for the agent. Deploy the agent in a pilot environment. Measure how often it recovers from errors versus how often it halts. Compare the maintenance hours to the hours you spend rebuilding RPA bots. If the agent requires fewer updates and handles unexpected states, expand it to more processes. Over time, you build a portfolio of agents that survive UI changes. You keep the stable RPA bots where they belong. This phased migration lets you hedge your bets. You reduce long-term maintenance while preserving what works today.
The RPA vendors will not tell you that the model of brittle selectors and rebuild-on-change is the wrong fit for evolving processes. Computer use agents see the screen and act like humans, so they survive UI updates, follow SOPs directly, and recover from exceptions. If you are tired of the maintenance treadmill, book a demo with the Coasty team to see how computer use agents can make your automation durable. https://cal.com/coasty/15min