The five RPA applications that survived contact with reality

The Care Quality Commission runs a fee calculator. It appears in the government’s public register of algorithmic tools, alongside language models and computer vision systems, and its own published entry describes it as working from a set of pre-determined rules to work out what a care provider owes. The same entry says plainly that the calculator “doesn’t use any AI tools/models”.

There is nothing intelligent about it, and that is why it is worth starting there. A national register built to capture artificial intelligence has ended up documenting a large amount of deterministic rule-following, because deterministic rule-following is what public bodies actually have in production. The same is true in banks, insurers and utilities. Ten years after robotic process automation was sold as a way to bolt a workforce of software robots onto any process at all, the estate that survived is narrow, unglamorous and highly specific in shape.

Five shapes, on the evidence that is publicly checkable in Britain. Each one is a genuine industry application. None of them is the one the 2016 brochures led with.

1. Provisioning and de-provisioning people, in health and in any large employer

Joiners and leavers is the most automated process in the country that nobody writes case studies about. NHS England’s national RPA guidance, published in May 2022 by the NHS Transformation Directorate, lists human resources work of exactly this kind among its back-office candidates: joiners and leavers, account creation and privileges, temporary staff management. A trust hires a locum on Thursday, and by Friday that person needs an identity, a smartcard, a rota entry, a payroll record, an e-learning enrolment and access to four clinical systems that do not speak to one another.

The reason this survives is that the work is high volume, the rules are written down somewhere already, and the failure mode is visible within hours. If the bot does not create the account, a person telephones a service desk and says so. Compare that with a fraud model, where a wrong answer can sit undetected for a year.

It also survives because it is the one place where an interface-driven robot has an unfair advantage. There is no integration to build, because the systems being joined were bought at different times by different directorates and were never going to expose an interface to one another. The robot is the integration. That is an ugly sentence to write in 2026 and it is still true.

2. Reading inbound paper, in benefits administration

The Department for Work and Pensions has a published record for a computer vision tool used by its Child Maintenance Group to extract the address and reference number from return letters, using computer vision and optical character recognition. Not to decide anything. To read two fields off a scanned page so that a case can be matched. Where the address cannot be extracted, the record says a human reviews it.

This is the application that has quietly moved from rules to models without anyone changing the name of the programme. Classical RPA cannot do it. The NHS guidance is blunt on the point: a software robot cannot process unstructured material such as emails, images, video, audio and text, and cannot understand, interpret or make decisions without machine learning and AI doing that part for it. So a recognition step was added, and the pipeline around it stayed exactly as it was.

That pattern matters more than the model does. What is in production at DWP is a deterministic matching process with one recognition step in it. The recognition step is the part that can be wrong, and it is confined to a place where being wrong produces a mismatched case rather than a wrong payment.

3. Opening cases in a regulator’s case management system

The Information Commissioner’s Office has a record for automated case creation for its primary case management system, ICE 360, listed as in production. A regulator receives a complaint, and something has to turn that complaint into a case with a reference, a queue, an owner and a clock. The register puts the scale at an average of 6,340 cases created per month over the previous year, with automation expected to handle upwards of 90% of them.

This one needs a disclosure that the register makes and most automation coverage does not. The ICO’s record is tagged LLM, its capability is listed as computer linguistics, and it states that ICE 360 uses a large language model to parse information found in unstructured complaints and queries. The model is named: Azure OpenAI gpt-4.1. So this is the DWP shape again rather than a rules engine. A model reads the incoming email and emits structured JSON against a schema, validation decides whether that output is usable, and anything failing it goes to a manual queue. No case decision is taken by any of it.

Two of the five survivors have a model in them, which is worth saying rather than glossing. What survived is not the absence of machine learning. It is the discipline of confining the model to one recognition step and leaving a deterministic pipeline in charge of everything after it.

Case creation is the most reliably automatable step in any casework organisation, and it is also the least discussed, because it produces no headline. Nobody announces that they have automated the front of the queue. But the front of the queue is where the volume is, the rules are stable, and the downstream process is unaffected by how the case got created.

The reason so few of these become case studies is that the benefit is a capacity release rather than a saving. The people who used to key in cases were not made redundant. They moved to the part of casework that needs a person, which is deciding, and the organisation’s headcount did not change. The Office for National Statistics finds the same thing at national scale. In every size band, roughly half of AI-using firms say their staffing is unchanged, and even where the stated purpose was operational improvement, fewer than one business in fifteen reports any reduction at all.

4. Calculating a charge from a published rule set, in regulation and utilities

Back to the CQC fee calculator, because it deserves more than an opening line. The application takes information supplied by care providers in England and determines the invoice value payable, using a rule set that is published policy rather than a model. It is registered as being in production.

This class of work is where RPA never had to justify itself, because there was never a judgement to defend. The rules are in a statutory instrument or a published schedule. The inputs are structured. The output is a number that can be recomputed by hand if anyone challenges it. Water companies, energy suppliers, licensing authorities and pension administrators all run something of this shape, and most of them ran it in a spreadsheet with a macro before anybody sold them a licence.

The honest observation is that a lot of what was bought as RPA in this category was a slower, more expensive way of doing what a well-written batch job would have done. The robot was purchased because it could be built by the finance team without a change request to IT, not because it was the right technology. That is a governance finding, not a technical one, and it is the single most common reason an automation estate is larger than it needed to be.

5. Daily reconciliation, in regulated financial services

The Financial Conduct Authority requires a firm holding client money to perform an internal client money reconciliation each business day, working from its own records as they stood at the close of the previous one, and to log when each reconciliation ran, what was done in it and what the calculation produced. The resulting evidence is retained for five years.

That is a rule written for humans that describes a machine. It is repetitive, dated, evidenced and non-negotiable, and it happens overnight. Reconciliation is the application that made RPA respectable in financial services, and it is still the anchor tenant. The Bank of England and the FCA, surveying 118 regulated firms in 2024, found that the single largest business area for AI and automation use cases across the sector was operations and IT, at around 22% of all reported use cases, twice the share of the next largest area. The same survey found gradient boosting models to be the most common model type at 32%, well ahead of anything transformer-based. This is a sector automating its back office with well-understood techniques and telling its shareholders about generative AI.

The regulatory scaffolding around this work is also why it lasted. A reconciliation that is a compliance obligation is a reconciliation with a permanent budget line, a named owner, an internal audit cycle and an external auditor who will ask about it annually. Nobody has to defend it in a cost review. Compare that with a process improvement automated on the enthusiasm of a departmental head, which is defended by whoever is still in the role two years later.

The property the five have in common

Rank the five by how much they were talked about and you get roughly the inverse of how much of them is still running. That is not an accident, and it points at the selection criterion nobody put in the business case.

Each of the five has a fast, unambiguous failure signal owned by somebody outside the automation team. An account that was not created generates a telephone call. A case that was not opened breaches a statutory clock. A reconciliation that did not run is a reportable matter. A fee that was miscalculated arrives as a dispute from a provider who wants their money back. A letter that was misread produces a mismatched case that a caseworker sees the same week.

Now consider the applications that did not survive. A pricing bot that quietly applied a stale rule. A procurement automation that approved things it should have queried. A reporting robot that produced a plausible number. In each of those the wrong answer looks exactly like the right answer, and the organisation only finds out when something else goes wrong. Automations of that kind do not fail loudly; they decay, and the decay is discovered during an audit or an incident review, by which point nobody trusts the output enough to keep paying for it.

So the useful screening question before automating anything is not whether the process is repetitive. It is: if this runs incorrectly on a Tuesday night, who notices on Wednesday, and how? An application with no answer to that question should be automated last, whatever the hours-saved calculation says.

What killed everything else

The brochures listed far more than five. Contact centres, claims handling, order-to-cash, procurement, clinical coding, mortgage origination. Some of that runs. Most of it stalled, and the reasons are documented in the national NHS guidance, which is franker than its provenance would predict. The foreword records that it was developed by the NHS Transformation Directorate and Atos, and several diagrams are sourced to the Atos intelligent automation methodology. Atos sells RPA delivery. That makes the challenges list more interesting rather than less, because it is a supplier’s own method conceding what goes wrong.

The guidance sets out the practical challenges and limitations that may be faced in delivering an RPA programme, framed as risks to plan for rather than as a post-mortem. Set-up is not quick, and typically takes three to five months because of IT procedures. Internal change processes limit how fast an automation can be updated. Processes turn out to be more complex than they first appear. And, most damagingly: software updates can cause robots to fail and impact process operations, including business critical processes.

Read that last one carefully, because it is the whole story. An RPA deployment does not fail on its own terms. It fails because somebody else shipped. The automation is a dependent of every system it drives, and it holds no vote in any of their release plans. An estate of two hundred robots is an estate with two hundred subscriptions to other teams’ change calendars, and the cost of those subscriptions arrives as unplanned work in the year after the business case closed.

The five applications above all avoid this in one of two ways. Either the process runs against a system the same organisation controls, or it runs against so many systems that the integration was never going to be built and the robot is the least bad answer available.

There is a second, quieter cause of death, and it is a documentation problem rather than a technical one. NHS England’s published playbook case studies on robotic process automation, which were for several years the most useful public account of what British public bodies had actually deployed, now redirect into a Blueprinting programme page whose library requires a FutureNHS account. The national guidance itself is still openly downloadable, and it is good. The worked examples that showed which processes had been automated, by which trust, with what result, are no longer publicly checkable. That is a real loss for anyone trying to assess this technology on evidence rather than on vendor material, and it is worth saying so rather than citing figures that can no longer be verified at source.

What this means for the agent conversation

Every vendor now describes its RPA product as the execution layer for something more autonomous. The claim is not empty. If you have already built the rules, the credentials, the environments and the exception queue, you have built most of what an agent needs in order to be allowed near a production system, and the operational lessons carry over more cleanly than the technical ones do. The fuller version of that argument is in what a decade of RPA taught us about agents, and the cost side of the same question is in our intelligent automation guide.

But the five survivors carry a warning for that conversation too. Not one of them survived because the technology was capable. They survived because the work was bounded, the failure was visible quickly, and somebody in the organisation would notice within a day if it stopped. Those are properties of the process, not of the software, and no amount of autonomy changes them. This is a recurring theme in Foundry4’s AI and automation reporting, and the register documenting most of it is public, searchable and considerably more useful than any vendor’s customer page.

The register’s most instructive feature is what it does not contain. There is no entry for a general-purpose automation platform deployed across a department. Every record names one tool, one job and one owner. After ten years, that remains the only configuration anyone has been able to keep running.