Enterprise

Unattended RPA Bots and the 3AM Pager: How AI Agents Change On-Call

Emily Watson||7 min
Ctrl+A

You have a batch process running at 3am. The process finishes, but the downstream team never gets the file. You pull open the logs and see a cryptic error: selector not found. The UI changed two weeks ago, and the bot never got rebuilt. Now the on-call engineer is manually downloading files while the rest of the team sleeps. This is the reality of brittle unattended RPA in a fast-moving enterprise.

The fragility of selector-based bots

Traditional unattended RPA works by binding to hardcoded selectors, xpaths, object IDs, and relative coordinates. Every time a UI refresh, a CSS class change, or a layout shift occurs, the bot fails. A Gartner report estimates that around 30 percent of RPA maintenance hours are spent on rebinding broken selectors. For high-volume, stable backend tasks, that cost is manageable. For processes that touch frequently updated web portals, CRMs, or legacy apps, it becomes a nightly on-call burden.

Rebuild-on-every-change versus adapt and recover

When a bot breaks, the RPA team either pauses the process and rebuilds the flow or patches it with workarounds. Both approaches require developer time, testing, and validation. The patch cycle introduces risk because dev teams often prioritize stable flows and deprioritize the pain point. Over a year, a single process can trigger dozens of rebuilds. Each rebuild is a chance for new bugs, regressions, and configuration drift. The on-call engineer ends up managing a running list of fragile bots instead of designing new automation.

Why computer use agents change the on-call model

  • Computer use agents see the screen like a human and act by moving the mouse, clicking, typing, and reading the result. When the UI changes, the agent recalculates coordinates and continues instead of halting.
  • No brittle selectors. The agent does not rely on fixed IDs or xpaths, so UI updates and layout shifts do not break the flow.
  • Agents recover from exceptions and unexpected states. If a popup appears or a field is disabled, the agent can recognize the situation, take a corrective action, and retry instead of stopping.
  • SOPs written in plain English become direct instructions. Agents follow the steps as written, so you do not need to translate workflows into proprietary bot logic.
  • Agents can work across any application, including legacy systems, Citrix desktops, and virtualized environments where traditional RPA struggles.

Agents adapt to change instead of breaking; you trade selector maintenance for an on-call story that stays stable.

A pragmatic migration path

You do not need to rip out all unattended RPA at once. Start by identifying one high-pain, SOP-driven process that breaks frequently due to UI changes. Use the original SOP as the pilot specification. Deploy a computer use agent to validate that it can follow the steps accurately. Measure how often the agent recovers from exceptions versus how many times a human had to intervene. If the agent maintains accuracy and reduces incident volume, expand to adjacent processes. Reserve traditional RPA for stable, high-volume backend tasks where selector-based approaches remain efficient. This phased approach lets you capture value while keeping mature automation in place.

The on-call story you want

With computer use agents, the 3am pager often becomes a false alarm. The process runs autonomously, agents adapt to layout changes, and recovery happens without human intervention. Your on-call engineers can focus on improving automation strategy instead of babysitting fragile bots. This is the durable automation model for enterprises that rely on reliable unattended processes.

Ready to see how AI agents can transform your on-call story? Book a demo with the Coasty team to explore a pilot for your highest-pain process.

Want to see this in action?

View Case Studies
Try Coasty Free