RPA, intelligent automation and agentic automation compared

Three terms, one distinction

These three terms are used loosely, which makes buying decisions harder than they need to be. The useful distinction is how much judgement the software is expected to exercise. RPA follows rules. Intelligent automation follows rules and uses AI for the steps that rules cannot handle. Agentic automation is given a goal and decides the steps itself, within limits you set.

More judgement brings more flexibility. It also brings less predictability, more testing and more oversight. The right choice is the simplest option that does the job.

RPA: software that follows the rules exactly

Robotic process automation (RPA) is software that performs the clicks, keystrokes and data transfers a person would otherwise do, following a fixed script. It suits work that is high in volume, repetitive and stable: the inputs are structured, the rules can be written down, and the screens or interfaces seldom change. It is also a practical way to connect older systems that have no modern interface.

RPA fails when its assumptions break. A changed screen layout, an unexpected format or a case the rules did not foresee will stop a bot or, worse, let it carry on wrongly. It cannot read a scanned letter or decide what an ambiguous email means.

A great deal of business work is rule-based, though, and for that work RPA or ordinary system integration is enough. No AI is needed, and adding it only adds uncertainty and things to maintain. For one of the largest used-car dealers in the United States, we automated high-volume, high-frequency bidding on UiPath and C#, and bidding now runs in near real time.

• Structured inputs
• Rules that can be written down
• High volume, low variation
• Stable screens and systems

Intelligent automation: rules plus AI where needed

Intelligent automation keeps the rule-based workflow and adds AI at specific steps: reading documents, extracting fields from unstructured text, classifying requests, recognising handwriting, predicting which cases need review. People still design the process and it still runs in a fixed order. AI handles the parts where the input is messy.

It suits processes that are mostly routine and are blocked by one or two steps that need reading or interpretation: invoices in many layouts, forms filled in by hand, emails that must be sorted before anything else can happen. For an Indian bank, we built automated processing of physical mandates and other money-transfer forms that reads handwritten text in Indian regional languages.

It fails when the AI step is trusted without checks. Models can return wrong answers with apparent confidence. You need thresholds, a route to a person for low-confidence cases, and monitoring, because accuracy can drift as documents and behaviour change.

• A mostly rule-based flow
• Unstructured inputs at certain steps
• Confidence thresholds and human review
• Ongoing accuracy monitoring

Agentic automation: software that plans its own steps

In agentic automation, an AI model is given a goal, a set of tools it may use and limits on what it may do. It works out the steps, calls the tools, checks the results and adjusts. Nobody scripts the path in advance.

It suits work where the steps vary from case to case and cannot sensibly be listed: researching a query across several sources, handling a customer request that could go many ways, investigating why two records disagree.

It fails in ways the other two do not. An agent can take a plausible wrong path, repeat itself, or act on a misread instruction. Results can differ between runs on the same input, which makes testing and audit harder. It needs narrow permissions, a log of every action, limits on scope, and human approval for anything that moves money, changes records or reaches a customer.

• Variable, multi-step work
• Narrow tool permissions
• A log of every action
• Human approval for consequential actions

How to choose

Start from the work and take these tests in order. Stop at the first one that fits.

If every step can be written as a rule and the inputs are structured, use RPA, or a direct integration between the systems where one is available. If the flow is fixed and some steps need reading, classifying or predicting, use intelligent automation and put AI only at those steps. If the steps themselves change from case to case, so that no fixed flow covers them, consider an agent with strong limits.

Then weigh the cost of a mistake. Where an error is expensive or hard to reverse, prefer the more predictable option and keep a person in the loop, even if that means automating less.

• Rules cover everything: RPA or integration
• Fixed flow, messy inputs: intelligent automation
• Variable steps: an agent, with limits
• Costly errors: more predictability, more review

Most real processes use more than one

Treat the three as layers. A single process often uses all of them. A scripted bot moves data between systems. An AI step reads the incoming documents. An agent handles the small set of exceptions that fit no rule, and passes the hardest to a person. Designing it this way keeps the predictable parts simple and testable and confines the uncertain parts to where they earn their place.

It also gives you a sensible order of work. Automate the rule-based core first. Measure the exceptions that remain. Add AI only to the exception types that are frequent enough to justify it.

Checks before you commit

Whatever the approach, a few checks apply. Name an owner for the process and a separate owner for the automation. Decide what happens when it fails: who is told, and how the work gets done by hand in the meantime. Agree how you will know it is working, with a baseline taken before the build. Confirm that the data it handles is covered by your privacy and compliance requirements, and involve your security team early.

For anything with an AI step, add a test set of real cases, including awkward ones, and rerun it after every change.

• A named owner for process and automation
• A manual fallback
• A baseline measured before the build
• A test set of real cases

What to do next

Pick one process and write out its steps. Mark each step as rule-based, needing interpretation, or variable. That marking tells you which approach each part needs. Start with the rule-based steps, measure the exceptions, and add AI only where the numbers justify it.