Agentic automation

Robotic process automation recorded a sequence of interface actions and replayed them. It automated real work, and it was famously fragile: a moved button, a renamed field or an extra confirmation dialog stopped the whole thing.

Organisations ended up employing people to maintain the automations, which ate much of the saving. That maintenance burden, not capability, is what limited RPA.

It is worth being fair to it, though. RPA delivered genuine value for years and still does, and the reason it needed maintenance is the same reason it was trustworthy — it did precisely what it was told and nothing else.

Agentic automation replaces the recorded path with a stated goal. Instead of "click at these coordinates", it is "submit this expense claim" — and the system works out how, adapting when the interface differs from last time.

Brittleness genuinely improves. A renamed field does not stop an agent that reads the form and reasons about what each input wants. This is the real advance and it is not small.

It also collapses the long tail that made RPA uneconomic. Automating one supplier’s invoice format was worth it; automating the fortieth never was, and a system that reads a document rather than a fixed layout makes that fortieth case cost almost nothing extra.

RPA failed loudly. It stopped, raised an error, and someone fixed it. Agentic automation fails quietly: it improvises, picks the plausible-looking option, and proceeds — so instead of a stopped process you get a completed process with wrong data in it.

That is a worse failure mode in many contexts, and it is why agentic automation needs verification RPA never did. Checking the outcome was right becomes as important as performing the action.

The asymmetry is worth stating plainly: a stopped queue is visible within an hour, and a quietly wrong record can sit in a system for months before anyone notices. The second is cheaper to prevent and far more expensive to unwind.

• RPA: deterministic, brittle, fails loudly and obviously
• Agentic: adaptive, robust to change, fails quietly and plausibly
• RPA: auditable by reading the script
• Agentic: auditable only by logging what it actually did each run

For a stable, high-volume, well-defined process, deterministic automation is still correct. It is cheaper per run, faster, fully auditable, and its failure mode is a stopped queue rather than corrupted records.

Agentic automation earns its place where the variation is genuine: many suppliers with different invoice layouts, many systems with different forms, exceptions that a script would have to enumerate and cannot.

The strongest designs use both rather than choosing. A deterministic path handles the eighty per cent that follow the standard shape, and the agent handles what falls out of it — which keeps cost low, keeps most runs auditable, and reserves the expensive, non-deterministic component for the cases that actually need judgement.

Business cases for this usually count the time saved performing the task, which is the smaller number. The larger saving is in the cases that were never automated at all because building a rule for each one was not worth it.

Exception handling is where the money sits in most processes. A team where ninety per cent of invoices flow through automatically and ten per cent go to a person is spending most of its human time on that ten per cent, and that is precisely the portion a deterministic system could not reach.

Count the verification cost honestly against it, though. If a person must check every agent-completed case, you have moved effort rather than removed it — and the business case depends on sampling being sufficient, which depends on how expensive a missed error is.

The parts that are easy to skip are the parts that decide whether it survives contact with an audit: a log of every action with enough detail to reconstruct a run, sampling of completed work by a human, and approval gates on anything financial or irreversible.

Teams that treat those as overhead discover the problem months later, when someone asks why a supplier was paid twice and nobody can reconstruct what the agent believed at the time.

Add a way to stop it quickly. An agent processing a queue incorrectly will keep processing the queue, and the difference between a contained incident and a large one is usually whether someone could halt it in a minute or had to find who owns the deployment.