A CFO asked me last quarter which one he should buy. He had an RPA licence renewal on his desk, a vendor pitching AI agents, and an IT team that wanted to write the whole thing in Python. My answer annoyed him: it depends on the process, and he probably needs all three. This post is the long version of that answer, with the questions we use on every engagement to decide.
If you want the short definitions first, our guide to what agentic AI is covers agents from the ground up, and what is intelligent automation covers how the pieces fit together. This one is for the moment after that, when you have a specific process in front of you and a budget to spend on it.
Three tools built for three different jobs
The easiest way to see the difference is to ask what each one follows when it runs. Traditional automation follows rules. RPA follows steps on a screen. An agent follows a goal. Almost everything else about them comes from that.
Traditional automation: rules you can read
By traditional automation I mean anything that runs on logic someone wrote down in advance. An ERP approval workflow. A nightly job that imports the bank feed. A stored procedure that posts accruals. An integration that moves orders from your storefront into your ledger through an API. The input arrives in a known shape, the logic is if-this-then-that, and the output is the same every time you run it.
Where it fits best
Structured data, stable rules, and systems that expose an API. Payroll calculations. GST return preparation from a ledger that is already clean. Scheduled reports. If you can write the rule on a whiteboard and it will still be true next year, write it as code. It is the cheapest option to run and the easiest one to explain to an auditor.
RPA: a script that drives a screen
Robotic process automation is software that operates other software the way a person would, through the user interface. It clicks, types, copies a value from one screen and pastes it into another. RPA exists because a lot of enterprise systems have no API, or have one that nobody in the building is allowed to touch. The bot follows a recorded or configured sequence. It has no idea what an invoice is. It knows the invoice number sits in a particular field on a particular screen.
Where it fits best
High-volume, repetitive work across legacy systems whose screens rarely change. Re-keying approved purchase orders from an old ERP into a newer one. Logging into a bank portal every morning to download statements. RPA is a bridge between systems that were never meant to talk to each other, and a good one as long as the ground on both sides stays still.
Agentic AI: a goal, a set of tools, and judgment
An agent gets a goal instead of a script. It has access to tools, which might be a document extraction model, an ERP API, a database query, or even an RPA bot, and it decides which ones to use and in what order. It can read unstructured input, reason about what it found, check that against other records, and hand anything it cannot resolve to a person along with the evidence.
Where it fits best
Messy inputs and processes full of exceptions. Invoices in forty layouts. Contracts with clauses nobody standardised. Customer emails that bundle a complaint, a change request, and a payment query into one paragraph. If your current process is "the system does part of it, and then someone works out the rest", that someone is usually the job an agent can take on.
What "judgment" means here
Nothing mystical. It means the agent can handle a case nobody wrote a rule for by working out what the rule would probably have been, and it can say how sure it is. When it is unsure, a well-built agent stops and asks. In practice, that second ability matters more than the first.
Side-by-side comparison
The table below is how I sketch the three options on a whiteboard when a client asks for the one-page version. Build times are what we typically see on a single workflow, and yours will vary with how tidy your systems are.
| What you are comparing | Traditional automation | RPA | Agentic AI |
|---|---|---|---|
| What it follows | Explicit rules and code | Recorded steps on a user interface | A goal, plus tools it chooses between |
| Input it handles | Structured data in a known format | Structured data shown on screens | Structured and unstructured, including scans, PDFs, and email |
| When something changes | Needs a code change | Breaks when a screen or field moves | Adapts to new formats within its guardrails |
| How it fails | Loudly, with an error | Stops mid-run, or types into the wrong field | Quietly, unless confidence is tracked and checked |
| Typical build time | Days to a few weeks | Two to six weeks per bot | Two to four weeks, then tuning on live data |
| Who maintains it | Developers | An RPA team or the vendor | An ops owner, with engineering support |
| Audit trail | Logs, fully deterministic | Step logs and screenshots | Reasoning trace plus a confidence score per field |
The four questions that decide it
Every process we scope goes through the same four questions. None of them mentions a vendor or a technology, which is the point. Answer them with a month of real data, and the right tool is usually obvious.
1. What does the input look like?
If the data is already rows in a database or fields in an API response, you don't need AI to read it. Use rules. If it lives on a screen in a system with no API, RPA can reach it. If it arrives as a PDF, a scan, an email body, or a photo of a delivery challan taken on someone's phone, neither rules nor bots can read it reliably, and that step belongs to an agent. Often the agent only needs to own the reading step, and plain automation takes over once the data is clean.
2. How many cases are exceptions?
Pull a month of transactions and count how many needed a person to step in. Our rough thresholds, from projects rather than any published study: below about 5%, rules and bots cope fine, and the leftovers go to a queue. Between 5% and 30%, you will spend more time writing and fixing exception rules than the automation saves. Above 30%, the exceptions are the process, and you need something that can reason about them.
Why exception rate matters more than volume
Vendors size automation by volume because volume makes the savings slide look good. Volume tells you the upside. The exception rate tells you whether you will ever collect it. I have seen a 200,000-invoice-a-year RPA programme deliver less than a 20,000-invoice agent rollout, because the RPA bots kicked a third of the work back to people.
3. How often does the process change?
Three kinds of change matter, and each one hurts a different tool. Screen changes break RPA. Every ERP upgrade, every portal redesign, every new mandatory field means someone re-records the bot. Rule changes hurt traditional automation, since each new GST notification or approval threshold is a code change and a release. Format changes, such as a vendor switching invoice templates, are what agents absorb best, because they read the document for meaning instead of by position.
4. What does a wrong answer cost?
A wrong number in an internal dashboard costs a correction email. A wrong number in a vendor payment is money you may never get back. The higher the cost of an error, the more you want deterministic checks wrapped around whatever does the reading, and a person reviewing anything uncertain. That holds for all three options, but it matters most with agents, because they are the ones making judgment calls.
Put deterministic checks around probabilistic reads
Our default pattern is simple. The agent reads and proposes. Rules verify. A person approves anything the rules or the confidence scores flag. The agent never gets to overrule arithmetic.
A small example
The agent extracts an invoice total of 1,18,000. A rule checks that it equals the sum of the line items plus tax. If it doesn't, the invoice goes to review, however confident the agent was about the number it read.
Put the four answers together and the choice usually looks like one of these.
Traditional automation
Inputs are structured, the rules fit on one page, and the systems have APIs. Cheapest to run, easiest to audit, and the right default whenever it fits.
A bot on the screen
You have to move structured data through a legacy system with no API, its screens change less than once a year, and exceptions stay under about 5%.
Agentic AI
Inputs are unstructured, exceptions are common, or the work means checking one document against several other records before anyone can act.
All three, per step
One process contains all three kinds of step. Map most finance and operations work honestly, and this is where you land.
What each option costs to run
Licence price is the number everyone compares and the one that matters least. The real cost of any automation is build plus maintenance plus the people who still handle what it can't.
Build cost is the small number
RPA looked cheap in the early years because the first bot was cheap. Record a process, deploy it, show the hours saved. The trouble came with bot number thirty, when every ERP patch meant a week of re-recording. Traditional automation has the opposite profile. It costs more developer time up front and then runs for years untouched, as long as the rules hold.
Maintenance is where the money goes
Agents cost more per transaction than either alternative, because every document goes through an extraction or language model. What they save is the maintenance and the exception handling. When a vendor changes its invoice layout, nobody needs to touch the agent. When a new exception type turns up, the agent either handles it or escalates it with context, instead of failing silently in a queue.
Ranges observed across PTAS DocPro and FinSuite engagements and RPA estate reviews. They are field observations, not published benchmarks, and they move with document variety, data quality, and how many systems expose an API.
Where each one breaks
Every automation fails eventually. What you want to know before you buy is how it fails, because that decides how much damage it does before anyone notices.
Traditional automation fails loudly
A rule that meets data it wasn't written for throws an error or drops the record into a reject file. That is annoying and also healthy. You find out the same day, and the fix is usually a small code change.
RPA fails when the screen moves
A bot that expects a button in one place and finds it somewhere else will stop, if you are lucky. If you are unlucky, it clicks the wrong thing and keeps going. The most expensive RPA incident I have seen came from a portal update that shifted two fields by one position. The bot posted reference numbers into the amount column for a whole morning before anyone spotted it.
Agents fail quietly unless you design for it
An agent that misreads a field doesn't crash. It returns a plausible wrong answer. That is the real risk with agentic AI, and it is manageable, but only if you build for it from the first day rather than bolting it on after an incident.
Guardrails that do the work
Confidence scores on every extracted field, with a threshold below which the item goes to a person. Cross-checks against a second source, like the PO or the vendor master, before anything is posted. A full trace of what the agent read, what it compared, and why it decided what it did. And a hard rule that the agent proposes and a system of record approves, so a single bad read can never move money by itself.
On replacing your bots. If an RPA bot has run for two years with almost no incidents, leave it alone. The case for agents is strongest where bots are already struggling: high exception queues, constant re-recording, documents the bot was never able to read. Start there, and let the stable bots keep working.
On confidence scores. Ask any agent vendor to show you per-field confidence on your own documents, and what happens below the threshold. If the answer is a single accuracy percentage for the whole document, you will not be able to build a safe review queue on it, and your auditors will not be able to trace a decision back to its source.
Most teams end up running all three
Once you map a real process step by step, the " which one" question mostly goes away. Different steps want different tools. Here is how a vendor invoice usually flows in the AP teams we work with.
A worked example: from vendor invoice to payment
Step 1: intake
Traditional automation. A mailbox rule and an SFTP pull route every incoming invoice into one queue with a timestamp. No intelligence required, and none wanted.
Step 2: read and validate
An agent. Agentic document extraction reads the invoice whatever its layout, matches lines to the PO and goods receipt, checks the GST details, and flags anything it can't reconcile. This is the step that used to need a person, and it is where the six-way invoice matching checks live.
Step 3: Post to the ERP
An API call if the ERP has one. An RPA bot if it is a legacy system with no other way in. The agent hands over clean, validated fields, so the bot's job becomes simple enough that it rarely fails.
Step 4: payment run
Traditional automation again, with a person approving the batch. Scheduled, rule-based, and easy to audit.
Four steps and three kinds of automation, each doing the part it is good at. We walk through more patterns like this in our post on AI workflow automation.
Questions we get asked
Is agentic AI replacing RPA?
For some processes, yes. Where RPA bots were stretched to handle unstructured documents or frequent exceptions, agents do the job with far less upkeep. For stable, structured, screen-based work, RPA still does fine, and many agents call an RPA bot as one of their tools when a system has no API.
What is the difference between traditional automation and RPA?
Traditional automation works through code, APIs, and system rules, underneath the user interface. RPA works through the user interface itself, repeating the clicks and keystrokes a person would make. Teams use RPA when a system cannot be reached any other way.
Is agentic AI more expensive than RPA?
Per transaction, an agent usually costs more to run because it calls language and extraction models. Per process, it is often cheaper, because it handles the exceptions that would otherwise need people or extra bots, and it needs less rework when document formats change. Compare total cost including maintenance, not the licence price.
Can agentic AI and RPA work together?
Yes, and it is a common pattern. The agent does the reading and the judgment, then hands structured output to an RPA bot or an API that enters it into the target system. The bot keeps doing what it is good at, and the agent covers the documents the bot could never read.
How to pick your first project
Don't start with the tool. Pick one process that hurts, pull a month of real transactions, and answer the four questions for each step. You will probably find one step where the exceptions pile up and the input is a document. That is your first agent project. The steps around it can stay exactly as they are.
One opinion I hold firmly after a lot of these projects: don't pilot agentic AI on your cleanest process to play it safe. A clean process is already well served by rules, so the pilot will look unimpressive and prove nothing. Put the agent where the exceptions live, measure how many it clears, and let that number make the case.