Robotic Process Automation (RPA)
What vendors mean: bots that work like humans. What it actually means: a category that's being eaten alive by AI agents and is mid-pivot to stay relevant.
The Technical Definition
Robotic Process Automation is software that mimics human interactions with computer applications — clicking buttons, typing in fields, copying data between systems, processing structured forms. The bots run on the user-interface layer, which means they work with applications that have no API and no integration path. The category was defined by UiPath, Blue Prism, and Automation Anywhere in the late 2010s, with NICE, Pega, and Microsoft Power Automate also significant. The 2024-2026 reality is that these vendors are racing to rebrand around AI agents because the underlying RPA business is shrinking.
What This Actually Means for Your Business
If you have an RPA program — and most $100M+ companies do — you are in one of three places. You are quietly winding it down because the bots broke too often, the maintenance bill grew faster than the savings, and the AI team has a better answer. Or you are doubling down because RPA is delivering reliable value on rules-based, high-volume work and the alternative isn’t ready yet. Or you are pivoting your “RPA Center of Excellence” into an “Automation Center of Excellence” that includes AI agents and is figuring out what to do with the existing bot inventory.
Here is what the vendors are not advertising. Traditional RPA bots break. They break when the application UI changes, when the operating system updates, when a popup appears that the bot wasn’t trained to dismiss, when network latency causes a click to fire before the page loads. The brittleness is structural — the bot is interacting with pixels and DOM elements designed for humans, not for machines. Maintenance costs on production RPA estates routinely run 30-60% of the original development cost, every year. Some companies hit total cost of ownership crossover within two years.
What changed in 2024-2026 is that AI agents can do what RPA bots do, more flexibly, with more tolerance for change. An LLM-powered agent given access to a screen can see that a popup appeared, decide what to click, and continue. An RPA bot has to be reprogrammed. The agent is slower per transaction and more expensive per call, but the maintenance cost collapses. For workflows where the underlying applications change frequently or where the volume doesn’t justify deterministic optimization, agents win.
RPA still wins where it always did: high-volume, deterministic, narrow workflows on stable applications. Bank reconciliation runs at midnight on a system that hasn’t changed in eight years. Invoice posting from a single ERP. Mass field updates in a CRM. The bot pays for itself in months, runs reliably, and the maintenance cost is real but bounded. These deployments aren’t going anywhere.
The strategic question for CEOs is not “RPA or AI agents” but “what’s the right tool for this specific workflow,” with full TCO honest accounting, including maintenance and rework. The Centers of Excellence that started with that question are doing fine. The ones that started with “RPA-first” are now in awkward conversations with their boards.
Reality Check
What the vendor says: “Our intelligent automation platform combines RPA, AI, and agents in a unified experience.”
What that means in practice: They glued an LLM onto their existing bot platform and renamed it. Sometimes the integration is real and useful. Sometimes it’s marketing. The test is whether an agent inside the platform can actually do work the bot couldn’t, with logging and control, or whether it’s a chatbot that opens RPA bots — which is a worse experience than just running the bots.
What Operators Actually Do
Companies running RPA at scale audit their bot estate annually. Which bots are still adding value, which are deferred-maintenance liabilities, which workflows would benefit from being rebuilt as agents, which should just be moved to native API integration. The audit usually surfaces 15-30% of the bot inventory as candidates to retire, rebuild, or consolidate. The companies that don’t run this audit accumulate technical debt that compounds.
They also separate the core stable bots (the ones that should keep running) from the AI-eligible bots (the ones that would be better as agents) from the workflows that should be retired entirely. Treating the RPA estate as a portfolio rather than a one-way investment is the operational shift most companies miss.
The teams getting it right have stopped describing themselves as “the RPA team.” They are the automation team, and they are tool-agnostic. RPA is one tool. AI agents are another. Native API integration is a third. The choice between them is workflow-specific, not vendor-specific.
The Questions to Ask
-
What’s the maintenance cost of our current bot estate as a percentage of TCO? If you don’t know, get the number this quarter. It usually shocks people.
-
Which of our existing bots would be better as AI agents? The vendor should be willing to answer this honestly. If they’re defensive, they’re protecting the bot license revenue, not your operations.
-
What’s the failure mode and recovery story when a bot breaks? Bots break. The question is whether the failure is detected within minutes (good) or whether it runs for hours producing bad data before the operations team notices (bad).