What a decade of RPA taught us about agents

UiPath announced its results for the year to 31 January 2026 on 11 March, and described itself in the first line of the release as a global leader in agentic automation. Revenue for the year was $1.611bn, up 13%. Annualised renewal run-rate reached $1.853bn, up 11%, with net new ARR of $186m and a dollar-based net retention rate of 107%. The company reached full-year profitability on a GAAP basis for the first time in its history.

Those are the numbers of a maturing infrastructure business, not an insurgent one. Net retention at 107% means the average existing customer spent seven per cent more than last year, which is expansion, but modest expansion. A company genuinely riding a new product cycle does not post that figure.

What the release says about the product is more interesting than what it says about growth. The chief executive’s quote frames the strategy as bringing deterministic automation, agentic AI and enterprise-grade orchestration onto a single platform, so that the company provides the execution layer for mission-critical processes. Strip the marketing and there is a real claim: agents need something underneath them that behaves the same way every time.

That claim is the answer to the question in the headline. What carries over from a decade of robotic process automation is the substrate, the operations and the credential problem. What does not carry over is the business case.

The technical carry-over is narrower than the vendors imply

RPA’s limits were catalogued plainly in NHS England’s national guidance of May 2022, and the authorship is worth stating before the content is used. The foreword records that the guidance carries Atos on its foreword alongside the NHS Transformation Directorate, and Atos sells automation delivery, so this is not a document written by a party with nothing at stake. Read with that in view, the guidance still sets out what software robots can and cannot do, and the cannot list is short, precise and against interest. They cannot read handwritten or scanned paper documents. They cannot process unstructured data such as emails, images, video or audio. They cannot work on systems, applications or websites that continually change user interface. And they cannot reach a judgement of any kind without machine learning alongside them.

Language models close two of those four. Unstructured input is now tractable, and an interface that moves is no longer automatically fatal, because the system can be told what it is looking for rather than where it is on the screen.

But look at what closing them costs. The reason a robot broke when a screen moved is the same reason you could certify its behaviour: it did precisely one thing. A system that can adapt to a screen it has not seen cannot be enumerated in advance, and the assurance method has to change from a test suite to an evaluation regime. Organisations that bought RPA because it was auditable, which in regulated sectors was most of them, are being offered a replacement that solves their maintenance problem by reintroducing the uncertainty they were avoiding.

The honest framing is a trade, not an upgrade. You are exchanging brittleness for unpredictability. Whether that is a good trade depends entirely on which of the two your regulator finds easier to forgive.

The operational carry-over is the valuable part

Everything an automation programme learned about running things it did not write applies unchanged.

Start with identity. Every RPA estate accumulated service accounts, because a robot needs credentials to log into the systems it drives, and those credentials belong to nobody. They were issued once, rarely rotated and frequently over-privileged, and every mature programme eventually had a painful year in which the identity team took them back.

The National Cyber Security Centre’s May 2026 guidance on agentic systems reads, in this respect, like a memorandum from that year. Apply least privilege and give agents only the minimum access they need for the shortest time required. Constrain what an agent can access, what actions it can take and when. Avoid long-lived credentials, use temporary ones where possible, and revoke elevated access when tasks are complete. Understand dependencies and manage supply chain risk for third-party components, models, tools and integrations.

None of that is new advice. It is the RPA operating model with the word robot replaced. Organisations that did the work once have a genuine head start, and it is the only head start in this transition that is worth anything.

Second, exceptions. Every automation of any generation produces items it cannot complete, and the design question is where they go and who is obliged to look. RPA programmes that failed did not usually fail on the happy path. They failed because the exception queue grew faster than the team watching it, until the manual work the automation was meant to remove reappeared in a different tab. An agent that resolves more exceptions still produces exceptions, and it produces them in a form that is harder to categorise.

Third, release management. The NHS guidance lists, among the practical challenges and limitations it says may be faced when delivering an RPA programme, that software updates can cause robots to fail and affect business critical processes. Agents inherit that dependency and add another, because the model itself now has a release schedule owned by a third party. Where an RPA estate was hostage to the release calendars of the systems it drove, an agent estate is hostage to those plus the vendor’s model deprecation policy.

What does not carry over at all

The business case. This is the discontinuity, and it is rarely acknowledged.

An RPA case was per process. You measured a task, counted the hours, applied a rate and set the result against a licence cost that was fixed for the year. The saving was expressed in full-time equivalents, the cost was a known number, and the arithmetic could be checked by a finance business partner in an afternoon.

Agent economics do not work that way, because the cost is metered per action and therefore rises with adoption. The more successful the deployment, the larger the bill, and the run cost cannot be fixed at the point of approval. That inverts the incentive that every automation programme has been managed under for ten years, and it is examined in detail in our analysis of what these systems cost in their second year.

The second thing that does not carry over is the confidence interval. Rules-based automation is either correct or broken, and both states are obvious. A model has an error rate, which means the correct question is no longer whether it works but how often it is wrong and what that costs, and almost no organisation that bought RPA has ever had to answer that about a production system.

The third is the skills profile of the team. An RPA capability was staffed with process analysts and configuration developers, people whose craft was understanding how work actually flowed and expressing it precisely. Those skills are still valuable and are now insufficient on their own, because somebody also has to design an evaluation, argue about a sampling frame and interpret a disagreement rate. That is a different discipline with a different labour market, and no vendor migration path includes it.

The estate is an asset only if it is documented

There is a version of this transition that goes badly, and it is common enough to be worth naming.

An organisation with several hundred automations built over eight years by three different delivery partners decides to modernise. It discovers that the authoritative description of what each automation does is the automation itself, that the process documentation was written before go-live and never updated, and that the people who understood the exceptions have left. At that point the estate is not a foundation. It is an archaeological site, and the migration budget is really a rediscovery budget.

The organisations that come through this well share one unglamorous habit. They kept the process definition outside the tool. The rules live in a document or a decision table that a person can read, and the automation implements them rather than embodying them. That is more work upfront, it is the first thing dropped under delivery pressure, and it is the single largest determinant of whether ten years of investment transfers or evaporates.

If you do nothing else before this transition, inventory the estate and record, for each automation, what it does, which systems it touches, who owns it, when it last changed and what happens if it stops. Half of any credible modernisation is that list, and it can be produced without buying anything.

How far anyone has actually got

Not far, on the only regulator-collected evidence available in Britain. The Bank of England and the FCA found that while 55% of AI use cases in the firms they surveyed involved some degree of automated decision-making, the semi-autonomous share, defined as systems that decide within a range but involve human oversight for critical or ambiguous cases, was 24% of those. Fully autonomous decision-making sat at 2% of use cases.

Set that beside a category leader growing annualised revenue at eleven per cent and the picture is coherent. The technology has advanced considerably. The permission has not.

The sequence that works

Take the estate you already have and ask which automations break most often and why. If the answer is that an upstream interface keeps moving, that process is a candidate for a model-driven approach and the benefit is a reduction in maintenance rather than a saving in headcount. If the answer is that the rules changed, an agent will not help you, because the rules will still change and now nobody will be able to say precisely what the system did about it.

Then take the identity work seriously before anything is connected to a production system, because it is the only part of this transition where the previous decade’s scar tissue is genuinely an asset.

Further reading sits in the AI and automation index. The applications that lasted are set out in the five that survived contact with reality, and the fuller cost and ownership argument is in the desk’s guide to intelligent automation.

The vendors are right that the two things belong on one platform. They are right for a reason that does not flatter the new product: the deterministic layer is what makes the probabilistic layer safe to deploy, and the organisations best placed to run agents are the ones that spent ten unglamorous years building it.