Every few months someone publishes a piece declaring that AI agents have killed robotic process automation. Why would you script a robot to click through screens when an agent can just work it out?
I understand the appeal of the argument. I also think anyone running a regulated operation should ignore it.
What each one is good at
An RPA robot does exactly what it was told, the same way, every time. Log in here, read this field, enter it there, save, log the result. It can't think. That is its great strength. It's predictable, it's cheap to run, it's fast, and you can prove to an auditor precisely what it will do because it can't do anything else.
An agent can reason. It can read a messy email, work out what the customer wants, decide which of four processes applies and handle the case that doesn't fit the rules. That's new and valuable. It's also slower, costs more per transaction, and won't always make the same decision twice.
So ask yourself which of those you want entering payment details into your core banking system.
The legacy problem hasn't gone anywhere
There's a practical point too. Agents act through tools, which usually means APIs. A lot of the systems that run regulated industries don't have them. The policy admin platform from 2004. The mainframe screen. The supplier portal with no integration. The desktop application that only works on one version of Windows.
RPA exists because of those systems. It's how you automate something that was never designed to be automated. An agent that needs to act in that world needs a robot to do it.
The pattern that works
The deployments I've seen succeed in regulated businesses don't choose between the two. They give each the job it's good at.
- The agent handles judgement. Reading unstructured input, classifying, deciding what should happen, dealing with exceptions.
- The robot handles execution. Carrying out the decision in the systems of record, through a scripted, tested, permissioned path.
- A person handles accountability. Approving at the points where the risk says a human should.
- An orchestration layer holds it together, and records every step from all three.
The agent never touches your core systems directly. It can only ask a robot to do one of a fixed list of things it's been approved to request. That gives you the flexibility of an agent with the control of a script. It's also a design your risk committee can understand, which matters more than most architects admit.
This is where UiPath, ETT's platform partner, has taken its platform: building agents and orchestration on top of its robots rather than replacing them, including deployments that run inside a client's own infrastructure. For regulated industries I think that's the right call.
If you already have an RPA estate
Then you're better placed than you might think.
You already have tested, governed connections into your hardest systems. You have credentials management, logging and a team that knows how your processes really work. Those are the expensive, slow things to build, and you've built them.
What most RPA estates lack is the front end of the process. The robot is fast, but a person still has to read the email, open the attachment and decide what to do before the robot can start. That's the gap an agent fills.
So don't write off what you've got. Get it assessed, find out which robots are solid and which are fragile, and work out where judgement is the bottleneck.
Sources: UiPath, agentic AI on Automation Suite for regulated and public sector · UiPath acquires WorkFusion