Robotic Process Automation (RPA)

What is robotic process automation?

Software that does a job the way a person would: opening the application, clicking the button, typing into the field, reading the screen. The bot follows a recorded or scripted sequence exactly, every time, and does nothing that was not written into it.

That literalness is the point. An RPA bot is deterministic in the strict sense: given the same inputs and the same screens, it does the same thing, which makes it testable, auditable and cheap to run once built.

Two operating modes are worth distinguishing because they carry different risks. Attended bots run alongside a person, triggered by them, on their machine. Unattended bots run on a schedule with no one watching, which is where the estate-level problems accumulate.

Why was it adopted so widely?

Because it needed no cooperation from anybody. No API, no vendor engagement, no integration project, no change to the system being driven. If a person could do it on a screen, a bot could be recorded doing it, and that removed every dependency that normally makes automation slow.

That single property explains the adoption curve better than any capability claim, and it is worth appreciating rather than dismissing.

• It reached systems nothing else could. A mainframe with no API, a third-party portal with no integration option, a supplier's web form. RPA automated the unautomatable, which is a genuine engineering achievement.
• It did not need the IT queue. An operations team could deliver working automation in weeks without waiting for a platform roadmap, which is why adoption happened from the business side outward.
• The business case was unusually easy. Count the hours a task takes, multiply by volume, compare against a licence. That arithmetic closed deals fast, and it is the same arithmetic that agentic AI ROI argues is harder than it looks.

Now look at that same trait from the other direction. A bot that needs no integration is also a bot that depends entirely on an interface someone else controls, and that person can change it anytime without telling you. There is no contract or agreement holding that interface in place, so you have no warning and no say in it. That means the dependency stays completely invisible right up until the moment it fails on you.

What actually breaks in an RPA estate?

Not usually one bot. A change to a shared portal breaks every bot that touches it at the same moment, so somebody has to find the failures, identify the affected bots, rewrite, test and redeploy. In an estate of hundreds, that stops being an incident and becomes a standing workload.

The failure mechanism matters more than the failure rate, because it explains why maintenance cost grows faster than the estate does.

• Failures correlate. Bots share the systems they drive, so one upstream change produces a cluster of simultaneous breakages rather than an isolated fault. Capacity planning based on average incident rates underestimates this badly.
• Exceptions have nowhere to go. A bot meeting a case it was not written for throws an error and stops. That is the correct behaviour and it means every unanticipated variation becomes a human queue.
• The estate outlives its documentation. Bots built by people who have since moved on, driving screens that have since changed, for processes nobody has reviewed. This is the same accumulation problem described at agent sprawl, arriving a decade earlier.
• Maintenance competes with new work. Once a team spends most of its capacity keeping existing bots running, the programme stops delivering and starts defending.

What do agents actually change?

What matters is the nature of the dependency, not the fact that one exists at all. An RPA bot depends on a screen or a button staying exactly where it was, so it breaks the moment that layout shifts. An agent depends on something different, meaning its judgment about what to do next. Both are things you cannot fully control, but they go wrong in very different ways, and that difference is what you need to plan for.

The distinction that matters operationally is how each one fails, and this is where the honest comparison favours RPA more than displacement material admits.

Read the third row carefully, because it is the one that gets skipped. A loud failure is a better failure. A stopped bot is a visible queue somebody addresses that morning. An agent that adapted its way to a wrong outcome produces no error, no alert and no queue, and is found later by whoever is affected. Which is why an agentic estate needs tracing, evaluation and guardrails that an RPA estate genuinely did not, and why that apparatus is a cost of the change rather than an optional extra.

The other change worth naming is who can build. RPA development generally needed a specialist in a proprietary tool. Agentic work needs somebody who can specify a goal and a boundary, which is a different and more widely held skill. That widens the pool of builders, and widens the governance problem correspondingly.

Where is RPA still the right answer?

Wherever the sequence is knowable and the interface is stable. If you can write down every step in advance and nothing upstream is going to move, a deterministic bot is cheaper per run, testable, auditable and incapable of inventing anything. Those are real advantages and no agent supplies them.

This is the section RPA teams should be handed first, because it is the one that is true and rarely said.

• Stable legacy interfaces. A mainframe screen that has not changed in fifteen years is not going to change next quarter. The brittleness argument does not apply, and RPA remains the cost-effective choice.
• High volume, low variation. The same operation thousands of times on identically structured input. Per-run cost dominates at that volume, and near-zero beats per-token.
• Where determinism is the requirement. Regulatory processes where the same input must produce the same output and be shown to have done so. A deterministic bot is explainable by construction; an agent needs a faithfulness argument, as set out at agent explainability.
• Where a wrong action is expensive and a stopped process is not. The loud-failure property becomes a feature rather than a limitation.

The framing to resist is that this is a choice between two technologies. The estates that work in practice run both: deterministic automation where precision and predictability matter, agents where judgment and variation matter, and often a deterministic workflow with a single agentic step inside it. That hybrid is the actual architecture, and it is set out from the coordination side at AI orchestration.

How do you modernise an estate?

By triaging what you have into three groups rather than migrating on principle. Most published guidance offers two, replace and keep. The third is the one that saves the most money: a share of any mature estate should simply be switched off.

Work through the estate in this order, because the third bucket removes work from the first two.

1. Delete first, and expect this bucket to be larger than anyone thinks

   Bots automating a step in a process that has since been retired. Duplicates built by two teams who did not know about each other. Bots whose output nobody has consumed in a year. Migrating any of these to an agent is paying to make an old decision more expensive.

2. Rank the rest by maintenance burden

   How many times has each bot been rewritten, and how many hours went into it. The heaviest consumers are your migration candidates, because they are already failing on their own terms and replacing them is the fastest measurable saving.

3. Leave the stable ones alone

   A bot that has run for three years without intervention against an interface nobody controls any more is doing its job. Replacing it introduces non-determinism, per-run cost and an evaluation requirement in exchange for nothing.

4. Check whether the answer is an API rather than an agent

   A significant share of RPA exists because an integration was unavailable at the time. If the target system has since published an API, the correct modernisation is an integration, which is cheaper and more reliable than either a bot or an agent.

5. Point new development at the work RPA could never take

   Processes rejected for automation because they involved unstructured documents or judgment calls. This is where agents add capability rather than substitute for it, and where the return is clearest.

6. Budget the apparatus into the migration, not after it

   Anything moved from a deterministic bot to an agent needs tracing, evaluation and bounded permissions, because a quiet failure is now possible where a loud one used to be. Costing the migration without that is the mistake described at agentic AI ROI.

One important point for anyone leading this with an existing RPA team already in place. The people who built that automation estate carry a lot of knowledge in their heads that never made it into any document. They know which bots quietly break every few weeks, which processes have stopped working without anyone officially noticing, and which screens are about to change and take a bot down with them. That knowledge is incredibly valuable when you are deciding what to fix first and what to leave behind. But if your programme treats the whole estate as a technical debt, rather than as a body of work that needs sorting through carefully, you lose access to exactly the people who know the best.