Most companies asking whether to adopt AI agents aren't starting from zero. They already have robotic process automation (RPA) running somewhere, in finance, in claims processing, in data entry between systems that were never designed to talk to each other. The real question is rarely "RPA or AI agents." It is which parts of an existing automation footprint are candidates for an agent layer, which should stay exactly as they are, and how the two should work together rather than compete.
This guide is for the COO or VP of Operations who already has RPA in production and is deciding what to do next, not the team evaluating automation for the first time. For a broader look at what an AI agent is and how it differs structurally from a chatbot or RPA script, see VOLO's definition guide to AI agents. This piece focuses on choosing an automation approach for a specific workflow; for the broader question of whether an existing system needs replacing at all before AI can be added to it, see VOLO's guide to the legacy system myth.
Why This Decision Comes Up Now
RPA was built for a specific job: repeating a fixed sequence of steps reliably, at scale. It does that job well when the process is stable, and the inputs are predictable. It does that job badly the moment either condition breaks down, which is a major reason RPA has a documented failure pattern. Industry estimates commonlycited by EY put the RPA project failure rate at 30% to 50%, and the reasons behind that failure rate are consistent across sources: processes that looked stable at the pilot stage turn out to have more exceptions and variants than expected, and a screen-scraping bot built around one version of a system's UI breaks the moment that UI changes.
None of this means RPA was a bad investment. It means RPA has a scope, and companies running into its edges are usually running into a structural limit, not an implementation mistake.
What Breaks When RPA Hits Its Limits
There are 3 consistent signs that a process has outgrown what RPA can reliably handle:
- The exception rate keeps climbing. RPA tooling generally treats anything above a 20% exception rate as a sign the process was a poor automation candidate to begin with. If a bot's fallback queue keeps growing because more cases need a human decision than the bot can resolve on its own, that queue is a strong candidate for an agent layer, not for a bigger bot.
- The process depends on judgment, not just steps. RPA scripts execute the same sequence regardless of context. The moment a process requires weighing two valid options, evaluating whether a document is legitimate rather than just present, or matching one record against another using more than an exact-match rule, RPA is being asked to do something it was not built to do.
- Every system update becomes a maintenance event. A bot built around screen scraping breaks when the underlying application's interface changes. If a team spends more time fixing broken bots after routine software updates than the bots save in labor, that is a sign the automation approach, not just the specific bot, needs reconsidering.
Where RPA Still Wins
It is worth being direct about this, since a lot of AI vendor content quietly implies RPA is obsolete: for genuinely stable, rules-based, high-volume processes, RPA remains the cheaper and more predictable option. A well-scoped RPA bot handling structured data entry with a low exception rate does not need the added complexity, cost, or evaluation overhead of an agent. Replacing working RPA with an agent for its own sake adds engineering and monitoring work without adding value.
A Practical Decision Table
What Migration Actually Involves
Moving a workflow from RPA to an agent is not a drop-in replacement, and treating it as one is a common source of failed migrations. A few realities worth planning around:
- The evaluation burden is different, not smaller. RPA testing confirms a script executes the same steps correctly every time. Agent testing has to confirm the system behaves reasonably across a wide range of inputs it has not seen before, which takes more design and testing effort up front.
- Existing process documentation is a starting point, not a finished spec. RPA implementations are often built around a process definition document describing the happy path. An agent needs that same process understood in more depth, including the exceptions and edge cases that were previously routed to a human queue rather than documented as decision logic.
- The two can and often should coexist. A common, practical pattern is not full replacement: an existing RPA bot keeps executing the deterministic steps of a process. At the same time, an agent layer sits at the point where the bot would otherwise fail or hand off to a person, handling the judgment call and then returning a structured result the rest of the process can use. This tends to be cheaper and lower-risk than a full rebuild, since it leaves the parts of the system that already work untouched.
Where to Go From Here
Deciding between RPA and AI agents is really a workflow-by-workflow decision, not a single company-wide choice, which is why the decision table above is meant to be applied process by process rather than as a blanket policy. For a full walkthrough of how AI agent projects get scoped and where they fit into a broader AI implementation strategy, seeVOLO's guide to enterprise AI implementation. VOLO's AI services team works on exactly this kind of integration, connecting agent capabilities to existing automation and legacy systems rather than requiring a full rebuild.
If you are trying to work out whether a specific workflow is an RPA problem or an agent problem,book a consultation with VOLO to walk through it.
