Robotic process automation earned its reputation twice, and both reputations are getting in the way right now.
The first one was won around 2018, when RPA was the thing that finally automated the work sitting between systems that would not talk to each other. The second arrived a few years later, when the bots that had been quietly holding that work together started breaking every time a vendor shipped a new login page.
If you run an automation program in 2026, you are somewhere in the middle of that story with an estate you inherited, a maintenance bill you did not plan for, and a vendor roadmap that suddenly talks about agents instead of bots. This piece is about what RPA actually does, where it still beats an AI agent outright, and how to decide which parts of what you already have are worth keeping.
What Robotic Process Automation Actually Does
RPA is software that operates other software the way a person does.
That sentence is the whole category. A bot logs into an application, clicks the fields a person would click, copies a value out of one system and types it into another. It works at the interface layer, not the API layer, which is exactly why it took off: it automates systems that were never built to be automated, without asking anyone to change them.
Nothing about it is intelligent, and that was always the point. The bot follows a sequence you recorded or authored. Given the same screen, it does the same thing at 3am on a Sunday that it did at 11am on a Tuesday, and it produces an execution log you can hand to an auditor.
How RPA Works
Most implementations have three moving parts.
The bot is the script. It targets elements on a screen by position, label, or an internal selector, then performs actions against them in order.
The orchestrator is the control plane. It schedules bots, queues work items, hands them out to available runners, retries failures, and holds the credentials the bots use.
The runner is the machine the bot actually runs on, which is either a person's desktop for attended work or a virtual machine in your environment for unattended work.
Underneath all three is the assumption that carries the category: the screen will look the same tomorrow. Everything RPA does well and everything it does badly follows from that one bet.
Where RPA Still Wins
It is worth being precise about this, because the current market noise suggests the answer is nowhere. It is not.
Systems with no integration point. A mainframe green screen, a state government portal, a supplier's extranet, a desktop application from a vendor who will not build you an API. If there is no programmatic way in, a bot driving the interface is not a workaround, it is the only option.
High-volume, fixed-sequence work. Reconciling two ledgers, posting the same invoice format, moving records between systems on a schedule. When the process genuinely has one correct sequence and the volume is real, determinism is a feature. You want the same thing to happen every time.
Work that has to be auditable step by step. Regulated processes where somebody will eventually ask what happened on 14 March and expect an answer down to the field. A recorded sequence answers that question completely. A reasoning system answers it with a trace you have to interpret.
If a process matches all three, an AI agent is not an upgrade. It is a more expensive way to do something you already solved.
Where RPA Breaks
The failure mode is not dramatic, which is part of why it goes unmanaged for so long.
The screen changes. A vendor redesigns a portal, an internal team ships a UI refresh, a field moves. The selector the bot depends on stops resolving and the bot fails. Nothing was wrong with the logic. The world underneath it moved.
Exceptions pile up somewhere. Every process has cases that do not match the recorded path: a mismatched reference number, an unexpected pop-up, a supplier who sends the invoice as a scanned image. The bot cannot form a plan, so it stops, and the work lands in a queue that a person quietly works through. The savings model assumed that queue would be empty.
Maintenance compounds. One bot is a project. Eighty bots across fourteen applications, each with its own selectors and credentials and owner who has since changed teams, is an estate. The cost of keeping it running grows with the number of systems it touches, not with the value it produces.
This is also where the internet will offer you a statistic, and most of the popular ones do not hold up. The widely repeated "30 to 50% of RPA projects fail" figure traces to consulting-practice commentary rather than to any instrumented study, and the "63% missed their delivery deadlines" number comes from a Deloitte survey run in 2018. Neither tells you anything about your own estate. The number that does is much easier to get: count how many of your bots needed an unplanned fix in the last quarter, and how many hours that took.
RPA vs AI Agents: The Comparison That Matters Now
The old comparison in most RPA explainers is RPA against traditional back-end automation. That question was settled years ago. The live question is what happens when the thing driving the process can reason.
| RPA bot | AI agent | |
|---|---|---|
| Decides what to do | At design time, by the author | At runtime, from the input |
| Unfamiliar input | Stops, raises an exception | Forms a plan, which may be wrong |
| Unstructured input | Needs a parser bolted on | Handled natively |
| Auditability | Complete, step by step | Trace-level, needs interpretation |
| Cost per run | Flat and predictable | Varies with tokens and tool calls |
| Breaks when | The interface changes | The input falls outside what it was evaluated on |
| Best suited to | Stable screens, fixed sequences, volume | Judgment, interpretation, open-ended triage |
Read the last two rows together, because they are the decision. A bot fails loudly, in a specific place, on a change you can point at. An agent fails quietly and fluently, and you only find out through monitoring you had to build in advance.
That is why swapping one for the other wholesale is the wrong move in both directions. The useful framing is the same one that governs agentic workflow design generally: decide step by step which parts of a process get a fixed path and which parts get to reason. Most real processes need both, and the boundary between them is the architecture.
The 2026 Vendor Landscape
Gartner's 2025 Magic Quadrant for Robotic Process Automation, published on 23 June 2025, evaluated thirteen vendors: Appian, Automation Anywhere, EvoluteIQ, IBM, Laiye, Microsoft, Pegasystems, Salesforce, Samsung SDS, SAP, ServiceNow, SS&C Blue Prism and UiPath. That list is roughly the shortlist any enterprise buyer will be handed.
Two things in that report are worth more than the quadrant placement. The market generated $3.8 billion in revenue in 2024, up 18% year over year, which is healthy growth and not a category in collapse. And Gartner describes the market as being at a "pivotal inflection point", with AI introducing alternatives to deterministic RPA and broader orchestration platforms absorbing what used to be a standalone purchase.
The category leader's own numbers say the same thing more plainly. In the fiscal year ended 31 January 2026, UiPath reported revenue of $1.611 billion, up 13%, and annual recurring revenue of $1.853 billion, up 11%. Its positioning now leads with deterministic automation, agentic AI and orchestration on one platform rather than with bots. Forrester's Predictions 2026: Automation And Robotics, published in October 2025, forecasts the same convergence, with buyers forced to fit deterministic and cognitive automation into a single framework. Treat that as a forecast, because that is what it is.
The practical read for a buyer: you are no longer choosing an RPA tool. You are choosing an orchestration layer that happens to include RPA, and the question to ask a vendor is how the deterministic and reasoning halves hand work to each other. For how those layers stack, see our breakdown of enterprise automation.
What to Do With the RPA Estate You Already Have
Nobody rebuilds eighty bots. Sort them instead. Three buckets, and the test for each one takes about five minutes per bot.
Keep. The bot sits on a system that has not changed in two years, runs a fixed sequence, and has not needed an unplanned fix. Leave it alone. Replacing a working deterministic process with a probabilistic one is a downgrade dressed as modernization.
Wrap. The bot works on the happy path but generates an exception queue a person works through. The bot is not the problem here, the exception handling is. Put a reasoning layer in front of it to interpret the input, decide whether this case is handleable, and either hand a clean work item to the existing bot or route it to a human with the context attached. You keep the deterministic execution and you stop paying for the queue. This is the largest bucket in most estates and the cheapest win in it.
Retire. The bot's real job was always interpretation, and RPA was the only tool available at the time. Reading a supplier's emailed PDF, classifying an inbound request, pulling three fields out of prose a human wrote. These were never fixed sequences. They were judgment tasks wearing a recorded macro, and they are the honest candidates for replacement.
The order matters. Teams that start with the retire bucket end up rebuilding working infrastructure and calling it progress. Teams that start with the wrap bucket recover the maintenance hours first, which is what funds everything after it.
RPA is also not the only automation layer in the building. Scheduled data movement, ETL jobs and integration tooling overlap with it more than most inventories admit, so it is worth mapping data automation and the AI automation tooling already in use before assuming a bot is the only thing doing a given job.
Where RPA Shows Up by Function
The verticals matter less than the shape of the work, but the shape repeats predictably.
Finance and accounting is where most estates start: invoice posting, account reconciliation, statement generation. Fixed formats, high volume, a system of record with no useful API. Classic keep-bucket work, though anything that begins with reading a document a supplier wrote belongs in the wrap bucket. If that is where your volume sits, the patterns in finance AI chatbots and AI bookkeeping assistants are the reasoning half of the same problem.
Insurance runs bots across claims intake, policy administration and underwriting support. The intake side is almost entirely interpretation, which is why insurance answering services have moved toward agents while the downstream posting stays deterministic.
Healthcare uses RPA for eligibility checks, claims submission and record transfers between systems that will never integrate. Highly regulated, heavily audited, and one of the strongest remaining cases for a deterministic path. The broader picture is in our look at AI in healthcare.
Legal and professional services automate intake, conflict checks and document assembly, where the split between a fixed sequence and a judgment call is unusually clean. See how law firms automate workflows with AI agents.
Customer operations is where the boundary is most contested, because so much of the work starts as a sentence somebody typed. That is the part digital customer service has been rebuilding around reasoning rather than recorded steps.
Governance: The Part That Decides Whether Any of This Ships
An unattended bot holds credentials and acts with a person's permissions, continuously, with nobody watching. Most RPA governance failures are some version of that sentence going unexamined for two years.
Three things are worth confirming before you add anything, agent or bot, to the estate:
- Every automation has a named owner and its own service account. Not a shared account, and not a departed employee's login. When the owner changes teams, the automation is reassigned rather than orphaned.
- Credentials live in the orchestrator's vault, not in the automation. This is standard in every major RPA platform and routinely bypassed under deadline.
- Something is watching for silent failure. A bot that stops is obvious. An agent that quietly starts handling a case wrong is not, which is why trace-level visibility has to exist before the agent meets a customer rather than after.
That third point is where replacing a bot with an agent genuinely raises the bar. You are trading a system that fails loudly for one that fails fluently, and the monitoring has to be in place first. If you are formalizing this, our enterprise AI implementation guide covers the surrounding controls.
Where Voiceflow Fits
Voiceflow is not an RPA tool and does not try to be. What it addresses is the boundary this whole article is about: the place where a fixed sequence has to hand work to something that can reason, and take it back afterwards.
Two primitives do that work.
Workflows are deterministic. A directed graph of nodes with branching edges, executed in the order you author it. When predictability is the requirement, which is to say payment collection, identity verification, appointment booking, compliance disclosure, this is the right primitive and it behaves the way your existing bots behave.
Playbooks are the reasoning half. Each is a task-scoped sub-agent with its own instructions, tools and model, and the main agent routes to one based on its description. A playbook is what interprets the messy inbound case that would otherwise land in an exception queue.
The part that matters for an estate you already run is how they compose. A workflow can invoke a playbook mid-sequence, and a playbook can transfer control back to a workflow when the conversation enters regulated territory. The transfer preserves session variables and conversation history, so a case can be triaged by a reasoning agent, handed to a deterministic flow, and returned without losing state. That is the wrap bucket, implemented: the bot keeps doing the part it does well, and the interpretation it was never suited for happens before the work item reaches it.
On the monitoring point, every conversation is captured with a trace of which playbook was invoked, which knowledge source was referenced, and where the agent exercised judgment rather than following a fixed step. That is the visibility you give up when you replace an auditable bot, and getting it back is a precondition, not an enhancement. The wider view of how these pieces assemble is in our AI agent framework guide.
The Honest Summary
RPA was not a mistake and it is not finished. It solved one problem well, which was automating work across systems that would not integrate, and it kept solving it right up until the systems underneath it started moving.
What changed is not that bots got worse. It is that a second option appeared for the specific part bots were always weakest at, which is interpreting input nobody anticipated. The teams getting value out of this right now are not the ones replacing their estate. They are the ones who sorted it, kept what was stable, put reasoning in front of what was not, and stopped paying for exception queues they had been quietly staffing for years.
Book a demo if you want to talk through where that boundary sits in your own processes.
![Help Desk Automation: What to Automate and How to Measure It [2026]](/images/help-desk-automation-og.jpg)