AI agents vs RPA
RPA runs fixed scripted steps in UIs and APIs. AI agents use judgement within agreed limits on a world model. When each fits, and when to combine them.
RPA runs fixed, scripted steps across user interfaces and APIs. AI agents pursue a goal with judgement inside limits the team agreed, working from a model of the business. They answer different questions. RPA is right when the path is known and stable. Agents are right when the path depends on context that changes, and when the next step has to be chosen rather than replayed.
Mixing the two up is common. Teams point an agent at a brittle UI path and call it automation, or they expect RPA to handle exceptions that need reading across systems. Below is a plain split, when each fits, when to combine them and how we approach the choice at Ortelian. For how agents differ from chat tools, see agentic vs generative AI.
What RPA does
Robotic process automation follows a script. A bot clicks, types, copies and calls APIs in a fixed order. The input shape is expected. The output shape is expected. When a screen moves, a field is renamed or an exception appears that the script did not cover, the bot stops or takes the wrong branch.
RPA is strong at high volume, repeatable work with clear rules: moving data between systems that lack a clean API, filling the same form thousands of times, kicking off a known sequence after a trigger. It does not need a picture of the company. It needs a stable path through the tools.
What AI agents do
An AI agent is given a goal and limits, then works toward that goal over several steps. It reads, decides what to do next, uses tools and stops or escalates when the case falls outside its limits. The useful ones do not get a person's full login. They get scoped tools, and anything that leaves the company or cannot be undone waits for a person. Approvals and control for AI agents covers that design.
Agents need context that no single screen holds. Which of two similarly named customers is this invoice about? Is last year's discount policy still in force? Did the shipment that should match this order already arrive under a different reference? That picture comes from a world model for knowledge work, and for one job the agent gets a context graph cut to what that job needs. Without it, agents guess confidently.
AI agents vs RPA at a glance
| RPA | AI agents | |
|---|---|---|
| What it follows | A fixed script of UI or API steps | A goal, with judgement inside agreed limits |
| What it needs | Stable screens, fields and rules | A current model of the business, scoped tools, a written standard |
| Handles change | Breaks when the path changes | Chooses the next step when the case varies within limits |
| Best on | High volume, repeatable, known path | Context heavy work with exceptions and investigation |
| Failure mode | Fragile when UIs or fields move | Wrong when the map of the business is missing or the limits are vague |
| Typical output | The same sequence completed | A result that meets a standard, with sources and a record |
When RPA is the right tool
Choose RPA when the path is known end to end, the systems are stable enough to script, volume is high and exceptions are rare or easy to park for a person. Classic fits include bulk data entry between two systems, generating the same report file every night from a fixed query and repeating a known click path that nobody should do by hand.
Do not stretch RPA into judgement work. If every other case needs a person to interpret an email, reconcile three documents or decide which policy applies, a script will either stop constantly or encode guesses that go wrong quietly.
When an AI agent is the right tool
Choose an agent when the work needs judgement within limits: matching documents that should agree but do not always, preparing a plan from capacity, orders and recent changes, researching an account across CRM, email and outside sources, or building a report that has to explain what moved and why. The agent investigates, proposes and acts where the consequence allows. People keep the decisions that cannot be undone.
Agents only earn that role after the work is redesigned and the standard is agreed on real examples, including the messy ones. Pointing an agent at the current process makes the waste faster. Pointing it at tools without a world model makes the guesses fluent. Both are common reasons agents fail in production.
When to combine them
Many companies need both. An agent decides what should happen. RPA (or a plain API call) executes a fixed step once that decision is clear. Example from operations: an agent matches invoices, orders and delivery notes. Matches that agree move on. Mismatches go to a person with the evidence. A payment step, if it is a fixed posting into the ERP after approval, can be a scripted action or an API write. The agent does not need to drive the ERP UI for that. See AI agents for operations for jobs like this.
The rule of thumb: if the step has a fixed input and a fixed output, keep it software or RPA. If it needs judgement within limits, give it to an agent. If it leaves the company or cannot be undone, keep a person in the loop.
What usually goes wrong
| Mistake | What happens | Better approach |
|---|---|---|
| Replace RPA with an agent on the same click path | You pay for a model to replay a script, and UIs still break the run | Keep RPA or an API for the fixed path |
| Expect RPA to handle exceptions that need reading across systems | The bot parks everything or encodes bad branches | Agent for investigation, person for the hard calls |
| Give an agent a person's login to "just use the UI" | Security blocks it, or nobody can say what it can do | Scoped tools, separate read and write, recorded runs |
| Skip the standard because the agent "will figure it out" | Nobody can tell if production is good | Agree quality, cost, time and human effort on real examples first |
| Automate the process as it stands | Waste gets faster | Redesign what belongs to software, agents and people |
How we choose at Ortelian
Ortelian is a platform plus a forward deployed team for knowledge work that depends on context no single system holds. We are not an RPA vendor. In the audit of about two weeks on site, we map the work and split steps: fixed path to software or existing automation, judgement within limits to agents, approvals and direction to people. Then we build in two-week cycles against a written standard. After launch, your team runs it or we keep running it. The platform is hosted in the EU.
If your main need is stable, high volume click paths with little judgement, an RPA specialist is the better shortlist. If the constraint is context heavy work that spans systems and outside sources, start from how we work and how to deploy AI agents in an enterprise.
Questions people ask
Are AI agents replacing RPA?
Not for fixed, high volume paths. Agents replace (or sit above) the judgement and investigation that scripts never handled well. Many deployments keep RPA or APIs for the last mile once the decision is clear.
Can an AI agent do what my RPA bot does?
It can drive similar tools, but that is usually the wrong design. If the path is fixed, a script or API is cheaper and clearer. Use the agent where the next step depends on reading the case.
Do AI agents need a world model if RPA does not?
Yes for most company work. RPA follows a path. Agents choose a path, so they need one identity per thing, current facts with sources and a task-scoped view. That is the world model and context graph split.
Is screen scraping with a language model the same as RPA?
No. A model reading a screen still needs limits, a standard and a record of what it did. Without those, you have a fragile script with a probabilistic driver. Prefer APIs and scoped tools over open UI control.
Where does Ortelian fit?
We fit context heavy sales, operations and similar work where agents need a maintained model of the business. We do not sell RPA platforms. Where a fixed step already runs in RPA or should, we leave it there and put the agent on the judgement around it.
