AI agents vs RPA

When a screen changes, an RPA bot doesn't raise its hand. It clicks where the button used to be. The lucky version stops; the unlucky version keeps running wrong, and you find out when a batch of records posts incorrectly. Selector maintenance exists precisely because of this failure mode.

Agents are API-first: they act through interfaces designed for software, which don't move when a designer refreshes the UI. Where a legacy screen is unavoidable, the agent treats it as a last-mile step and verifies the outcome instead of trusting the click.

RPA vendors sell OCR and 'intelligent document processing' add-ons because the base product cannot read. The result is a stack: capture tool feeds template-based extraction feeds the bot, with each layer licensed and each layer producing its own exceptions.

For an agent, reading is the core competency, not an add-on. Extraction comes with confidence scores, and low-confidence items route to a person. One layer, one exception queue, one log.

A bot that hits an unexpected state stops or misfires; a human then reconstructs what happened from screenshots. An agent flags the exception, explains what it saw, and routes it with context attached. Both approaches produce logs; only one produces logs a reviewer can read as a narrative of decisions.

For regulated back offices, this is the quiet advantage: every action records what was read, what was decided, and who approved it.

A stable legacy application with no API, no export capability, and no vendor roadmap is RPA territory, and honestly so. Screen automation is the only interface that exists, and if the screens haven't changed in years, bots run reliably.

The practical pattern we build: the agent does the reading and deciding, and where the last step is a legacy screen, it drives existing automation as its actuator. Brain and hands, separated.

Ask where your automation budget actually goes. RPA programs consistently spend a large share on keeping existing bots alive: broken selectors, OCR exceptions, environment changes. That spend buys no new capability; it buys standing still.

Agent maintenance exists too (we sell it openly as a retainer), but it maintains a system that understands its work, so changes in input format don't break it the way screen changes break bots.

RPA splits into attended bots (macros helping one person at their desktop) and unattended bots (server bots working queues). In both, the human's role is babysitting: restart the bot, fix the input, clean up after a misfire.

Agents move the human up a level: from babysitting the mechanism to approving the decisions. The agent prepares the work; a person clicks approve on anything that touches money or customers. Same headcount involvement, entirely different quality of involvement.

Classic RPA projects run through an implementation partner: process documentation up front, development, testing against a frozen environment, change-control before go-live. Months, routinely.

Agent pilots invert the sequence: 30 days against your real data, learning from corrections as they happen, with success criteria agreed in writing before the start. The pilot is the documentation.

Every screen change in an RPA estate triggers re-validation of every bot that touches it, which is why RPA change-control processes grow heavy. Agent behavior is governed by versioned rules instead of pixel positions, so a UI refresh is not a change event.

For auditors, the difference is legibility: an agent's log reads as a narrative (what was read, what was decided, who approved), not a replay of coordinates. Reviews get faster when the trail explains itself.