Unattended RPA bots and the 3am pager: how AI agents change on-call
A quarterly close, a batch reconciliation, or a daily compliance run triggers an unattended bot. The script runs fine for months. Then a UI update or a compliance change breaks a selector. The bot stalls, the alert triggers, and a developer at 3am has to patch the bot and redeploy it. This is the recurring pattern for many automation teams. The bot that was supposed to eliminate on-call work now creates it.
Why RPA breaks here
Traditional RPA bots rely on selectors, xpaths, and object IDs to find elements. When an application changes a class name, a layout shift, or an upgrade, those bindings break. Gartner estimated that more than 60 percent of RPA deployments experience unplanned downtime due to such changes. Teams spend weeks rebuilding bots for every major upgrade. The bottleneck is not the volume of work but the volume of maintenance. A single bot that fails once a year can absorb weeks of developer time. For processes that touch multiple systems, the maintenance backlog grows quickly. A VP of automation might see 30 percent of their team’s capacity consumed by updates rather than new automation.
What changes with computer use agents
- ●Agents see the screen like a person: they read text, identify buttons, and infer context from layout changes.
- ●No brittle selectors: because they act on what is visible, UI updates, layout shifts, and minor UI tweaks rarely break them.
- ●Recover from exceptions instead of halting: when an error occurs, the agent can retry, fall back to an alternative path, or ask for a human check.
- ●Follow SOPs as written: a plain-language procedure becomes a direct prompt for the agent, removing the need for flowchart bots.
- ●Work on legacy and virtualized desktops: agents operate on real desktops, Citrix environments, and older applications where RPA struggles.
The durable automation is the one that survives the next UI change, not the one that survives the most clicks.
A simple comparison
Think about a recurring process that runs unattended. If the UI changes, a traditional bot halts until a developer rebuilds it. A computer use agent sees the new layout, adapts, and continues. If an error occurs, wrong data, missing field, failed API, the RPA bot stops and alerts a human. The agent can attempt a different action, log a structured exception, or flag the case for review. Over a year, that difference compounds: fewer rebuilds, fewer on-call disruptions, and a more stable digital workforce.
How to move without the risk
A phased approach lets you hedge against uncertainty. First, identify a high-friction process that is prone to UI changes or exceptions. It could be a monthly reconciliation that touches legacy systems, or a compliance submission that routes through multiple portals. Run a pilot with a computer use agent to compare reliability and maintenance effort. Measure uptime, error rates, and time to resolve incidents. Use those results to justify expanding the scope. For processes that are stable, deterministic, and high-volume, such as a batch upload that runs nightly, RPA can still make sense. The goal is to allocate the right tool to the right job, not to replace everything at once. Organizations that start with a single pilot often uncover additional opportunities within a few months, and the confidence to scale gradually.
If you are tired of responding to unattended RPA alerts at 3am, a different approach is possible. Computer use agents see the screen and recover on their own. To see how this works in practice, book a demo with the Coasty team at https://cal.com/coasty/15min .