The position, stated up front
That point is measurable, it arrives earlier than most teams expect, and it has nothing to do with how clever the model is.
What each one actually is
Robotic process automation executes a recorded sequence against a system. Click here, read that field, paste it there, submit. It is deterministic. Given the same screen, it does the same thing forever, which is exactly what you want for a step that never varies.
An agent is given an outcome and decides its own next action, using tools and retrieved context, then reads back the result. It is not deterministic. Given an ambiguous case, it makes a judgment call and records why.
Deterministic and non-deterministic are engineering properties, not marketing ones. One is easier to test and impossible to generalize. The other generalizes and has to be measured statistically. Neither property is better. They fit different steps.
The branch explosion
Here is the mechanism that decides the outcome, and it is arithmetic rather than opinion.
A process has a happy path and a set of variations. Invoice arrives, invoice matches the purchase order, invoice is posted. Now count the variations you have actually seen. Currency mismatch. Partial delivery. Line-item consolidation on the supplier’s side. A credit note issued against a paid invoice. A tolerance that differs by supplier. A tax line that only appears for one region. A supplier who changed their PDF layout last quarter.
A rules engine handles each of these with a branch. Every branch is a change request: someone specifies it, someone builds it, someone tests it, someone deploys it. Call that cost C per branch, and note that it recurs, because each branch also has to be regression-tested every time the underlying system changes.
Now the part that catches teams out. Variations do not arrive in proportion to volume. Volume grows with the business; variations grow with the number of counterparties, systems, regions and product lines you touch. Doubling invoice count adds throughput work. Adding one supplier with an unusual layout adds a branch.
So the maintenance line rises while the savings line flattens. Your automation is at its most profitable in month two and quietly loses ground from there. Nobody notices, because the cost shows up in a change-request backlog rather than on the automation’s own dashboard.
Named failure modes
Four, in the order we usually find them.
Agents fail too, in their own ways: they can be confidently wrong, their cost per task is variable, and they need an eval suite before you can trust a number about them. The difference is where the failures sit. A rules engine fails on inputs it has never seen. An agent handles the unseen input and can be wrong about it, which is why it reports confidence and escalates rather than deciding silently.
AI agents vs RPA, side by side
| Rules-based automation | Agent | |
|---|---|---|
| Instruction | A sequence of steps | An outcome and a boundary |
| Unseen input | Stops, or writes something wrong | Attempts a judgment, records confidence, escalates |
| Adding a variation | A change request and a deployment | Usually a context or policy update, sometimes nothing |
| Testability | Exact. The same input gives the same output | Statistical. Scored against an eval set |
| Cost shape | High fixed build, low marginal run | Lower fixed build, variable run cost per task |
| Best at | High-volume identical steps with a stable interface | Reading, deciding, and the variation between the steps |
| Worst at | Variation | Work with no ground truth to evaluate against |
Where the switch point sits
Three signals, any one of which means the arithmetic has already turned.
Do the sum with your own figures. Take the annual cost of maintaining the branches, add the loaded cost of the humans working the exception queue, and compare it against the hours the automation returns. Teams are often surprised by the second term, because exception handling is rarely tracked as automation cost. It is the automation’s cost. The exceptions exist because the automation drew a line.
Not a replacement. A different layer.
The reflexive answer is to rip out RPA and buy agents. That is usually wrong, and it is expensive.
Deterministic steps should stay deterministic. If a value has to be copied from one system to another and the mapping is fixed, use a script or an API call. An agent doing that is slower, costs more per run and introduces variance into a step that had none. We would rather delete an unnecessary agent than sell one.
What changes is the division of labor. Judgment moves to the agent; execution stays with the deterministic layer. The agent reads the messy input, decides what case this is, and then calls the same reliable tools your scripts already call. You keep the determinism where determinism is valuable and stop trying to express judgment as a decision tree.
That is the shape of every build we do in AI business process automation: agents for the reading and deciding, plain integrations for the acting, and an approval gate wherever the action is irreversible.
A migration order that does not break anything
If the arithmetic says switch, do it in this order. It keeps the working parts working while the judgment layer is proved.
The order matters because it front-loads the evidence. At every step you can stop, and the thing you already had still works. Compare that with a rewrite, where the payoff arrives only at the end and the fallback is a system you already switched off.
A worked example
Invoice matching, because everyone has it and it is where the branch explosion is most visible.
The rules version matches on invoice number, purchase order number and total. It works on the majority and throws the rest into a queue. The queue holds partial deliveries, consolidated lines, currency rounding, supplier credits and every layout the parser did not expect.
The Invoice Matching Agent approaches it from the other end. It reads the document as a document, finds the purchase order, reconciles at line level rather than on the total, applies the tolerance you set per supplier, and posts the match. When something falls outside tolerance it does not add it to a pile. It attaches what it checked, what it found and what it thinks the discrepancy is, then routes it to the person who owns that supplier.
The savings are not in the matches. Those were mostly automated already. The savings are in what happens to the ones that do not match, which is where the human hours actually sat.
One honest limit. If your tolerance rules genuinely differ by supplier and nobody has ever written them down, the first phase of that project is documenting them with your finance team, not building anything. That work is unglamorous and it is the difference between an agent that is right and one that is plausible.
The short version
- RPA is excellent at repeating an identical step and structurally poor at absorbing variation.
- The cost that kills it is branch maintenance, which grows with counterparties rather than volume.
- Switch when the exception rate stops falling, the change backlog outpaces new variations, or nobody will touch the automation.
- Keep the deterministic layer. Move judgment to the agent and let it call your existing reliable tools.
- Neither approach helps if the process rules only exist in someone’s head.
Keep reading
- Multi-agent orchestration, explained with a beehive - How several small agents split a process that one script used to own.
- How to choose the first process to hand to an agent - A scoring method for picking the candidate that will actually pay.
- Questions, answered - Cost, safety, timelines and what stays human.
