Kronehoefstraat 85
5612 HL Eindhoven
BTW NL863902509B01
RPA vs intelligent automation: what's the real difference?
qw
vc
mshm
.svg)
RPA runs a fixed script and stops the moment a process deviates from the pattern. Intelligent automation recognises that deviation, makes a decision within preset limits, and fixes the error itself, with a human weighing in when there's doubt.
Plenty of operations managers at Dutch SMEs say it with conviction: we already automate. An RPA script pulls the invoice from the inbox, fills in the template, and puts the file ready for review. As long as every document looks exactly like the last hundred, that works fine.
It goes wrong the moment something happens that the script never anticipated. A supplier changes its invoice format. A request is missing a required field. A file contains an exception nobody wrote down. The script stops, or worse, it carries on with the wrong data.
Then a person is back standing next to the automation instead of behind it. The time savings RPA promised leak away into the same exceptions the script couldn't handle. Anyone who sees that pattern a few times a week isn't working with automation. They're working with an extra check.
This piece shows exactly where that difference sits: what RPA does and doesn't do, what changes once automation starts making its own decisions, and the craft that comes with it. For a deeper look at what that means in practice at a Dutch SME: intelligent process automation for SMEs.
Robotic Process Automation is rule-based automation. A bot follows a fixed script: click here, copy that field, paste it there. IBM describes RPA as software that mimics human actions in an interface, step by step, without the system itself understanding what's in that field (IBM, 2025).
That makes RPA strong at exactly the tasks people have been frustrated by for years: retyping data between two systems, filling in a template, assembling a report from fixed sources. No decision needed, just repetition.
The limit sits at variation. Change the screen, the file format, or the order of steps, and the script breaks. RPA has no context. It follows the route that was written down, even when that route no longer holds. That's what separates RPA from broader IT automation, where systems talk to each other through an integration instead of through the interface: see also the difference between agentic automation and IT automation for that comparison.
That's not a shortcoming of the vendor. It's the design. RPA is built to repeat exactly, not to interpret. For stable, high-frequency tasks, that's exactly what you want. For a process full of exceptions, it's the wrong tool.
Think of a payroll process that sends the same fixed export to the same fixed destination every month, or a staffing agency pulling the same weekly hours overview from the same system. As long as the source, format, and destination don't change, RPA stays the simplest and cheapest option. The problem only starts once those three variables shift, and that happens more often in administrative, construction, and recruitment processes than on a factory line.
Intelligent automation combines rules with a layer that actually understands what's happening. At its core is agentic AI: a system that makes its own decision within preset limits, instead of just running through a script. IBM describes that as a system with 'agency': it can assess information, weigh a next step, and choose an action based on the goal and the available context (IBM, 2025).
The difference with RPA sits in that last piece. Where a script follows a fixed route, intelligent automation recognises when a file deviates from the pattern. If a field is missing, the system asks for it instead of getting stuck. If an amount is unexplainably off, it puts the case in front of a person instead of processing it anyway.
Deloitte Netherlands frames the distinction this way in its own comparison of RPA and intelligent process automation: RPA carries out tasks, intelligent automation learns from the tasks it carries out and becomes suited to a broader range of work as a result (Deloitte, 2025). That learning isn't a promise of magic, it's the result of a model trained on more patterns than a script could ever capture.
In practice that means: you deploy our approach to intelligent process automation once a process deviates often enough to make RPA unreliable. Not as a replacement for every script, but as the layer that takes over once the script gets stuck.
An agent that decides for itself isn't an off-the-shelf product. Before it goes live, we test its behaviour against a set of real and constructed cases: the evals. What does the system do with a duplicate invoice, a missing VAT number, a customer that appears twice in the system? Every outcome gets checked before the system is allowed loose on production data.
After that comes error handling: what happens when the system runs into something outside the tested cases. A well-designed agent recognises that situation, stops deciding, and puts the file in front of a person instead of continuing on a guess. That's what separates real craft from a demo that only works as long as nobody tries anything unusual.
Logging is the third piece: every decision the agent makes must be traceable afterwards. Why did the system choose this route, based on which data, and could a person have followed that choice? Without that traceability, an agent is a black box, and a black box has no place in a financial or operational process.
In practice that means a log per decision: the file that was assessed, the rule or model that determined the outcome, and the moment it happened. During an audit or a customer complaint, that log is the difference between 'we'll look into it' and 'we can show you right now'. That auditable trail is exactly what a standalone RPA script usually doesn't keep.
Gartner predicts more than 40% of agentic AI projects will be cancelled before the end of 2027, mostly at organisations that don't build in governance, error handling, and human oversight from the start (Gartner, 2025). That's not an argument against agentic automation, it's an argument for this craft before you go live.
The NIST AI Risk Management Framework describes the same discipline in four steps: identify the risks, map them, measure the system's behaviour, and keep governance in order (NIST, 2023). That's exactly where agents take over the real work without losing control.
Human-in-the-loop sounds like a compromise: the system can't fully handle it, so we add a person alongside it. That's the wrong reading. Human-in-the-loop is a design choice: you decide in advance which type of decision a person reviews, regardless of how well the system performs afterwards.
In practice that works with thresholds. An agent that recognises an invoice under 500 euros and matches it to a known supplier can post it independently. If the amount, the supplier, or the pattern deviates, the file goes to a person. Not because the system failed, but because that's where the line was deliberately drawn.
That threshold shifts over time, based on what the evals and the logging show. If the agent performs correctly for months on a given type of file, the threshold can move further out. If it performs worse than expected, the threshold moves back. Human-in-the-loop isn't a fixed fence, it's a setting you adjust based on evidence.
That's exactly the difference with a script you can only replace, never adjust. RPA has no threshold to shift: it works, or it doesn't. Intelligent automation gives you a dial between fully automatic and fully controlled, per process type.
The two approaches don't rule each other out. The question is per process: how much variation does it contain, and how costly is an error when it goes wrong. A process with fixed input and a low error cost stays a good fit for a script. A process with a lot of variation and a high error cost, like an application or approval process, calls for a system that can assess rather than just repeat.
RPA stays the right choice for a task that's run without exception for months: a fixed report, a simple data transfer between two systems that don't change. Don't replace that with something heavier just because you can.
It becomes the wrong choice once a team is structurally losing time to manually resolving exceptions the script can't handle. Forrester predicts fewer than 15% of companies actually turn on the agentic features in their automation suite (Forrester, 2025), often precisely because the foundation (evals, error handling, human-in-the-loop) is still missing. That's a choice you make deliberately, not something that happens on its own.
Want to take that step? It belongs in a bigger picture than a single process. Our clients typically set this up within a connected AI business brain, so the agent handling invoices today can take on the next process tomorrow, built on the same evals and logging.
RPA follows a fixed script and repeats the exact same steps, regardless of the situation. Intelligent automation assesses the situation first and then picks a route within preset limits. The first is rule-based, the second is decision-based.
Barely. An RPA script only recognises the steps it was built for. When a file deviates from that pattern, the script either stops or processes the wrong data. Exceptions still have to be resolved by hand afterwards.
Agentic automation is the underlying principle: a system that makes its own decisions within limits. AI agents are the concrete implementation of that, the digital workers that apply that principle to a specific process such as invoicing or file processing.
Not necessarily. For fixed, high-frequency tasks with no exceptions, RPA remains a solid choice. Intelligent automation comes in once a process has enough variation to make a script structurally unreliable.
RPA licenses are often cheaper per bot, but the cost of manually handling exceptions doesn't show up in that price. Intelligent automation requires a bigger upfront investment, in evals and design, but structurally saves on the work a script would otherwise dump on a person.
With evals: a set of real and constructed cases, including the tricky ones, against which the agent's behaviour is checked before going live. Only once the outcomes are consistently correct, and error handling catches the unexpected well, does the agent move to production.
Yes, at the points agreed in advance. Human-in-the-loop isn't a sign the system falls short, it's a deliberate threshold: below a certain amount or risk level the agent decides on its own, above it a person reviews.
RPA shows you where the repetition sits, but breaks the moment a process deviates. We build process automation that can actually handle exceptions, with evals and human-in-the-loop as standard.
See Intelligent Process Automation
.svg){kind=icon}