AI agents vs RPA: what replaces what, and what to keep

The AI agents vs RPA debate is usually framed as one replacing the other. In practice, the honest answer is a sorting exercise. Robotic process automation is excellent at repeating a fixed sequence of clicks and keystrokes against a stable screen. It is terrible at anything that varies: a differently worded email, a new invoice layout, a decision that depends on context. Agents are the reverse: good at reading, deciding and coordinating; unnecessary, and more expensive, for a step that never changes.

This article gives you the criteria for sorting your existing bots into keep, wrap and replace, and the architecture that lets the two work together.

Why the agentic automation vs RPA question matters now

Most RPA estates built over the last decade share three problems. Bots break whenever a vendor changes a screen layout, so a team exists purely to repair them. Bots cannot handle exceptions, so the exception queue that the automation was meant to eliminate simply moved. And bots automate the mechanical part of a process while the judgement part, the reading, classifying and deciding, stayed with people.

Language models changed the third problem. An agent can read the email, classify the invoice and decide the route, which was precisely the part RPA could not do. That does not make the bot obsolete. If the last step is typing a validated result into a mainframe screen with no API, the bot is still the cheapest way to do it. What changes is who is in charge: the agent decides, the bot executes.

RPA vs AI agents: a side-by-side

The sorting rule: keep, wrap or replace

Keep the bot

Keep RPA where the step is fixed, the input is structured, the target system has no API, and the bot has been stable. Posting a validated journal into a legacy ERP screen, downloading a statement from a portal that offers nothing else, or filling a government form with known fields. These are mechanical steps and a bot does them reliably and cheaply. Do not rebuild them with an agent to be modern; you would pay more per run for a less deterministic result.

Wrap the bot

Wrap RPA where the mechanical step is fine but the surrounding process is not. The agent takes over intake, classification, validation and decision, then calls the bot as a tool with clean, structured inputs. The bot's exception rate falls because it no longer receives ambiguous work. This is the most common outcome and the cheapest to reach, because the bot itself does not change.

Replace the bot

Replace RPA where the bot exists only because nobody had an API, and an API now exists; where the bot scrapes a screen that changes often; or where the bot encodes decisions in a tangle of rules that nobody dares edit. An agent working through a proper tool contract is more robust and far easier to evaluate than a rule tree with a hundred branches. The tool layer is described in MCP explained.

Intelligent process automation: the combined architecture

The pattern that works has three layers. At the top, an orchestrator owns the process: its state, its retries, its waits for approval. In the middle, agents do the reading and deciding: extract fields, check policy, propose the action. At the bottom, execution tools do the work: APIs where they exist, RPA bots where they do not, each exposed to the agent as a scoped, typed tool with an idempotency key.

Two consequences follow. The bot becomes a function with a contract, which means it can be tested and replaced with an API later without touching the agent. And the agent never sees a screen, which means the safety properties, limits, gates, and audit, live in the orchestration layer rather than inside a bot script. The orchestration options are compared in AI agent orchestration, and the guardrails in How to build an AI agent that is safe to run unattended.

What RPA teams get wrong about agents, and vice versa

• Treating the model as a rule engine. Agents are probabilistic. They need evaluation suites and gates, not just test cases with expected clicks.
• Treating bots as legacy to be deleted. A stable bot into an API-less system is an asset. Wrap it.
• Pointing an agent at a screen. Computer-use models exist, but a screen is the most fragile, least auditable interface available. Use it only where no API or bot exists, and gate everything.
• Rebuilding the exception queue. If the agent escalates everything it is unsure about without investigating, you have moved the queue again. Escalations must arrive with a summary and a proposed action.
• Skipping the process map. RPA estates often have no current documentation. The agent build starts by mapping what the bots actually do today.

What happens to the RPA team

The people who built and repaired the bots know the systems better than anyone. In every estate we have worked on they become the owners of the tool contracts: they know which screen is stable, which portal times out at month end, which field the ERP silently truncates. That knowledge goes into the tool layer and the evaluation suite. Repair time falls because the agent stops sending bots malformed input, and the team's work shifts from patching selectors to reviewing exceptions and widening what the agent may do alone.

Measuring the change

The number RPA teams track is bot uptime. The number that matters after agents arrive is end-to-end completion without a human touch, per process, with exceptions counted rather than hidden. Add cost per completed case, since agents cost more per run than bots and must earn it through fewer exceptions and less repair time. The metric set is in How to measure an AI agent.

A worked example

A university ran admissions, fees and records on an ERP that had accumulated years of RPA bots: one downloaded bank statements, one posted fee receipts, several moved data between modules that had no integration. The bots broke each time the ERP was patched, and the exceptions, mismatched names, partial payments, unusual fee structures, went to a shared inbox.

Rather than rewrite the ERP, the modernisation added an API layer over the modules that mattered, replaced the bots that moved data between them, and kept the statement-download bot because the bank portal offered nothing better. An agent took over the exception inbox: reading the statement lines, matching to student records, proposing the posting, and gating anything ambiguous to the finance office with a summary. The university ERP modernisation case study describes the wider programme; the approach is the legacy-to-AI modernisation service.

Team and timeline

Sorting an RPA estate is a two-week exercise: a solutions architect and an AI engineer inventory each bot, its target system, its failure history and its exception volume, and classify it as keep, wrap or replace. That work fits a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build. The build that follows is typically a multi-agent system from $24,500 or ₹16 lakh, with API work priced under API development and integrations from $7,000 or ₹4.4 lakh where systems need a door. Where the underlying platform itself is the problem, the ReCore programme at $31,500 to $105,000 or more over eight to sixteen weeks covers modernisation without a rewrite. Prices are on the pricing page.

Before you start: a checklist

• Inventory every bot: target system, trigger, failure rate, repair hours per month
• Record the exception volume each bot generates and where exceptions go
• Check which target systems now have APIs that did not exist when the bot was built
• Classify each bot as keep, wrap or replace with a one-line reason
• Map the process around the bots, including the human judgement steps
• Define completion-without-touch per process as the success metric
• Decide which decisions remain human regardless of automation
• Plan idempotency for every bot exposed as a tool

Glossary

• RPA: robotic process automation; software bots that replay fixed UI or API steps
• Screen scraping: reading and typing into an application's interface instead of its API
• Intelligent process automation: agents handling judgement with bots or APIs handling execution
• Tool contract: the typed interface through which an agent calls a bot or API
• Exception queue: the work automation could not complete, routed to people
• Idempotency key: an identifier that stops a retried bot run from repeating a side effect

Related reading

10 business workflows that are ready for AI agents today lists the processes where wrapping RPA pays off fastest, Application modernisation vs rewrite covers the platform decision underneath, and Microsoft's Power Automate documentation is a primary source on what modern RPA tooling does and does not handle.

Keep the bots that are boring and stable, put an agent in charge of the judgement, and the exception queue finally starts to shrink.