How to Pilot Computer Use Agents Alongside Your Existing RPA

The RPA problem you actually face today

Most enterprises start with traditional RPA to automate repeatable, stable tasks. That works well when the source application is fixed and the steps are deterministic. But every enterprise has a set of processes that live in the cracks. A request form that sits in a legacy ERP, a support ticket routed through a Citrix desktop, or a manual approval that depends on a human reading a notification. When you try to wrap these with RPA, you quickly hit three consistent pain points.

Selectors and xpaths are brittle

RPA works by binding controls to selectors, xpaths, and object IDs. If the UI changes, those bindings break. A new version of the ERP, a theme update, or even a localized change in a dropdown can take a bot offline. Enterprise surveys consistently show that 30 to 40 percent of RPA maintenance time goes into fixing selector-related failures. A single UI change can trigger a cascade of rebuilds across dozens of bots. The longer you stay on pure RPA, the more you pay to keep bots alive instead of building new ones.

Rebuild-on-change is expensive

When a bot fails, your team either fixes the selectors or rebuilds the workflow. Rebuilding is time-consuming. It requires a developer to re-analyze the UI, update the workflow, and test against the new version. If the process lives in multiple applications or environments, you may need to repeat the work for each target. The TCO of a bot that needs frequent rebuilds can double or triple over three years. You end up with a maintenance treadmill that limits your ability to scale automation across the enterprise.

Standard operating procedures are already prompts

Many processes are documented as plain-English SOPs. A human reads the document, interprets the steps, and acts. RPA cannot read an SOP. It needs a detailed flowchart or a developer-written workflow that encodes every decision. This gap is where the process either succeeds or stalls. If the SOP is vague, the bot will fail. If the workflow is too detailed, it becomes hard to keep it in sync with the actual process. You have two choices: force the process to match the bot, or force the bot to match the process. Neither option scales.

Halt-on-exception vs recover

Traditional RPA bots are designed to run smoothly. They are not built for the messy reality of enterprise work. If they encounter an unexpected dialog, a missing field, or a validation error, they stop. An alert goes to a developer, who must diagnose and restart the bot. This exception handling cost adds up. In many organizations, 20 to 30 percent of total automation effort is spent on exception management. A bot that halts on error is a liability, not an asset.

What changes with computer use agents

• Agents see the screen like a human does. They can read dialogs, read form fields, and verify outcomes.
• No brittle selectors. The agent works with whatever is visible, so it survives UI updates and version changes.
• Exception recovery built in. If an unexpected state appears, the agent can reason about the next step, retry, or ask for guidance.
• SOPs become executable. A plain-English procedure can be fed directly to the agent, removing the need for flowcharts.
• Works across legacy systems, Citrix, and virtualized desktops where traditional RPA struggles to reach.

How to move without the risk

You do not have to choose between RPA and agents. A pragmatic pilot lets you expand your automation coverage without upending existing investments. Follow this phased approach to run both in parallel.

Step 1: pick the right candidate process

Look for processes that sit at the intersection of high pain and high automation potential. These are processes that are currently manual or handled by a fragile RPA bot, live in legacy or virtualized environments, and have a clear SOP. Examples include data entry from scanned documents, ticket routing based on human review, or approval workflows that depend on reading email or portal notifications. These are the processes where RPA breaks and where agents can show clear value.

Step 2: define the SOP

Take the existing SOP and make it explicit. Break it down into discrete, observable steps. Use language that is unambiguous about what to look for and what decision to make. For example, instead of “check for approval,” specify “look for an approval button, click it, and confirm the status message says approved.” A clear SOP becomes the agent’s input. It also becomes a checklist for process owners to validate that the current human workflow is sound.

Step 3: run a parallel pilot

Deploy the agent alongside the existing RPA bot or manual process. Run the same volume of transactions and compare outcomes. Measure uptime, exception rates, and the time to complete each transaction. You will likely see fewer selector-related failures and more graceful handling of edge cases. The agent can also detect new patterns in exceptions that your current bot never saw, giving you data to improve the overall process.

Step 4: evaluate and expand

After a defined period, evaluate the pilot against your enterprise automation goals. If the agent demonstrates sustained uptime and lower exception handling effort, expand it to related processes. Continue to use RPA for high-volume, stable, backend tasks where it remains the most efficient choice. Over time, you will shift more of the long-tail, changing workflows to agents while keeping your core RPA estate healthy.