Agents versus RPA: where each one earns its keep

Robotic process automation has been quietly doing useful work for two decades. It clicks the buttons a person used to click, moves data between systems that were never introduced to each other, and does it at three in the morning without complaint. When the inputs are structured and the path is fixed, RPA is fast, cheap per run, and completely predictable.

Its weakness is the same as its strength. It follows rails. Change the layout of the screen it clicks, or feed it a document in an unexpected format, and it derails. Anyone who has run an RPA estate knows the maintenance tax: bots breaking every time a vendor ships a redesign.

What agents add

An AI agent can read. It can look at an email written in a hurry, a contract with the clause in an odd place, or a support ticket that mentions three problems at once, and work out what is actually being asked. It can weigh options and pick one, then explain its reasoning in the log. That is the capability RPA never had, and it is why processes that used to be classed as "needs a human" are now automatable.

Agents bring their own costs. Each run consumes model inference, which is not free. Output is probabilistic rather than fixed, so it needs review gates and measurement in a way a deterministic bot does not. And an agent given tools without limits is a liability, which is why governance is not an optional extra.

The rule of thumb

If a step can be drawn as a flowchart with no judgement in it, script it or use RPA. It will be cheaper and it will never have an opinion. If a step needs reading, interpretation, or a decision that depends on context, that is agent work. Trying to force either tool into the other's territory is where automation budgets go to die.

In practice the installations that hold up are hybrids. Agents sit at the messy edges: reading what comes in, classifying it, drafting what goes out, handling the exceptions. Deterministic steps run on rails in between: moving records, posting entries, firing notifications. The agent decides, the rail executes, and each is doing the only job it is good at.

A worked example

Take supplier invoices. Arrival and extraction is agent work, because invoices arrive in every format humans can invent. Matching to a purchase order is a lookup, so it runs on rails. Deciding what to do with a mismatch is judgement, so it goes back to an agent, which either resolves it against the delivery records or writes a one-paragraph escalation to a named person. Posting the approved entry to the ledger is rails again. Four steps, two technologies, no heroics.

The question to ask a vendor is not "agents or RPA". It is "which of my steps needs judgement, and what does each step cost to run". Anyone selling one answer for every step has a product to shift, not a process to fix.