Browser Agents in 2026: What They Break On

A browser agent sits between a model and a browser. The browser exposes a page — as pixels, as an accessibility tree, as DOM text, or as some combination — and the agent decides on the next action: go to this URL, click that control, type into this field, scroll, read, stop. The loop repeats until the model believes the task is done.

That is a remarkable capability and it deserves the attention it gets. It removes the integration step entirely: no API key, no schema negotiation, no waiting for a vendor to expose the field you need. If a person can do it in a browser, a browser agent can attempt it, and for exploratory work the attempt is usually enough.

The trouble starts when the task stops being exploratory. “Check whether this supplier is on the sanctions list before we onboard them” and “find me a supplier” are not the same class of problem, even though a browser can serve both. The first is a recurring question whose answer will be acted upon, and recurring questions are where the four failure classes below live.

The first failure class is the most obvious and the least interesting technically: a great deal of the web is actively defended against automated clients. Rate limits, challenge pages, fingerprinting, IP reputation and outright blocks are normal infrastructure now, and none of them were built to distinguish a helpful agent from a hostile one.

The important part is not that this happens. It is what it looks like from inside the agent. A block rarely arrives as a clean error the model can reason about; it arrives as a page. An interstitial, an empty result set, a login wall, a “we could not complete your request” panel. The model reads a page, because reading pages is all it does, and a page that says nothing useful is indistinguishable from a page that legitimately has nothing on it.

Even where a target is happy to serve you, throttling is real and it truncates quietly. Both of the UK procurement registers behind our tender work throttle: Find a Tender refused a burst at 0.35 seconds per page, and Contracts Finder returned a 429 on two requests two seconds apart. An automated walk that does not back off does not fail loudly — it comes back with a short list and reports success.

The second failure class is state. A browser is a stateful machine: cookies, local storage, a logged-in session, a consent banner that was dismissed twenty steps ago, a filter that is still applied from an earlier task. An agent that ran correctly on Monday can run into a different application on Tuesday because the session it inherited is different.

This one is dangerous precisely because it does not error. The agent lands on a page, the page renders, the values are real values, and they are the wrong values — filtered to last month, scoped to the wrong account, or paginated to a page the agent never left. Everything downstream then treats a correct-looking answer as correct.

Human operators catch this constantly and barely notice they are doing it. A person glances at a total, thinks “that is too small”, and re-checks. An agent has no such prior. It has the number it was given and the confidence with which it was given.

The third failure class is drift in the target. Sites are redesigned, controls are renamed, a table becomes a set of cards, a value moves from the page body into a lazily loaded panel. A selector-based scraper breaks loudly when that happens, which is annoying and honest. A model-driven agent tends to break softly, which is worse.

Softly means it finds something plausible. Asked for a price, it returns the crossed-out price. Asked for a deadline, it returns the publication date sitting next to it. Asked for a company, it returns the parent brand in the footer. Each of those is a defensible reading of the page, and each is wrong in a way that will not be visible in a spreadsheet a week later.

Truncation is the same problem wearing a different hat. A long list that lazily loads its tail, a table with a hidden “show all”, a result set capped at the first page: the agent reads what is rendered and reports it as the whole. Nothing in the output distinguishes “there were nine” from “there were nine on the first screen”.

The fourth failure class is non-determinism, and it is structural rather than fixable. The model chooses the next action probabilistically. The page it acts on is itself variable — experiments, personalisation, ordering, ads, whichever build shipped this hour. Run the same task three times and you may legitimately get three answers, none of which is a bug in the ordinary sense.

For a research task, that is tolerable and sometimes even useful. For a monitor, it is fatal, because a monitor's entire product is the difference between today and yesterday. If the run-to-run variance is larger than the change you are watching for, every diff is noise and you will train yourself to ignore the alert.

This is the reason “did anything change?” is a much harder question for a browser agent than “what does this page say?”. Answering the second reliably is a prompt problem. Answering the first reliably is a state and provenance problem, and no amount of prompting fixes it.

For a recurring question, the better shape is to browse once, verify, store the result with its receipt, and let the agent read the stored answer through a typed tool. That is what a feed is, and it changes what the agent is being asked to do: not “go and find out”, but “read this, and here is where it came from”.

Three rows from the API Deprecation Watch feed make the difference concrete. Each carries the source URL the date was read from, a row type that says whether it came from a maintained end-of-life catalogue or from a vendor changelog entry, and a confidence marker — CONFIRMED where the value comes from a catalogue that maintains it, SIGNAL where it comes from a single vendor post. The days-left column is measured against the run date, 14 August 2026, not against whenever you happen to read this.

A browser agent asked “when does Confluence 9.3 go end of life?” can get that right. The question it cannot answer reliably is “which of the 460-plus products we depend on moved their dates this week”, because that requires yesterday's answer to have been recorded in a form today's answer can be compared against.

The two are not rivals, and the honest division of labour is not subtle once you separate the one-off question from the standing one. Browsing is how a set gets built the first time and how an exception gets chased. A feed is how the same answer gets served a hundred times without a hundred chances to be wrong.

Five questions settle most cases. If you answer yes to the first three, browse. If you answer yes to the last two, put a feed behind the agent and let it read through a tool instead.

In practice the wiring is small. The scraper.io MCP server is a remote Streamable HTTP server with ten typed tools — list_monitors, get_monitor, create_monitor, update_monitor, pause_monitor, resume_monitor, list_alerts, get_evaluation, list_channels and check_now — so an agent can read a set, ask what changed, and be woken when something matches, without ever driving a browser itself.

Scope matters as much as capability here. Read-only agents can be issued read-only keys, creating or changing a monitor requires an explicit write scope, and every call is isolated to a single workspace. An agent that cannot open a browser also cannot be talked into doing something unwise by a page it is reading, which is a security property as much as a reliability one.

If you want to see the shape of the data before wiring anything, the live feeds are the same sets these tools serve, with the receipts visible on the page.