Scripts or agents?

A script breaks loudly. A selector stops matching, the run throws, and you know immediately that something changed. The cost is maintenance; the benefit is that you are never wrong without knowing it.

An agent bends. The layout changed, it works out the new arrangement, and the run succeeds — or it half-works out the new arrangement, does something slightly wrong, and the run also succeeds. Adaptability and silent error are the same property viewed from two sides.

Which failure you prefer depends entirely on what the automation touches. For scraping prices, a quietly wrong run costs you a bad number in a dashboard. For submitting a job application, it costs someone an application with the wrong salary expectation in it, sent under their name, with no way to retract it.

A scripted form fill is a few milliseconds of CPU. An agent doing the same thing is a sequence of model calls, each costing tokens and a second or more of latency. For a form with eight fields that can be two orders of magnitude difference in both.

At small volumes this is irrelevant. At a thousand applications a day it decides whether the product has a viable unit economics, which is why systems that start agentic usually end up scripting their common paths.

Screenshots are what make the gap so wide. A vision-based step sends an image on every observation, and images dominate the token bill in a way a developer reasoning about text prompts consistently underestimates — the first production invoice is where most teams discover this.

• Script: milliseconds, negligible cost, deterministic, brittle
• Agent: seconds per step, token cost per step, adaptive, non-deterministic
• Script: breaks visibly when the page changes
• Agent: may quietly do the wrong thing instead of breaking

Use a script for the paths you have seen and an agent as the fallback for the ones you have not. Most volume flows through a handful of applicant tracking systems whose forms are stable enough to script; the long tail is where an agent earns its cost.

The refinement that makes this compound: when the agent successfully handles a new form, record what it did as a candidate script. The next hundred times that employer appears, the cheap path handles it. The agent becomes a mechanism for generating scripts rather than a runtime dependency.

Promotion needs a gate, though, or you will cache a mistake. Require the agent to have completed the same form successfully two or three times with a consistent field mapping before the recorded path is trusted, and keep the agent as the fallback for when the promoted script starts throwing.

The question is not which is better but how much variety you face and how often it changes. Low variety and stability favour scripts overwhelmingly; high variety with no repetition favours agents.

Job applications sit awkwardly in between, which is exactly why the hybrid wins there: a few systems account for most volume, and a long tail accounts for most of the distinct work.

One more factor decides it in borderline cases: who maintains the thing. A script is cheap to run and needs an engineer whenever a page changes; an agent costs more per run and absorbs those changes silently. A small team without capacity for constant selector maintenance can rationally choose the more expensive option.

Much of the brittleness attributed to scripting is really brittleness in how selectors were written. Targeting a generated class name or a deep CSS path couples the automation to the page’s implementation, which changes constantly; targeting the accessible role and name couples it to what the control is for, which rarely does.

This is why Playwright pushes role and label based locators so hard, and why the accessibility tree is the most stable part of a modern web page to automate against. A field labelled "Email address" tends to stay labelled that through three redesigns.

The practical effect is to narrow the gap. A script written against the accessibility tree survives a substantial share of the changes that would have broken a CSS-selector script, and every change it survives is a case where you did not need the agent at all.

• Prefer accessible role and name over CSS paths and generated classes
• Never target a class that looks machine-generated
• Wait on a condition, not a fixed duration
• Assert the end state after submitting, not just that the click happened

Because a script fails loudly, its verification can be light. Because an agent fails quietly, verification is not optional: read the form back after filling, confirm the expected end state, and treat a missing confirmation as a failure rather than assuming success.

Teams that move from scripts to agents and keep their old verification habits are the ones surprised by silently wrong runs months later.

Record enough to reconstruct a run, too. With a script the code tells you what happened; with an agent the code is identical for every run and the only account of what it actually did is the trace you chose to keep — so a screenshot and the field values at submission time are the difference between answering a complaint and guessing.