The real reason your RPA center of excellence has a six month backlog
Your automation team is not lazy. They are fighting a structural problem that every RPA Center of Excellence hits sooner or later: bots that break every time an app UI changes. That is the maintenance treadmill. Instead of shipping new automations, your engineers spend weeks rebuilding broken bots. The backlog grows until it reaches the six month mark. Other teams live in that world too. A process that should take a human an hour can require days of coordination once automation is involved. This is not a people problem. It is a design problem.
Why RPA breaks here
Traditional RPA tools like UiPath, Automation Anywhere, and Blue Prism automate by binding to selectors, xpaths, and object IDs. When a developer builds a bot, they make assumptions about the current state of the application. A button has a certain class, a text field has a specific ID, the layout is stable. Those assumptions are correct for a snapshot. They are fragile over time. When business teams update their apps, even a small change breaks the selector. The bot halts. A developer must investigate, update the selector, and redeploy. This is the rebuild-on-change cost. Industry analysis shows maintenance consumes 60, 70% of total RPA effort in many enterprise deployments. That is not a line of business savings. That is a hidden tax. The problem worsens in environments with frequent releases, multiple environments, and custom applications. Every change creates a new incident. The backlog is not a lack of demand. It is a lack of durability.
What changes with computer use agents
- ●Survives UI changes: agents see the screen and act on what is there, not on brittle selectors.
- ●No brittle selectors: agents use vision and reasoning instead of fixed identifiers.
- ●Recovers from exceptions: when something unexpected happens, agents can detect the state and try alternative actions rather than halting.
- ●Follows SOPs as written: plain English instructions are already prompts. Agents can execute them directly without flowcharts.
- ●Works on legacy and Citrix: agents run on any desktop or virtualized environment where RPA struggles.
Agents replace the selector with a simple question: 'Can the agent see this step on the screen, and does it know what to do next?'
How to move without the risk
You do not need to rip out all existing RPA overnight. A pragmatic, phased path reduces risk and builds evidence. Start with one high-pain process that is easy to describe in plain English and has frequent UI changes. Automate it with a computer use agent using the current SOP. Measure time saved, error reduction, and the number of incidents you avoid compared with the manual process. Then compare with your existing RPA approach. If the agent is faster to build, easier to update, and more resilient, expand to similar processes. Keep RPA for high-volume, stable, deterministic tasks like backend data entry where API access is available. Over time, you can migrate more of the long tail to agents while preserving the value of your existing RPA investments. This approach lets you move without betting the entire automation program on a single technology.
RPA still has a place in the enterprise. The bottleneck is not the demand for automation. It is the cost of maintaining brittle bots. Computer use agents let you automate SOPs directly and adapt to real UIs instead of rebuilding every time. If your Center of Excellence has a six month backlog, it is time to talk to the Coasty team. Book a demo at https://cal.com/coasty/15min.