I wrote a post on this blog back in 2019 explaining the difference between RPA, machine learning, and AI. At the time I described RPA as the brawn and machine learning as the brains. RPA would handle the clicking and dragging, machine learning (ML) would read the documents, and the two would hand work back and forth. That was the accepted model of the day, and I believed it.
Seven years later I think the model was wrong, and not in a small way. RPA did not turn out to be the brawn of an intelligent system. It turned out to be the part that breaks first.
I want to be fair to it. Robotic process automation solved a real problem for a while. If you had a stable, rule-based task that crossed two or three systems, a bot could click through it faster than a person and never get bored. For a narrow band of work, that was genuinely useful. The trouble is that almost no real business process stays inside that narrow band for long.
RPA automates the steps, not the judgment. A bot is a recording of a human's clicks, hardened into a script. It does exactly what it was told, in exactly the order it was told, against exactly the screen it was trained on. That is its whole nature, and it is also its fatal flaw.
Change a field label, move a button, push a vendor portal update overnight, introduce a new document layout, change a rule at quarter close, and the bot stops. It does not adapt. It does not reason about what changed. It throws an exception and waits for a developer. Multiply that across hundreds of automations and you get the pattern every operations leader has lived through. The bots that were supposed to remove labor end up generating a new kind of labor: the team that keeps the bots alive.
This is why so many automation programs stall after the pilot. McKinsey has noted that roughly two-thirds of automation initiatives fail to scale because the underlying operating model never actually changed. RPA is the clearest example of that failure. You automated the clicks. You did not change anything about how the work understands itself. The first time reality drifted from the recording, you were back to manual, plus a maintenance bill.
I'd put it bluntly. RPA was automation with no comprehension. It could move work through a process. It could not understand the process, the document, or the decision the work existed to make. That gap is where it died.
The thing that replaced RPA is not a faster bot. It is a different kind of worker. AI agents with tool use, paired with modern UI automation, do the job RPA was always sold as doing, and they do it because they start from understanding rather than from a recording.
Two capabilities matter here.
The first is tool use. A modern agent does not just click through a screen. It can call an API, query a system of record, retrieve a document, post a result, and decide which of those actions the situation calls for. When a clean integration exists, the agent uses it. The work runs straight through, no fragile screen-scraping involved.
The second is UI automation done with judgment. Plenty of the systems a real workflow touches have no usable API. The old answer was a brittle RPA recording. The modern answer is an agent that can operate the interface the way a person would, but with one critical difference. It is reading and reasoning about what is on the screen, not blindly replaying coordinates. When the layout shifts, it adapts instead of crashing. UI automation stops being a liability and becomes a fallback the agent reaches for only when it needs to.
Put those together and the brittle handoff I described in 2019 disappears. There is no longer a dumb bot waiting on a smart model to feed it. There is one agent that understands the document, decides what to do, and acts across whatever systems the process requires.
Here is the part I most want to correct from my old post. I treated document understanding as a step that machine learning bolts onto the front of an RPA process. It is not a step. It is the foundation. If the system does not understand the invoice, the claim, the loan file, or the medical record in front of it, nothing downstream is real automation. It is just faster guessing.
This is why our own approach at KnowledgeLake starts with the AI doing the comprehension, not the clicking. Intuitive AI is our document engine, and it uses an ensemble of techniques rather than betting everything on one model. Computer vision, neural networks, language models, and traditional machine learning each get used where they are actually the right tool for the job. The agent layer then orchestrates the work: classify the document, extract the fields, decide what is certain and what is not, and route accordingly.
That last point is where modern automation earns trust, and where RPA never could. A bot has no concept of doubt. It is equally confident when it is right and when it is about to make a mess. An agent grounded in real document intelligence knows the difference. An invoice number that comes back at 98 percent confidence passes straight through. A vendor field at 62 percent routes to a human for a two-second check. The human is no longer babysitting bots. The human is resolving the small set of cases the system flagged as genuinely uncertain, and every one of those corrections makes the system smarter for the next document.
The deeper reason RPA failed is the same reason point automation tools keep failing today. Intelligence stuck onto a single task does not compound. It fragments. You end up with one bot that scrapes a screen, one model that reads a document, one script that posts a result, and a brittle chain of integrations holding them together. Every link is a place to break.
Agents change the economics only when they run on a platform that gives them grounding: the data, the workflow, and the audit trail in one place. That is the difference between automation that gets stronger every quarter and automation that needs a standing repair crew. AI compounds on a platform. It fragments on a patchwork.
So I'll update what I wrote in 2019. RPA was not the brawn of an intelligent system. It was a stopgap we used while the actual technology caught up. The actual technology is here now. It understands the work before it touches the work, it adapts instead of breaking, and it knows when to ask for help.
If you are still running a maintenance team to keep yesterday's bots alive, I think it is worth rethinking the whole model rather than patching it again. I'm always glad to compare notes on what that shift looks like in practice.