By Stan Reshetnyk, CTO · Last updated 13 October 2026
If you already run RPA in production, the useful question is not “agents or scripts.” It is narrower: which of your bots are worth touching, what the ones you keep cost you, and how to add judgment without a rewrite. Start from restraint: most bots in a mature estate are not migration candidates. A bot that runs reliably on structured input is doing its job, and swapping it for a probabilistic component buys risk with no return. The candidates are the bots collecting “just one more exception rule” because the input keeps drifting. (For the definitions, start with our primer on what AI agents actually automate.)
Key takeaways
- Triage before you migrate. A mature estate sorts into four buckets and only one is an agent candidate: leave alone, replace with an API, retire, or add judgment in front.
- The exception queue is the strongest signal. It is staffed by people already doing the interpretation the bot can’t, which makes it both candidate and specification.
- Measure your own maintenance bill. The figures in circulation mostly trace to vendor blogs; what matters is your engineer-hours and exception-queue headcount.
- You are trading failure modes, not removing them. RPA fails loudly and stops; an agent can fail quietly and continue, which needs monitoring that answers “was it right?”
- Hybrid beats rewrite. An interpretation layer feeding validated instructions to the bot you already trust bounds your blast radius to what that bot could already do.
If you hold the budget rather than maintain the bots, read the maintenance framing and the sequencing plan.
Which of your existing RPA bots are actually migration candidates?
Start from the bot’s change history, not from what it does: has its rule count been growing, and why? A bot whose logic has been stable for a year, on input that arrives in a fixed shape, is not a candidate. A bot that has accumulated exception branch after exception branch is telling you its input keeps arriving in shapes the rules never anticipated, and the team keeps patching rules instead of addressing interpretation.
That only makes it a candidate if the drift is in the input’s meaning rather than its presentation. Presentation drift — the screen moved, the template changed — is fixed by a stable interface, not by an agent driving the same brittle UI. Meaning drift is when three suppliers use the “reason code” field three different ways and a human has to read the thing to know what it is.
So a mature estate sorts into four buckets, not two:
- Leave alone — stable input, stable rules, working.
- Replace with a real integration — the bot exists because nobody built the API.
- Retire — the upstream process changed and the bot automates a step nobody needs.
- Put judgment in front of it — meaning drifts, rules can’t keep up, and a human is already doing the reading.
The strongest single signal is the exception queue, and most plans overlook it because it never registers as a failure. If a bot completes 82% of runs and drops 18% into a queue a person clears by reading and deciding, that person is already doing the judgment step by hand, every day. The queue is both the clearest candidate in your estate and a specification: a log of what a competent person already did.
What is RPA actually costing you to maintain right now?
Almost every number you will be shown in this conversation is unreliable. When we traced the widely-quoted RPA-maintenance statistics — the maintenance-per-licence-dollar multipliers, the bot-failure and weekly-breakage percentages — the trail ended at vendor and content-marketing blogs with no primary source. Discount any pitch built on them, including a pitch for agents.
The one non-vendor source we could verify is a Stanford paper on automating enterprise work with foundation models. Read it precisely: “Through case studies of a hospital and large B2B enterprise, we find that the adoption of RPA has been inhibited by high set-up costs (12-18 months), unreliable execution (60% initial accuracy), and burdensome maintenance (requiring multiple FTEs)” (Wornow et al., arXiv 2405.03710). Those are findings from two organisations, not a measurement of RPA in general, the paper does not define what “initial accuracy” counts, it dates from May 2024, and its authors go on to propose a foundation-model alternative of their own — so they are not a disinterested source. Directional at best, and not a business case for your estate.
Your own numbers are better, and all three come from systems you already run: engineer-hours logged against bot fixes over the last two quarters, the standing cost of keeping the estate alive rather than the licence line; headcount clearing exception queues, in FTE rather than estimated; and releases in upstream systems that forced a bot change, which is your coupling number. High coupling argues for an interface; a large exception queue argues for judgment.
Which failure would you rather operate — brittleness or nondeterminism?
This tradeoff gets skipped. It is not a choice between a risky option and a safe one, but a swap of one operational risk for a structurally different one.
RPA usually fails brittly and loudly: a selector stops resolving, the bot stops, the queue backs up, someone gets paged. Often nothing wrong reaches a customer, because nothing happened — though that is the typical case rather than a guarantee, and a bot that dies midway through a multi-step sequence can leave a half-committed state that is worse than either outcome. An agent fails differently: handed an input it misreads, it proceeds on a wrong interpretation, returns a plausible result, and your monitoring reports a successful run.
So the monitoring changes instrument. RPA observability answers did it run; an agent estate needs observability that answers was it right — sampled human review, agreement rates against the people who used to clear the queue, drift alerts on the agent’s own decisions. Nobody owns that instrument on day one. The shape is familiar to us from real-time video, where “is the stream connected?” and “is the call watchable?” need different toolchains, and teams that build only the first hear from users that the product is broken while the dashboards stay green.
The test strategy changes too. An RPA suite asserts equality; an agent can return two acceptable answers to one input, so equality assertions either fail constantly or test nothing. What replaces them is an evaluation set of real labelled cases, scored on every change.
What does a hybrid RPA and AI agent architecture actually look like?
The pattern that works is a layer, not a replacement. The agent sits in front of the estate and does one job: read the messy input, make the interpretation call, and emit a clean, schema-validated instruction. The existing bot or integration then executes it exactly as it always did.
That containment is the whole argument for hybrid over rewrite: if the agent can only emit instructions your executor already accepts, your blast radius stays bounded by what that executor could already do. A model limited to filling a validated payload cannot invent a new action against your system of record. A model given a browser and your credentials can.
Be precise about that bound, because it is easy to oversell. A schema validates form, not intent: it rejects a malformed instruction and happily passes a well-formed one with the wrong values in it. An agent reading untrusted input is exactly what an attacker aims at — an invoice PDF carrying text that tells the agent to route the payment elsewhere produces a perfectly valid instruction. So the real bound is the executor’s privilege set, usually wider than the task: a bot that can post any journal entry gives you a blast radius of any journal entry, not this one. What closes that gap is not the schema but authorization on the parameters — amount ceilings, allow-listed payees — plus treating anything the agent read as data, never as instructions. And “still reversible” holds only where the action has a rollback; a sent email or a filed submission does not.
Three design rules make the bound real. The agent never touches the system of record; it emits a typed instruction and the deterministic layer commits it, keeping credentials, retries and rollback where they already live. The contract between layers is an explicit schema, so anything failing validation never reaches the executor. And that boundary is where the human checkpoint belongs — the one point where the decision is fully materialised and still reversible.
We have built both halves of this shape, though never as a migration. In our Chambiar workforce-automation build, every tool call the model produced was validated against the target platform’s schema before execution — added after early incidents where a malformed call surfaced only as an API error the user had already been waiting on. Same contract, one honest difference: there the agent called the APIs itself rather than handing an instruction to a separate executor. Eska’s leasing pipeline shows the routing half, scoring risk from contracts read by OCR and NLP and routing cases for approval rather than committing them blind. Neither is a migration — both were new pipelines with no bot estate to retrofit — and we have no published case study of a judgment layer retrofitted in front of someone else’s bot fleet.
Sanity-checking a hybrid design before you commit engineering to it? That schema boundary is where most of the risk gets decided, and it is the first thing we scope on an AI agent engagement.
What breaks in your audit trail when a deterministic bot becomes a probabilistic agent?
A rules-engine bot’s audit trail records steps taken: opened this record, copied this field, wrote this value. It is complete because it is exhaustive, and trustworthy because replaying the input reproduces the steps. Both properties disappear when the layer making the call becomes probabilistic, and a longer log does not restore them.
An agent’s record has to capture four different things: what it saw, including the context retrieved to interpret it; what it concluded and how confidently; who owned the outcome, named and timestamped, whether they approved, overrode or were only notified; and which version of the system decided — model version, prompt version, and the snapshot of the knowledge base it read from.
That last item is the concrete replacement for reproducibility. You can no longer promise an auditor that replaying the input reproduces the decision — a model update or a changed retrieval index will legitimately change the answer. What you can promise is a record that explains the decision under the configuration that made it, so pin those versions or the explanation is unfalsifiable. The confidence-tier pattern that carries this, with the approver logged per tier, is the one we work through in our playbook on building an AI admin co-worker.
How do you sequence an RPA-to-agent migration without a big-bang rewrite?
Pick one workflow from bucket four, with the highest exception-queue volume and the lowest per-case stakes you can find. Volume gives you evidence quickly; low stakes means the first quarter’s misreads cost you rework rather than a customer or a regulator. Then run it in the order that costs nothing to be wrong about.
- Shadow mode, against the exception queue only. The agent reads cases a human is about to clear anyway and records what it would have done; nobody acts on its output. That yields an agreement rate against a competent human and, more valuable, the labelled eval set every later change depends on — at zero production risk.
- Draft-and-approve where agreement is already high: the agent emits the validated instruction, a person releases it, the executor is untouched. Then auto-complete per case type, not per workflow, and only where the data earns it. Leave every other bot alone for the duration.
Anthropic’s engineering guidance points the same way on sequencing: “Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short” (Anthropic, Building Effective Agents). Worth being precise about what that post is comparing: its “workflows” are “systems where LLMs and tools are orchestrated through predefined code paths” — LLM pipelines, not RPA. So it is not a verdict on your bot estate. The transferable part is the direction of travel: add autonomy only where a simpler, more predictable construction has actually fallen short, and make the evaluation the thing that tells you.
Where Trembit fits
We build the judgment layer and the engineering around it: schema boundaries, confidence routing, eval suites, audit records. Where the honest answer is “this bot needs an API, not an agent,” that integration work is something we do too — the recommendation isn’t a referral elsewhere. What we bring to it is 50+ production builds in video and voice, on a team whose founders have worked on real-time systems together since 2009, where “it usually works” was never an acceptable standard. We have no published RPA-estate migration case study, and say so above rather than dress one up.
If you have an RPA estate and a mandate to “do something with AI,” the next step is a triage, not a project. Book a free 30-minute call with one of our engineers — get in touch and bring your bot inventory, your exception-queue volumes, and the workflow leadership is pointing at. We will sort the estate into the four buckets, name the workflow that makes a defensible pilot, and tell you plainly if the answer is an API instead of an agent build. No deck, no pitch, no obligation.
Frequently asked questions
Should we replace our RPA platform entirely with AI agents? Almost certainly not. Deterministic execution on structured input is what RPA is good at, and an agent is a worse tool for it: less predictable, harder to audit, more expensive to monitor. Keep the executor layer you trust and add judgment only where the input was never clean enough for a rules engine.
Can an AI agent use our existing RPA bots instead of replacing them? Yes, and that is where we would start — it is the hybrid shape above. The agent reads the messy input and emits a structured, validated instruction; the existing bot executes it unchanged. That is safer than handing a model a browser session, but the bound is the executor’s privilege set, not the schema, so put the authorization on the parameters. (What agents do and don’t automate covers the capability question underneath this one.)
Is an AI agent cheaper to maintain than an RPA bot? We would not claim that in general, and any figure offered to that effect deserves a source check. The cost changes shape: less rule-editing after upstream changes, more ownership of an eval suite, correctness monitoring and review capacity for escalated cases.
Does RPA still have a place if we adopt agents? Yes, and in a typical estate it keeps the larger share of the work. Every deterministic step after the interpretation is better executed by something rules-based and repeatable. The realistic end state is not an agent fleet, but a few judgment layers in front of a mostly unchanged set of bots.
