A model that clicks is still a screen scraper

Most RPA estates follow the same arc. Bots are built quickly to bridge systems that have no integration, they save real time in the first year, and then the maintenance load grows with every screen change, every new supplier template and every dialog box that appears after an upgrade. Eventually the bot team spends more of its week repairing than building.

The current proposal is to replace the bots with AI agents that look at the screen the way a person does and adapt when it changes. That proposal is half right, and the half that is wrong is the expensive one.

Three different kinds of brittleness

Bots are usually described as fragile in general. They are fragile in three specific ways, and it matters which one is hurting.

Bound to the screen. The bot finds a field by its position or its element identifier. Move the field, rename it or add a confirmation dialog, and the bot stops.

Bound to a template. The bot reads its input with fixed rules: the invoice number is in this box on this supplier’s layout. A new layout produces nothing or, worse, the wrong value from the right place.

Bound to the happy path. The bot was recorded doing what a person did on a normal day. The exceptions were handled by the person sitting next to it, and nobody wrote down how.

What a model fixes, and what it does not

A model fixes the second kind well. Reading a document it has never seen and returning structured fields is exactly what it is good at, and it removes the template maintenance that every bot team knows too well.

It does not fix the first kind; it changes how it fails. A bot with a broken selector stops with an error — loud, irritating and safe. A model driving a screen that changed may find a field that looks right, type into it and carry on. A loud failure has been exchanged for a quiet one, at a higher cost per transaction and with runs that are harder to reproduce, because two runs over the same screen do not have to take the same path.

The third kind is not fixed by any technology. Exceptions need a design, whatever does the clicking.

Go below the screen

For each bot, the useful question is not what should replace it but where else the data could come from or go to. In rough order of preference: the system’s own API, its events or message queues, a file exchange it already supports, and only then the screen.

Infographic

Where to connect the automation

System APIEvents and queuesFile exchangeScreen automation

StableBrittle

Many of the systems that bots touch offer one of the first three. They were not used because building a bot was faster than raising an integration request, and that trade looked good until the maintenance arrived. Old systems with no interface at all do exist. For those, a bot on a stable screen is a reasonable answer: keep it, monitor it, and stop expecting it to handle exceptions.

The model belongs at the intake, where the input exists only as a document or free text — the supplier’s invoice, the customer’s email, the scanned form. There it turns the document into a structured proposal, which ordinary code checks before anything is written anywhere.

Triage the estate, do not migrate it

A programme that converts bots into agents one for one inherits every process decision the bots froze in place. Sort them instead.

Retire. The process has changed, or the data is now available another way. Worth checking first, because it is cheaper than any rebuild.

Rebuild below the screen. Integrate through the API, the events or a file, with a model only where a document has to be read.

Keep. A stable screen, a low rate of change and no alternative interface. Leave it alone and spend the effort elsewhere.

The bot maintenance log is the business case. The bots generating the most tickets are where to start, and the tickets also tell you which kind of brittleness each of them suffers from.

What the bots were really doing

Look closely and most of an RPA estate is moving data between systems that had no other way to talk, plus reading documents nobody had parsed properly. Both are data problems with a user interface glued on top.

Replacing bots well is therefore mostly AI data engineering: incremental, observable ingestion from the awkward sources the bots were scraping, documents parsed and checked before anybody trusts them, and failures that are loud — the one property of the old bots worth keeping.