When a company starts looking at AI agents, someone usually asks what happens to the robotic process automation it already runs. The bots that copy invoice numbers from one screen to another, log in to a portal every morning and download a file, or key an order into a system that has no other way in. The question is framed as a contest, old technology against new. We think it is better framed as a question about interfaces.
The useful line between the two is not intelligence. It is whether the application has a door built for software.
RPA records or scripts what a person does on a screen: open this window, click this field, type this value, press save. It works on the surface of an application, the way a user would. It does not need the application's cooperation, which is its great virtue. A bot can drive a system that offers no integration at all.
An AI agent works through the application's own interfaces, its API, to read and change records, and uses judgment about what to do when a case does not match the pattern. It acts on the data underneath the screen, not on the screen itself.
Both can automate a task. They differ in what they depend on, and so in how they fail.
A click path depends on the layout of the screen. If a vendor moves a button, renames a field, adds a step to a login or changes a pop-up, the bot clicks the wrong thing or nothing at all. The failure is often silent: the bot reports success after clicking, and the record it was meant to create does not exist. The bot also logs in as a user, usually a shared account, so the application's own audit trail names a person who did not do the work.
An API call depends on a contract. The application promises that a certain request does a certain thing, and changes to it are announced and versioned. When a call fails, it fails with a message. The action is attributed to a named service identity, and the application's permissions apply to it as they would to any user.
None of this makes API-based automation foolproof. It makes the failures louder and the audit trail honest, which is most of what you want from automation that touches money or customer records.
Choose the interface first, and the technology follows.
If the application has an API for the action, use it. Whether the caller is a script, a workflow or an agent, the call goes through the door built for software. This is how the actions of a governed agent should reach your systems, with its own identity and limits.
If there is no API, use RPA as an adapter, narrowly. Keep the bot's scope small, give it its own account, log every run, and treat it as a temporary bridge with an owner and a review date. A bot that does one thing in one screen is manageable. A bot that spans a dozen screens is a maintenance bill.
Never put an agent on top of a click path. An agent's judgment is only as good as the actions it can take, and a brittle action under a clever decision maker is the worst of both. If the only way to act is a screen, the agent proposes and a bot or a person performs, with the gate in between.
Retire a bot when an API appears. Many applications have added interfaces since the bots were recorded. A yearly inventory finds the ones that can now go through the front door.
RPA has always been strongest on the happy path and weakest on the exception. A bot that meets a case it was not recorded for stops, or does the wrong thing, and a person is called. An agent can read the odd case, work out what is wanted and either handle it or put it in a queue with a good explanation. That is a real improvement, and it is why the two are not the same product.
The improvement applies only when the agent can act through a stable interface. We describe how this differs from a workflow that merely uses a language model for phrasing in agentic automation against workflow automation. The short version is that the system must choose the action, and for that the action must be available to choose.
Imagine a company with four bots, each recorded some years ago. One downloads a bank file each morning from a portal. One keys sales orders into a legacy order system with no integration. One copies payment confirmations from the accounting system into a spreadsheet. One updates shipment status in a supplier's web portal.
An inventory against the rule gives a clear answer. The accounting system has an API, so the third bot goes: a direct call replaces it and the spreadsheet disappears. The bank offers a file feed, so the first bot goes as well. The legacy order system and the supplier portal have no interface, so those two bots stay, narrowed and given owners, and each carries a review date.
Now suppose the company wants an agent to triage incoming orders. The agent reads the email, proposes the order lines and flags anything unusual. It does not drive the legacy screen. It hands a clean, checked order to the surviving bot, or to a person, and a gate sits between them for anything above a set value. Two bots remain where there were four, and the agent sits above clean interfaces.
A bridge bot needs more care than its size suggests, because it holds a login. Someone has to own the credential and rotate it, someone has to know which screen it drives and what the next version of that application will change, and someone has to read its run log each morning. Without those three, the bot is an unmanaged user with access to a system and nobody watching.
Plan for its retirement from the day it is built. Write down what would let it go, such as a vendor releasing an interface or a migration to another application, and put a date on the review. A bridge with an end date tends to be treated as a bridge. One without tends to become part of the architecture.
Write down every bot you run. Beside each, put the application it drives and one of three words: API exists, API in progress, or none. Anything marked API exists is a candidate to retire this quarter. Anything marked none is a bridge that needs an owner and a review date. If you do not know what bots you run, finding out is the first piece of work, because those bots hold credentials and move your data. Our case for building an agent layer over what you already run is in you do not need a new ERP to get agents.
We start with a no-risk discovery: we inventory your bots and scripts, mark which can move to an API and which stay as narrow bridges, and show how an agent would sit above them, and you pay for the discovery only if you go on. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations owns the bridge bots and their review dates.
Use the click path only where there is no door built for software.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
