RPA replays a recorded sequence of clicks in a user interface and breaks the moment a form changes. An agent in an agentic workflow reads content — an email, a document, a ticket — and decides within set boundaries, routing exceptions to a human. They're two different mechanisms, and in practice they usually work together rather than replacing each other.
RPA in short: what it does, and where it stops being useful
RPA (Robotic Process Automation) is software that records and replays a sequence of user actions on an interface — clicks, data entry, copying values between systems. Gartner defines RPA tools as executing "if, then, else" logic on structured inputs, without understanding the content they process. A robot is fast and predictable right up until its environment changes — a new form layout, a different export format, an extra field in the source system. At that point the script no longer matches reality and the process stops, usually without telling whoever finds it what specifically broke.
Agentic workflow in short
An agentic workflow doesn't replay clicks — the agent reads the content of a ticket, an email, or a document and interprets it roughly the way a first-line human would. That's what makes it resilient to variation in form: a different sentence structure, an unusual phrasing, a missing field don't automatically mean failure. In exchange, the workflow needs explicit decision boundaries — unlike RPA, an agent doesn't stop itself when it hits something unusual; that has to be defined for it up front.
Side-by-side comparison
| Trait | RPA | Agentic workflow |
|---|---|---|
| How it works | replays a recorded sequence of clicks/actions | interprets content and decides within bounds |
| Input | structured data, fixed format | natural-language text, variable form |
| Resilience to UI change | low — a form change breaks the script | high — a change in phrasing rarely matters |
| Handling exceptions | stops with an error, goes to a review queue | recognizes the boundary and hands off with context |
| Upkeep cost | grows with changes in source systems | grows with new case types |
| Typical use cases | moving data between systems, reporting | ticket triage, lead qualification, reading documents |
When to combine RPA and an agent in one workflow
In practice the two rarely rule each other out. A common pattern: the agent reads content and makes the decision, while RPA does the mechanical part of the task — entering data into an accounting system, updating a CRM status, generating a document in a fixed format. In short: RPA executes, the agent decides. Separating those two roles is one reason it's worth designing the agentic workflow as its own layer before wiring up any specific tools.
Common pitfalls when migrating from RPA to an agent
- Copying the old script verbatim. An RPA script describes steps, not decision boundaries — trying to "translate" it for an agent usually skips the part that actually matters.
- No defined escalation threshold. Without an explicit rule, the agent starts guessing instead of handing off — exactly what an agentic workflow is meant to prevent.
- Treating the migration as a purely technical project. Most of the time goes into agreeing on business thresholds, not picking a framework.
An example: agent and RPA in invoice processing
An invoice arrives as a PDF attachment with a layout that varies by vendor and template. The agent reads the document, extracts the amount, purchase-order number, and due date, then matches them against the order in the system. If the numbers reconcile exactly, an RPA robot handles the mechanical part: entering the data into the accounting system in exactly the format that system expects. On a mismatch, the agent doesn't try to smooth it over — the case goes to accounting with the discrepancy highlighted. In this setup, RPA never sees the invoice content, only already-resolved data; the agent never touches the accounting system itself. Splitting the responsibility this way also makes testing easier — a failure is easier to trace to a specific layer.
How to get started
Before deciding whether a process needs RPA, an agent, or both, it's worth checking two things: whether the input is structured (RPA) or requires interpreting content (agent), and how often the environment the process runs in actually changes. If the answer to both is "structured and stable," building an agentic workflow is probably overkill — plain RPA is cheaper and faster.
Can an agent fully replace existing RPA robots? Rarely worth doing outright. Where RPA runs reliably on structured data, swapping it for an agent buys you nothing — a model's upkeep cost often exceeds a simple script's. It's worth adding an agent where a human is currently sitting in front of RPA, reading and interpreting content before the robot can act.
For more on the concept itself, see What Is an Agentic Workflow?, and for designing one step by step, read Designing an Agent Workflow for Ticket Handling.