By Laas Nury"Should we use RPA or AI for this?" comes up in almost every conversation about automation, and most of the articles that answer it were written before AI agents existed. The choice today has more options, and it is simpler than it looks: it depends on what the input looks like, how fixed the steps are, and whether the systems involved have a proper way in.
The short answer
- RPA (robotic process automation) is right when the input is structured, the steps are always the same and the screens rarely change.
- AI (reading and classifying) is right when the input is unstructured: e-mails, PDFs, scans, free text.
- AI agents are right when the steps themselves vary: the next action depends on what the previous one found, and the work involves matching, chasing and deciding within rules.
- An integration beats all three when the system has an API or a standard connector. Always check that first.
In practice, the best set-ups combine them.
What each one does
RPA is software that operates other software the way a person would: it clicks buttons, types into fields, copies values from one screen to another, following a script someone recorded or built. Tools such as UiPath and Microsoft Power Automate's desktop flows are the best-known examples. RPA is fast, exact and cheap per transaction. It is also literal: when a screen changes, a field moves or the input arrives in a different format, the script breaks.
AI for reading and classifying handles what a script cannot: an order written in the body of an e-mail, an invoice from a supplier you have never seen, a scanned delivery note, a customer complaint in free text. It recognises what the document is and extracts the data. Software that does this for documents is often called intelligent document processing (IDP). It reads well, but it does not decide what happens next.
AI agents add the deciding. An agent works towards a goal within limits: it reads, looks things up in your systems, decides the next step, carries it out, checks the result and escalates what it is not allowed to decide. That makes it suited to work where the path varies from case to case. We explain agents in more detail in AI agents for business.
Side by side
| RPA | AI (reading, IDP) | AI agent | |
|---|---|---|---|
| Input it handles | Structured, predictable | Unstructured: e-mails, PDFs, scans, text | Both, plus changing situations |
| Steps | Fixed in advance | One step: read and extract | Decided per case, within limits |
| When things change | Breaks, needs a fix | Adapts to new layouts | Adapts, escalates what it cannot place |
| Checking the result | Easy: it either ran or failed | Confidence per field, spot checks | Log per decision, tests, samples |
| Typical cost profile | Licence per bot, plus maintenance when screens change | Per document or per page | A build, then running costs per volume |
| Weak spot | Change and variation | Deciding what to do with the data | Needs clear limits and good guardrails |
A decision tree per process
Walk through these questions for one process at a time:
- Does the system have an API or a standard connector? Then integrate. Do not build a robot that clicks through a screen when you can talk to the system directly. Continue with the questions below only for the parts where there is no such way in.
- Is the input unstructured (e-mails, PDFs, scans, free text)? Then you need AI to read it, whatever comes after.
- Are the steps after that always the same? Then a fixed workflow (an integration, or RPA where there is no API) does the rest. AI reads, the workflow posts.
- Does the next step depend on what the previous one found, or does the work involve matching, chasing or choosing between options within rules? Then an agent is worth it, with a person approving what cannot be undone.
- Is the volume low and the judgement high? Then none of the above. Give the person doing it a good assistant and leave it there.
Three examples
Purchase invoices in a fixed format from a handful of large suppliers, into an ERP without an API. Structured input, fixed steps, old system. RPA does this well, and cheaply.
Purchase invoices from two hundred suppliers, in every format, into an ERP with an API. Unstructured input, fixed steps after reading. AI reads the invoice, an integration posts it, and a person handles the invoices that do not match an order.
Keeping delivery dates on open purchase orders correct, based on supplier e-mails, portal updates and missing confirmations. Varying input and varying steps: match, update within a tolerance, chase the supplier, escalate the rest. That is agent work.
Why RPA projects disappoint, and what AI changes
The classic RPA problem is maintenance. A robot depends on screens that other people change: a software update, a new field, a supplier who changes their invoice layout. Each change means a repair, and a set of fifty robots can keep a team busy just keeping them running.
AI does not remove that problem everywhere, but it moves it. Reading with AI instead of fixed positions on a page means a new invoice layout is no longer a breakdown. And connecting through an API instead of a screen means an update to the screen no longer matters. The robots that remain are the ones for systems with no other way in.
If you already have RPA
You do not need to throw it away. Three steps usually bring the most value:
- List the robots that break most often and look at why. Changing input usually points to AI for reading; changing screens usually points to an integration.
- Put AI in front of the robots that choke on unstructured input, so the robot receives clean, structured data.
- Look for processes where people still sit between two robots, making the decisions the robots cannot. That is where an agent adds the most.
And if a robot has run for years without trouble, leave it alone. Stable, cheap and boring is exactly what automation is supposed to be.
