Browser agents and RPA versus an API: when driving the screen is the right call

There is a generation of tools — browser-driving agents, classic RPA, computer-use models — whose pitch is that they automate anything a person can do on a screen. For the systems that genuinely have no other interface, that is a real capability and there is no substitute.

For everything else, it is the most expensive way to do something you could do with an HTTP call.

Use the API when one exists

This sounds obvious and gets ignored, because the screen path is faster to build in an afternoon. The comparison is not build time, it is total cost over two years.

An API integration breaks when the vendor changes a documented contract, which they announce and version. A screen integration breaks when the vendor moves a button, which they do not announce, will not version, and may do in a Tuesday release that only affects your tenant's A/B bucket. One of these produces a deprecation email; the other produces a silent failure in production.

Check in this order: public API, private or partner API, database or file export, vendor webhook, then the screen. Somewhere in the first four there is usually an answer, and an export-plus-import beats a browser session more often than people expect.

When driving the screen is genuinely right

Legacy systems with no interface at all. The banking terminal, the 1998 ERP, the government portal. Classic RPA exists for these and it works. There is no elegant alternative and the boring one is a person retyping.

Vendors who lock the API behind an enterprise tier. Sometimes the arithmetic favours the fragile automation over the licence upgrade. Do the arithmetic explicitly, including a maintenance estimate, rather than defaulting to the screen because it is available today.

One-off or short-lived work. A migration that runs twice, a backfill, an extraction with a deadline. Fragility is priced in hours here, and the thing will be deleted before it breaks.

Genuinely visual verification. Checking that a page renders correctly, that a flow completes end to end. This is testing, and the screen is the point.

Making the fragile version survive

If you are committed to the screen path:

Anchor on stable things. Accessible labels, roles and stable test ids, in that order. Never absolute XPaths or coordinates — they encode a layout that will change.

Verify at every step, and fail loudly. The catastrophic RPA failure is not a crash, it is a bot that clicked the wrong thing and proceeded confidently for two hundred records. After every action, assert that the expected state arrived. A stopped bot is an inconvenience; a bot that continued is an incident.

Make it idempotent and resumable. Same requirement as anywhere, more likely to be exercised. Record what has been processed before the action, so a mid-run failure resumes rather than restarts — idempotency and retries applies directly.

Run headless, in a container, on a schedule you control. Not on somebody's desktop, which is how RPA installations end up depending on a laptop staying logged in.

Own the credentials properly. These automations log in as a user, which means a real account with real permissions and often no MFA because MFA breaks the bot. That is a security exception and it should be written down, scoped to a dedicated account with the minimum role, with its access reviewed like any other privileged path.

Budget the maintenance. A rule of thumb from the projects we have seen: a screen automation against an actively developed SaaS product needs attention every six to ten weeks. Against a frozen legacy system, almost never. The vendor's release cadence is the single best predictor of your maintenance cost, and it is knowable before you start.

Where the AI part helps

A model that reads the page rather than matching selectors survives a redesign that would break a scripted bot, and that is a genuine improvement in robustness. It is also slower, costs per step, and introduces non-determinism into an automation that was at least predictable when it was brittle. The pragmatic combination is a scripted path with a model as the fallback when a selector misses, plus an alert saying the fallback fired — because that alert is your early warning that the interface changed.

What to do this week

List your screen-driven automations and, for each, spend fifteen minutes checking whether the target has shipped an API since it was built. Vendors add APIs; nobody revisits the decision. In most portfolios at least one of these can be retired into an HTTP call this quarter.