We get asked to “replace our RPA with AI agents” reasonably often. It is usually the wrong framing, and the conversation that follows is one of the more useful ones we have with clients, so it is worth writing down.
Rule-based automation is not obsolete. For a large class of work it remains the correct answer, and swapping it for an agent makes the process slower, more expensive, and less predictable. But there is a specific and growing class of work where rules were never going to be enough, and that is where agents earn their keep.
The variable that decides it is variance.
The one question worth asking
For any task you are considering automating:
How much do the inputs vary, case to case?
That is it. Everything else follows.
Low variance. The input arrives in the same shape every time. Same fields, same format, same decision logic. A rule handles this perfectly, deterministically, at negligible cost per transaction, and it never surprises you. Do not put a language model on this. You would be paying inference costs and accepting non-determinism to solve a problem that arithmetic already solved.
High variance. The input is a customer’s email, a supplier’s PDF that is laid out differently every quarter, a claim with a narrative attached, a ticket where the actual problem is in paragraph three. Here rules have always struggled — not because RPA is bad, but because the number of cases is unbounded, so the number of rules is too. Teams end up with hundreds of branches, a maintenance burden nobody wants to own, and a fallback queue that quietly grows.
This is the space agents were built for. A model can read something it has not seen before and work out what it is, which is precisely what a rule cannot do.
Where each one breaks
The failure modes are opposites, and this matters for how you test.
RPA fails loudly and brittly. A field moves, a page changes, a format shifts, and the automation breaks. This is annoying but honest — it stops, someone gets an alert, someone fixes it. You know the moment it happens.
Agents fail quietly and plausibly. The agent handles the unfamiliar case, produces something reasonable-looking, and is wrong. Nothing raises an alert, because nothing crashed. This is a far more dangerous failure mode, and it is why agent work needs the machinery I keep going on about: grounding so the agent answers from real data, evaluation so you can detect quality regressions, and observability so you can reconstruct what it did.
If you take one thing from this: RPA needs monitoring, agents need evaluation. They are not the same discipline and the second one is much less mature in most organisations.
Cost per task, and why volume is part of the design
The economics differ by orders of magnitude and they push in opposite directions.
A rule executes for effectively nothing. Ten million transactions cost about the same as ten. An agent invocation involves model inference — pennies at most, but pennies that multiply, plus retrieval, plus retries when a tool call fails.
The consequence is not “agents are expensive”. It is that volume and variance interact:
- High volume, low variance — rules, unambiguously. Putting an agent here is the most expensive mistake in this space.
- Low volume, high variance — agents, comfortably. The per-task cost is irrelevant next to the human hours it replaces.
- High volume, high variance — the interesting case, and where the design work is. Usually: a cheap deterministic classifier at the front, rules for the majority that turn out to be routine, and the agent reserved for the tail that genuinely needs judgement.
That last pattern is the one we build most often, and it is not what people expect when they ask for an agent. It ends up being mostly conventional engineering with an agent at the point of difficulty — which is exactly the right shape.
The hybrid design, concretely
Take invoice processing, since almost everyone has some version of it.
The naive agentic design hands every invoice to an agent. It works, and it costs perhaps fifty times what it needs to, because the majority of invoices are from suppliers you have seen a hundred times in a format you already know.
The design we would actually build:
- Route deterministically. Known supplier, known template? Straight to the existing extraction rules. This is most of your volume and it should never touch a model.
- Agent on the tail. Unknown supplier, unusual layout, mismatched totals, an attached note explaining a partial delivery. The agent reads it, extracts to your schema, and reasons about the discrepancy.
- Confidence-gated handoff. The agent flags what it is unsure about rather than guessing. Low confidence routes to a human with the agent’s reasoning attached — which makes the human faster, not just involved.
- Feedback loop. Human corrections become evaluation cases. Patterns that recur often enough graduate into rules, moving volume from step 2 back to step 1 over time.
Note the direction of travel in step four. A well-designed hybrid gets cheaper as it learns, because recurring patterns migrate out of the expensive path. Systems that treat the agent as the destination rather than the exception handler do the opposite.
Where a human belongs
Not everywhere, and not nowhere. Both extremes fail.
Approval on every action produces a system your team routes around, because reviewing an agent’s work is often slower than doing the work. Approval on nothing means the project never gets signed off, and shouldn’t be.
The useful question: which decisions, if made wrongly, would cost you something you cannot easily undo? Money leaving the business. A commitment to a customer. A change to a system of record with no audit trail. Those points get a human. The rest do not need one.
This is a business conversation, not a technical one, and it is worth having explicitly with the people who own the risk — before the build, not during the launch review.
A short diagnostic
Before you decide anything, get the answers to these:
- What fraction of cases follow the common path? If it is above about 80%, your first move is better rules, not an agent.
- What does your current exception queue look like? That queue is your agent’s job description. If there isn’t one, you may not have a variance problem.
- What is the volume? It determines whether per-task cost is a rounding error or the whole business case.
- What is the cost of a wrong answer? Sets your guardrail and approval budget.
- Who will own the evaluation set? If the answer is nobody, the project will drift regardless of the technology.
The short version
Rules for the spine, agents for the exceptions, a human at the decisions that are expensive to get wrong, and an evaluation set so you can tell whether any of it is working.
Most clients end up with both technologies, and part of our job is being straight about which half of a process belongs to which — including telling you when the answer is that you do not need an agent at all. That conversation is cheaper than the alternative.
More on how we approach this on our AI agent development and workflow automation pages, or bring us a process and we will tell you which half is which.
info@xpergia.com 