Legacy mainframes and custom apps power the back office of many enterprises. Yet the automation teams I speak with still rely on traditional RPA bots that only work when the UI stays exactly as it was when the bot was built. When a developer touches a screen, users install a patch, or a new version of the legacy frontend ships, bots break. The organization ends up with a growing backlog of failed bots and a process that does not scale. A process that should be a steady, repeatable stream of work becomes a cycle of rebuilds and brittle fixes.
Why RPA breaks here
Modern RPA tools, including UiPath, Automation Anywhere, Blue Prism, and Power Automate, automate by binding to selectors, xpaths, or object IDs. These identifiers rely on the stable rendering of a web or desktop control. On modern web apps, selectors often change with each deployment. On legacy mainframes and custom frontends, they can shift when a developer tweaks a layout, adds a new field, or updates a third‑party library. A bot that works today may be confused tomorrow. The result is a high maintenance burden. Industry data suggests that up to 30% of RPA development time goes into maintenance rather than new automations. When the underlying system changes, bot teams must rebuild, retrain, and re‑validate every affected bot. For legacy environments with infrequent but critical updates, that cost compounds quickly. The process becomes a treadmill rather than an asset.
What changes with computer use agents
- Agents see the screen and act like a human, so they survive UI changes without brittle selectors.
- No need to maintain object repositories for every legacy control.
- When the UI changes, the agent adjusts rather than halting.
- Exceptions and unexpected states are handled gracefully, not as fatal errors.
- A plain‑English SOP becomes the primary specification, eliminating the need for flowchart bots.
- Agents work across any app, including legacy frontends, Citrix, and virtualized desktops where traditional RPA struggles.
Selectors bind to a snapshot. Computer use agents bind to what is actually on the screen.
How to move without the risk
You do not need to rip out all your existing RPA at once. The most pragmatic path is to pick a single high‑pain process that lives on a legacy or mainframe system. The process should have a clear SOP and a mix of deterministic steps and human decisions. Deploy a computer use agent pilot to automate that one workflow. Compare the time to build, the time to maintain, and the rate of successful runs against your current RPA approach. If the agent proves more durable and easier to maintain, expand the scope to similar processes. Keep legacy RPA in place for high‑volume, stable, backend tasks where RPA is proven and cost‑effective. Use computer use agents where you need flexibility, exception handling, and the ability to follow a natural‑language SOP. This phased migration lets you build confidence without overcommitting resources.
The durable path forward
Traditional RPA works well when the system is stable and the process is fully defined. Computer use agents excel where the system is legacy, the UI changes, and the process relies on human judgment. By combining both approaches, you can keep your high‑volume backend automations on RPA while you modernize the long tail of processes with agents that adapt and recover. You gain a digital workforce that can handle changing environments and evolving requirements without a constant rebuild cycle.
If you want to see how a computer use agent handles a legacy workflow and follows a natural‑language SOP on your own environment, book a demo with the Coasty team at https://cal.com/coasty/15min .
Want to see this in action?
View Case Studies