From RPA to Agentic Automation: A Migration Path That Doesn't Break the Back Office

Most enterprises we work with own an RPA estate of 100–600 bots, built over a decade, automating everything from invoice entry to benefits enrollment. The estate works — until a vendor moves a button, a portal adds a captcha, or a PDF layout changes. Industry analyses consistently put unattended-bot maintenance at 25–40% of the original build cost per year, and the failure mode is silent: the bot doesn't crash, it clicks the wrong thing.

Agentic automation is the credible successor, but "rip out UiPath and deploy agents" is a plan for a very bad year. Here is the migration path we've now run at several large organizations, designed around a simple principle: replace bots in order of failure economics, not in order of excitement.

First, triage the estate#

Score every bot on two axes: fragility (breakage incidents per quarter, selector churn, screen-scraping depth) and variance (how often inputs deviate from the happy path — exception rates tell you this). That yields four quadrants with four different destinies:

• Low fragility, low variance — stable API-based bots doing deterministic work. Leave them alone. A working deterministic automation is cheaper and more auditable than any agent. This is typically 30–40% of the estate.
• High fragility, low variance — deterministic logic trapped behind screen scraping. These don't need intelligence; they need interfaces. Migrate them to API calls or workflow-engine steps. No LLM required.
• Low fragility, high variance — bots drowning in exception queues because reality has more cases than the flowchart did. This is the agentic sweet spot.
• High fragility, high variance — usually end-to-end processes glued together with three bots and a shared spreadsheet. These need process redesign before any technology decision.

The high-variance quadrants are where agents earn their inference bill. An LLM agent handles input variance natively: an invoice with a novel layout, an email requesting three things at once, a supplier form with fields in the wrong place. The deterministic bot's exception is the agent's Tuesday.

The interception layer: don't let agents click buttons#

The tempting migration is to give an agent the bot's job and the bot's method — computer-use models driving the same UIs. Resist this as the primary pattern. UI-driving agents inherit the fragility problem (now with added non-determinism) and multiply per-transaction cost. Screen-level agents are a fallback for systems that truly have no other interface, not an architecture.

Instead, build what we call an interception layer: a thin orchestration tier that owns the process, and treats both legacy bots and new agents as interchangeable workers behind a queue.

Work item → Orchestrator → route by confidence/type
              ├─ deterministic worker (API call, old bot)
              ├─ agent worker (LLM + tools, for variant cases)
              └─ human queue (exceptions, approvals)

Concretely: work items (invoices, cases, requests) land in a queue with a typed schema. The orchestrator routes each item — clean, structured items go to cheap deterministic workers; ambiguous or variant items go to agent workers equipped with tools (lookup_po, match_vendor, post_to_erp); items failing confidence thresholds go to humans. The legacy bot becomes just another worker you can retire per route, gradually, with a feature flag.

This gets you three things a big-bang replacement doesn't: rollback per route, A/B measurement of agent vs. bot on identical traffic, and an audit trail that doesn't care which worker type handled the item.

What the agent actually does: a worked example#

Accounts-payable exception handling is the canonical first agentic workload, because it's the exception queue of an existing automation. In a recent deployment for an industrial-equipment manufacturer, the flow looks like this:

1. The deterministic pipeline processes ~70% of invoices straight through (clean PO match, tolerances met).
2. The remaining 30% — mismatched quantities, missing PO references, price variances, multi-PO invoices — historically went to a 14-person exceptions team.
3. An agent now picks up each exception with tools to query the ERP, vendor master, goods-receipt records, and contract terms. It classifies the discrepancy, gathers evidence, and either resolves within policy (e.g., price variance under 2% with a valid contract escalator) or packages a recommendation with evidence links for human approval.

Results after six months: 68% of exceptions resolved autonomously within policy, average handling time for the remainder down from 26 minutes to 9 (because the agent's evidence package eliminates the research phase), and — the number the CFO cares about — early-payment discount capture up 31% because exceptions stopped aging past discount windows.

Note what made this safe: the agent's write scope was limited to within-policy resolutions with hard caps enforced in the tool layer, every action logged against the invoice record, and the approval workflow reused the existing delegation-of-authority matrix. Agentic automation succeeds when it plugs into existing governance, not when it routes around it.

Cost math you should run before migrating#

Agents cost more per transaction than bots — inference plus longer execution. The comparison that matters is cost per completed item, loaded: include bot maintenance amortization, exception-handling labor, and the cost of delay (missed discounts, SLA penalties). In the AP example, the bot path cost ~$0.11 per clean invoice and the agent path ~$0.58 per exception — against a human exception cost of ~$14. The blended economics were decisive, but only because routing kept the cheap path for cheap work. An estate migrated indiscriminately to agents would have tripled processing costs.

Sequencing the program#

A realistic enterprise roadmap: Quarter 1 — estate triage, build the orchestration/queue layer, wrap the top 3 systems' APIs as tools. Quarter 2 — first agentic workload on an exception queue (AP, claims intake, or order management), shadow-mode first, measured against the human baseline. Quarters 3–4 — expand routes, retire the most fragile 20% of bots, publish per-route dashboards of cost, autonomy rate, and intervention rate.

The end state isn't "no RPA." It's a process layer where deterministic automation does deterministic work, agents absorb variance, humans handle judgment — and any of the three can be swapped per route without a migration project. That composability, more than the intelligence, is what you're actually buying.