Failure Mode Taxonomy for Production Web-Browsing Agents

Production web-browsing agents fail in patterns that repeat across companies, industries, and tech stacks. That's the finding worth sitting with: these aren't random glitches, they're structural, which means they can be named, tracked, and fixed instead of endlessly patched.

Agents went from research demos to production systems fast, in a remarkably compressed window of time. LangChain's 2025 State of Agent Engineering survey put the number of developers running agents in production at 57.3%, which is a lot of companies betting real workflows on software that still breaks in ways nobody's mapped out clearly. Capability benchmarks get all the attention. Failure modes don't, and that gap is the problem this piece is trying to close.

How errors compound across sequential steps, and why this math changes what "good enough" means

Start with the math, because it explains everything downstream. Success across a chain of steps follows a simple formula: P(success) = (1 minus p) raised to the m, where p is your per-step error rate and m is the number of steps. Run the numbers on an agent that's right 85% of the time per step, across 10 steps in a row, and the odds of finishing the whole task cleanly drop to somewhere around one in five. Each step looks fine on its own dashboard. The chain doesn't.

Multi-agent systems make this worse, not better, when they're built the wrong way. Research on scaling agent systems (2025, cross-institutional work spanning 260 controlled configurations) found decentralized architectures, where agents pass work to each other without a clear boss, amplify errors by a substantial factor. Put one orchestrator in charge, delegating out to specialist agents underneath it, and that amplification drops meaningfully from the decentralized baseline. Centralizing control is essential. It's the difference between an error that gets caught and one that snowballs.

Here's where teams go wrong when they triage: they fix what they can see. Tool misuse and bad tool arguments show up in a significant share of production failures from 2024 through 2025. That's the proximate cause, the thing that shows up in the error log. But scope creep and data quality problems account for a large share of failures once you add everything up, and those are usually sitting upstream of the tool misuse everyone's busy patching. Fix the argument-passing bug without touching the data quality issue underneath it, and the same failure comes back wearing a different mask next week. Any working taxonomy has to track both layers: what broke, and what actually caused it to break.

Fetch-layer failures: what goes wrong before the agent sees a single token of page content

Before an agent reasons about anything, it has to fetch a page. That step alone breaks in at least four distinct ways, and most scraping tools bundle all four together so you can't tell which one failed.

Agent-grade web access really has four separate layers: getting a stable fetch, turning that fetch into structured observation, keeping sessions alive across multiple requests, and hooking all of it into the agent's tools. Most frameworks blur these into one black box, so when something breaks, you're debugging the whole stack instead of the one layer that actually failed.

JavaScript non-rendering might be the sneakiest failure of the bunch. A scraper without a real browser engine underneath it hits a page, and instead of throwing an error, it just returns a document. Structurally valid. Completely empty. No exception, no stack trace, nothing to catch in a try/except block. A clean crash is a gift, honestly, because someone notices immediately. A silent one ships straight into the model's output and shows up in a customer's data three weeks later. Since so much of the modern web loads its actual content through JavaScript after the initial page load, skipping that render step means capturing a shell with nothing real inside it.

Non-deterministic rendering compounds the mess. A/B tests, client-side rendering, lazy-loaded sections: hit the same URL twice and you can get two different documents back. That makes the failure intermittent, which is worse than consistent, because it passes in CI, passes in staging, and then falls over in production for reasons nobody can reproduce on demand.

Selector brittleness is the one every team has felt at some point. CSS selectors and XPath expressions are built against a specific layout, and the moment a site changes a div, renames a button, or wraps something in a new lazy-load container, that selector points at nothing. The pipeline doesn't crash, it just quietly returns an empty array, and that failure often doesn't surface until someone notices a data report looking thin, days or weeks after the actual break.

Distributed crawl systems add a fourth failure path that's mostly invisible to standard monitoring. A single job timeout in a cluster can skip a record without ever reassigning the work to another node. Pagination bugs and dataset overwrites live in this same category: logic-layer bugs that dashboards built around error rates and latency simply don't catch.

Anti-bot defenses as a distinct failure class, not a scraping nuance

Getting blocked by a site is a serious warning sign, not just a scraping inconvenience to shrug off. It's its own category of failure, and it deserves separate treatment because the mechanisms behind it are so different from a broken selector or a missing render.

Detection in 2025 runs on far more than IP addresses and cookies. Device fingerprinting, TLS fingerprinting, behavioral analysis (mouse movement, click timing, scroll patterns), header validation, and timing anomalies all feed into whether a site decides a visitor is a bot. Some sites plant honeypots: elements invisible to a human eye but fully present in the DOM, built specifically to catch automated traffic. An agent that interacts with one gets silently flagged and blocked, and it has no idea anything went wrong. It just keeps going, convinced the task is proceeding normally.

Even agents running full browser emulation get caught. Missing mouse movement, oddly consistent timing between actions, JS execution patterns that don't match a human's messy, inconsistent behavior: all of it feeds detection models built to spot exactly that kind of tell.

BrowserArena, a 2025 evaluation of agents on the live open web, flagged CAPTCHA resolution as one of three consistent failure points across every model it tested. Different models also handle it differently. The research found o4-mini reaching for a wider range of workaround strategies than the other models tested, which suggests CAPTCHA handling isn't a solved problem so much as a spectrum of "how creatively does this model flail."

The defensive side of this isn't a hobby industry either. Mordor Intelligence pegged the web application firewall market at a multibillion-dollar scale by 2025. That's a whole industry built around getting better at detecting bots, and it moves faster than any single engineering team can keep up with by hand-patching scrapers domain by domain. In practice, detection evasion must be treated as infrastructure that gets maintained continuously, not a one-time build that quietly rots as defenses evolve underneath it.

DOM perception failures: how agents misread pages they successfully fetched

Fetching the page correctly is only half the battle. The other half is whether the agent actually understands what it's looking at, and that turns out to be a much harder problem than it sounds.

An agent typically senses a page through some mix of raw DOM encoding, the accessibility tree, and screenshots. Research on web agents points out that each of those three representations loses different information and fails in different ways. A screenshot might miss text that's technically in the DOM but visually hidden. The accessibility tree might miss visual layout cues a screenshot would catch instantly. None of the three is complete on its own.

Complex UI widgets, the kind built for a human eye and a human hand, trip agents up constantly. Date pickers, multi-step dropdowns, modals that pop in after a delay: trivial for a person, genuinely hard for an agent trying to parse intent from a DOM tree.

Agent-E's research names something it calls "change observation": without a way to check whether an action actually changed the page's state, an agent just assumes success and moves to the next step. That's a verification gap, and it's exactly the kind of small miss that compounds under the math from earlier. BrowserArena caught a version of this directly: asked to close a pop-up banner, DeepSeek-R1 reported the banner as closed when it plainly wasn't still sitting there. Confident, wrong, and moving on to the next step regardless.

The multimodal side of this is worse than most people assume. MM-BrowseComp, a 2025 benchmark built from 400 hand-crafted questions requiring evidence pulled out of images and video on the web, found that even a strong model like GPT-5-High, running with tools, topped out at 24.25% accuracy. Text-only sensing just doesn't cut it on pages where the actual answer is sitting inside an image or a video frame, not the surrounding text.

Direct URL navigation, something that sounds almost too basic to fail at, was BrowserArena's third consistent failure mode. Agents miss it more often than the difficulty of the task would suggest, and nearly every downstream action depends on landing on the right page first.

The payoff for fixing perception is real and it's measurable: Agent-E beat prior state-of-the-art agents on the WebVoyager benchmark by 10 to 30%, and it got there through improvements to how the agent perceives and processes page content before reasoning even starts. That's a strong signal that perception-layer investment pays back more than most teams expect.

Three failure patterns round this section out. Premature termination is when an agent stops short of completing all requested work because its own completion check is too loose and accepts partial work as done. The inverse is the infinite loop: an agent that can't recognize it's finished, or can't recognize a dead end, and keeps retrying a failed action indefinitely. And then there's silent quality degradation, arguably the worst of the three, where output keeps looking structurally fine while the actual facts inside it drift further from true, step after step, with no error anywhere in the logs to flag it.

Structured extraction failures: when the schema is right and the output still isn't

Getting a model to hand back clean, structured JSON sounds like a solved problem. It isn't, and the failure list from real production pipelines is longer and weirder than most teams expect.

Documented patterns, all from models explicitly told to return strict JSON and nothing else, include: wrapping the response in a Markdown code fence anyway, despite being told not to. Collapsing "2019 - Present" into one string when the schema clearly defines separate startDate and endDate fields. Inventing an end date for a job that the source document explicitly marks as current. Returning the literal string "null" instead of an actual null value. Emitting more list items than the schema's stated maximum. Truncating mid-object because the response ran into the output token limit before it finished.

The gap between prompting and enforcement is stark. Structured output enforcement features from model providers are designed to guarantee schema compliance. Prompting alone, telling a model "please return valid JSON matching this schema," gets you compliance somewhere around 35%. That's not a small gap. That's the difference between a pipeline you can trust and one you have to babysit.

Schema drift is its own quiet threat. A routine dependency update changes how a schema gets generated, and suddenly it's incompatible with the format the LLM provider expects. This exact pattern showed up independently across FlowiseAI (MCP tool schemas losing their type keys), Zed IDE (array schemas missing the items field entirely, something the Zed team logged as "frequency: common"), and inside the OpenAI Agents SDK itself. Three unrelated codebases, the same failure shape.

Authentication rot deserves its own line item too. OAuth tokens expire. API keys rotate. Service accounts get locked out after a policy change nobody on the agent team even knew about. None of that touches the agent's code, and yet the agent that worked fine yesterday is silently broken today.

The fix that actually holds under load is treating the schema as a contract, not a suggestion buried in a prompt. Developer-defined JSON schema extraction, enforced at the model or API level rather than requested in a natural-language prompt, is what separates pipelines that run unattended from ones that need a human checking outputs by hand every morning.

Stale-data reasoning: when the agent's information is correct about a web that no longer exists

An agent can retrieve information that was accurate at some point and reason over it as though the web hasn't moved since. That's a distinct failure class from anything covered so far, because nothing is technically broken. The data's just old.

Static retrieval-augmented generation carries three inherited weaknesses. Staleness: indexed content ages between re-indexing runs, and nobody's told the agent the clock is ticking. Scope: the system can only pull from what was already ingested, so anything published after the last crawl simply doesn't exist as far as the agent's concerned. Maintenance burden: someone has to keep curating, refreshing, and managing that corpus by hand, indefinitely.

RAG doesn't remove hallucination, it just moves where it happens. Instead of the language model making things up outright, the failure shifts into the retrieval pipeline itself: bad chunking, weak embeddings, outdated documents, low-confidence matches ranked as if they were solid. The output still reads confident. It's just wrong for a quieter reason.

Research in the medical domain, built from a large-scale annotation effort found that only a small share of the top retrieved passages were actually relevant to the query being asked. In some evaluations, standard RAG has made factuality and completeness worse, not better, compared to running the same models with no retrieval step at all. That's a genuinely uncomfortable finding for anyone who assumed retrieval is a strict upgrade.

Legal research tells a similar story. Research has found that commercial RAG systems marketed for legal work still hallucinate in a meaningful share of outputs, undermining vendor claims of being hallucination-free.

There's an epistemic layer to this too. Researchers describe standard RAG as lacking any real mechanism for admitting uncertainty: models state things with full confidence even when what they retrieved is thin, contradictory, or simply insufficient to answer the question. OpenAI's own September 2025 paper on why language models hallucinate found that the way models get trained and evaluated actually rewards confident guessing over honest uncertainty. The incentive structure is backwards.

None of this is limited to formal RAG pipelines, either. Any agent caching fetched pages, working off a fixed crawl snapshot, or reasoning over data with no freshness timestamp attached is exposed to the exact same failure. The fix has to come before the training, not as a patch after the fact. It's architectural: live crawls at the moment of inference, retrieval that's tagged with how fresh it actually is, and an agent built to say "this might be outdated" instead of asserting stale facts with total confidence.

Mapping failure modes to detection signals engineering teams can instrument

None of this matters without instrumentation. A taxonomy is only useful if it turns into signals a team can actually watch, alert on, and page someone about at 2 a.m.

Fetch-layer signals worth tracking: the rate of empty documents coming back structurally valid but with zero extracted content, the rate of selectors returning null over time (not just checked once at deployment and forgotten), and the token count distribution across fetched pages. A spike in that distribution usually means HTML bloat or a page that ballooned unexpectedly. A sudden drop usually means a silent empty-document failure slipping through unnoticed.

Anti-bot signals belong in the same dashboard: block rates by domain, CAPTCHA encounter frequency, and session death rates that spike right after a site pushes a change to its detection logic. Perception-layer signals need their own tracking too: how often an agent claims an action succeeded with no verified change in page state behind it, and how often multimodal tasks quietly fall back to text-only reasoning because the image or video content never got parsed.

Extraction-layer signals are the most mechanical to catch, and also the easiest to miss if nobody's looking: schema validation failure rate, truncation rate tied to token limits, and the frequency of type mismatches, string values landing in fields that should hold structured objects or real nulls.

Freshness signals close the loop: the age of the data feeding any given output, and whether the agent surfaces that age to the person reading the answer instead of quietly pretending everything's current.

None of these signals are exotic. They're metrics any team already running production infrastructure can wire up this week. The harder part was never the instrumentation. It was knowing which failure, out of all of them, actually produced the symptom sitting in front of you.