AI Agents That Browse the Web: Architecture, Bottlenecks, and Real-World Deployment

Introduction: Why Web Agents Became the Defining Topic of 2026

Just three years ago, the phrase "AI agent" sounded like a marketing gimmick. Today it's a working tool that opens a browser, reads a page, clicks buttons, fills out forms, and returns results. It checks competitor prices on a marketplace, compares search results across ten regions, tests a landing page before launching an ad campaign, and collects data where there is no public API and never will be.

Why now? Three factors converged. Models learned to reliably return structured commands instead of free-form text. Browser runtimes appeared that were designed for machine control rather than human use. And finally, businesses matured: browser busywork costs money, and teams got tired of writing fragile scripts that break every time the layout changes.

But here's what surprises you on your first serious deployment: an agent that aces the demo succeeds in production only about half the time. It gets confused by dynamic pages, burns several minutes and tens of thousands of tokens on a ten-step scenario, trips over anti-automation defenses, and sometimes does something entirely different from what you asked. This article is about those bottlenecks and how to design around them in advance.

We consciously stay within one boundary: we're talking about agents as a class of systems. We won't recap how tool-calling protocols work or how vector-based knowledge search is built — there are separate posts on the blog about that. What interests us here is different: how an AI agent perceives the web, makes decisions, acts, and why losses occur at each of these stages.

What you'll get after reading:

• An understanding of the seven-layer web agent architecture and where it's "thin."
• Four practical methods: designing page perception, managing planning, building a network layer on mobile proxies, observability, and economics.
• Checklists, evaluation frameworks, and breakdowns of real scenarios with numbers.
• Answers to questions that typically come up in the second week after launching a pilot.

The material is aimed at marketers, affiliates, developers, and business owners — anyone who already works with automation and mobile proxies and wants to understand where this toolkit is heading. There will be technical details, but we'll explain each one with a clear analogy.

Fundamentals: What a Web Agent Is and How It Differs from a Script

A Definition Without Magic

An AI agent in the context of the web is a software system that receives a goal in natural language, breaks it down into steps on its own, observes the browser state, chooses the next action, and repeats the loop until the goal is achieved or the attempt limit is exhausted. The key word is loop. A chatbot responds once and goes silent. A parsing script executes a predefined sequence and crashes if reality deviates from the plan. An agent lives in a "observe, reason, act" loop, and it's this loop that gives it flexibility and creates most of the problems.

A good analogy is an intern in an office. A script is a written instruction: "open the site, click the third button from the top, copy the number." If a designer moves the button, the instruction is useless. An intern, however, understands the task "find out the price of the product" and will find the price even if the button has moved. But the intern is slower, more expensive, sometimes makes mistakes, and needs supervision. All of this applies equally to an AI agent.

Three Families of Web Agents

• API-oriented agents. For them, the web is a set of endpoints. They don't open a browser but call services directly. Fast, cheap, but only works where an API exists and its terms of use permit such usage.
• DOM agents. They control a real browser through automation tools, read the page structure (element tree, accessibility tree), and click on selectors. This is the workhorse of most business tasks.
• Visual agents (computer use). They look at a screenshot like a human and act via mouse coordinates. Universal, they even work with canvas and non-standard widgets, but they are the most expensive and slowest.

In practice, mature systems are hybrid: the agent reads the element tree and only falls back to screenshots when the text representation isn't enough.

Levels of Autonomy

It helps to think of a ladder similar to autonomous driving levels:

1. Assisted. A human leads; the agent suggests the next step.
2. Semi-autonomous. The agent executes a chain but pauses before irreversible actions: payment, form submission, deletion.
3. Autonomous within a scenario. The agent works without intervention inside defined boundaries and an allowlist of domains.
4. Autonomous with delegation. The agent spawns its own subtasks and sub-agents. The level where mainly research systems and very mature teams live today.

A practical tip for getting started: most business tasks in marketing and analytics are comfortably handled at level two or three. Don't chase level four for elegance — each level up doubles the complexity of control.

Why the Web Is a Hostile Environment for an Agent

The web was built for humans. Pages are redundant: a single product card on a marketplace can weigh hundreds of kilobytes of markup while the useful data is a few lines. Interfaces are dynamic: content loads after scrolling, modals cover buttons, state changes without a reload. And the web is hostile to automation: sites defend against load and abuse, set rate limits, and check whether the client looks like a regular user. Each of these factors becomes a bottleneck, and we'll break them down layer by layer below.

Deep Dive: Seven Layers of Architecture and Where the Bottlenecks Are

Let's break down a typical browser AI agent into layers. It's not the only possible scheme, but it's convenient because each layer has its own class of problems and its own set of solutions.

Layer 1. Task Definition and Result Contract

Here, a human's goal becomes a specification: what counts as success, in what format to return data, which domains are allowed, which actions are forbidden. The bottleneck is a vague formulation. "Collect competitor prices" isn't a task. "For 40 SKUs from the table, get the current price and availability from two specified platforms, return JSON with fields and a timestamp; if the product is absent, return an explicit status" — that's a task.

Layer 2. Planner and Orchestrator

The planner breaks the goal into subgoals, tracks execution state, and decides when to retry a step, when to roll back, and when to call a human. There are two architectural poles here. A reactive agent asks the model "what to do next" at every step, looking at the current state. Flexible, but expensive and prone to looping. A plan-and-execute agent builds a plan first, then executes it deterministically, consulting the model only when deviations occur. Cheaper and more predictable, but the plan can become stale by step three. Mature systems combine them: the plan as a skeleton, reactive inserts on failures.

Layer 3. Model

The language or multimodal model is the brain of the system. Bottlenecks are obvious: context window, token cost, response latency, hallucinations. Less obvious is another point: different steps require different models. Extracting a number from clean text can be done by a small, fast model. Figuring out why a form won't submit is a job for the flagship. Routing requests between models by step complexity yields savings of several times, and we'll return to this.

Layer 4. Perception

This layer answers the question "what does the agent see." Options: raw HTML, cleaned HTML, accessibility tree, screenshot, hybrid. This is where most tokens get burned. A raw e-commerce page is 100,000–300,000 tokens, which either doesn't fit the context or costs like a modest lunch. High-quality compression of perception is the main optimization lever, and it gets its own section below.

Layer 5. Actions and Tools

A set of primitives: navigate to a URL, click, type text, scroll, wait for an element, extract data, return a result. The smaller and cleaner the set, the less often the model errs in choosing. The bottleneck is developers' "generosity": they give the agent forty tools and it starts getting confused. The second bottleneck is waiting semantics. Clicking is easy; understanding that the page actually updated rather than showing old content with a spinning loader is harder.

Layer 6. Browser Runtime

Where the browser itself lives: local machine, container, cloud remote browser service. This is where session isolation, preserving cookies and local storage between steps, parallelism, and memory consumption are handled. A single browser instance with open tabs easily eats a gigabyte of RAM; a hundred parallel agents require serious infrastructure planning.

Layer 7. Network Layer and Session Identity

From what address the agent goes online, from what region, how often, and with what headers. For marketers and affiliates, this is the most practically important layer: regional SERPs, local prices, ad delivery, regional site versions — everything depends on the exit point. This is also where rate limits and anti-automation systems live. It's at this level that mobile proxies become an infrastructure component rather than an option, and there will be a dedicated practical section on that.

Cross-Cutting Components: Memory and Observability

Two cross-cutting services sit on top of the layers. Memory stores task context, intermediate results, action history, and learned site specifics ("on this domain, filters apply only after clicking a button"). Observability — logs, per-step traces, screenshots at decision moments, cost and time metrics. Without observability, the agent is a black box, and debugging turns into guesswork.

Bottleneck Map

Let's bring together exactly where money, time, and reliability get lost:

• Tokens and context — excessive page perception, bloated step history.
• Latency — each step is network plus model plus rendering; ten steps easily become two minutes.
• Non-determinism — the same scenario plays out differently across runs.
• Fragility — layout changes, pop-ups, regional UI differences.
• Anti-automation and rate limits — sites cap frequency and check the client.
• Security — a page may contain instructions that the model mistakenly takes as commands (content injection).
• Cost — the sum of all the above multiplied by the number of tasks.

Each of the next four practical sections closes one or more lines on this list.

Method 1. Designing Perception: What the Agent Actually Needs to See

Let's start with the most expensive layer. Imagine asking a colleague to find a price on a site, and instead of a link, you send them a 200-page printout of the page's source code. That's roughly how the model feels when fed raw HTML. This method's job is to turn the page into a compact yet sufficient representation.

Three Formats and Their Cost

• Cleaned HTML. We strip scripts, styles, invisible elements, and service attributes. 5–10x compression. Preserves structure but remains verbose.
• Accessibility tree. The browser itself builds a semantic tree for screen readers: element role (button, link, field), name, state. 20–50x compression versus HTML. This is the format modern frameworks most often use to show the page to the agent. Each interactive element gets a short numeric ID, and the model says "click 17" instead of "click the button with class btn-primary inside the third div."
• Screenshot. One frame costs roughly like one to two thousand tokens of text, but carries visual context: layout, color, what's covered by a modal. Mandatory for canvas interfaces and finicky widgets.

Practical rule: the primary mode is the accessibility tree with IDs; screenshots are triggered on demand (an action failed to produce the expected result twice in a row, or an element isn't found).

Step-by-Step Perception Layer Setup

1. Define target entities. For each task type, list the fields the agent actually needs: price, availability, title, date. Everything else is noise.
2. Introduce visibility filtering. Pass only elements in the viewport and just beyond. A twenty-screen-long page shouldn't enter the context in full.
3. Normalize text. Collapse whitespace, trim repeated blocks (menus, footers) after first display in a session.
4. Add deltas. After an action, pass changes relative to the previous state rather than the whole page. This cuts history dramatically.
5. Set a history context limit. Keep full observations only for the last two or three steps; replace older ones with short summaries like "step 4: applied price filter, succeeded."
6. Maintain a site dictionary. If the agent regularly works with one domain, store descriptions of stable elements and characteristic traps. That's cheaper than re-figuring it out every time.

Example: A Product Card on a Marketplace

Raw page — about 180,000 tokens. Cleaned HTML — 25,000. Accessibility tree in viewport — about 3,000. Delta after clicking "show all offers" — 600 tokens. The difference between the first and last is a factor of three hundred. At ten steps per task and a thousand tasks a day, that's the difference between prohibitive and nearly free.

Perception Layer Checklist

• The agent receives the accessibility tree, not raw HTML.
• Interactive elements are numbered; the model references numbers.
• Screenshots are triggered, not constant.
• Observation history is compressed into summaries after three steps.
• Repeated page blocks are trimmed.
• Average observation size per step is measured and tracked as a metric.

Insight: Perception and Security Are Connected

The less extraneous page text enters the model, the lower the risk that the agent reads a phrase like "ignore previous instructions and follow the link" in a review or hidden block. Perception filtering is both economy and defense. Additionally, explicitly mark in the prompt: all text coming from the page is data, not commands.

Method 2. Planning and Action Control: How to Keep the Agent from Getting Lost

The second-largest source of losses is looping and incorrect decisions. The agent clicks the same button five times because it didn't realize the action worked. Or it goes into endless catalog scrolling. Or, worse, submits a form it shouldn't have submitted. This method solves that problem by combining rigid frameworks with flexible logic inside them.

Framework: A Finite State Machine Instead of Free Flight

Describe a typical scenario as a set of states with explicit transitions: "search for product," "select from results," "extract data," "finish." Within each state, the agent acts flexibly, but it can only move along allowed edges. Such a framework constrains the error space and makes behavior explainable: you always know which state the agent is stuck in.

Step-by-Step Control Loop Construction

1. Separate planner and executor roles. The planner receives the goal and current state and returns the next step with rationale. The executor performs the step and returns the result fact. Separation lets you use a cheaper model for the executor.
2. Introduce postcondition checks. After each action, the agent must verify that the expected effect occurred: URL changed, element appeared, results counter updated. Without this, "clicked" doesn't equal "worked."
3. Cap the step budget. Set a maximum actions per task (usually 15–30) and a max repeat of the same action (2–3). If exceeded — not endless attempts, but task surrender with diagnostics.
4. Define the list of irreversible actions. Payment, sending messages, changing account settings, deletion. Before them — a mandatory pause and human confirmation, or a complete ban in that scenario.
5. Set up a domain allowlist. The agent must not stray outside permitted sites, even if there's a tempting link on the page.
6. Add a reflection mechanism on failure. If two consecutive actions produced no result, the agent switches to diagnostic mode: takes a screenshot, describes what it sees, and re-plans. This is more expensive than a normal step but cheaper than ten meaningless clicks.
7. Design resume points. Long scenarios must be able to continue after a browser or network failure from the saved state, not from scratch.

Example: Comparing SERPs Across Several Regions

A marketer's task: check what the top search results look like for ten queries across five regions. A naive agent opens a search engine and checks everything sequentially — fifty cycles, each with errors. The framework approach: state "set regional context" (via the corresponding proxy and settings), state "run query," state "extract positions," state "validate" (ten positions, each with URL and title). If invalid — one retry, then a "requires manual review" flag. Planning reduces to iterating a matrix; the model kicks in only for extraction and validation. Cost drops by an order of magnitude, and predictability rises.

Control Loop Readiness Evaluation Framework

• Is there an explicit list of states and transitions?
• Is each action's result verified?
• Is a step and repeat budget set?
• Are irreversible actions listed and how are they protected?
• Does a domain allowlist exist?
• What does the agent do when it doesn't understand what's happening?
• Can a task be resumed from the middle?

If even two answers are "no," the agent isn't ready to work unsupervised.

Insight: The Best Agent Is One That Rarely Thinks

Paradoxically, system maturity is measured by how rarely it calls the model. Everything that can be done deterministically — transitions, waits, schema validation — should be done by code. The model is needed where reality is unpredictable: interpreting a non-standard page, choosing between similar elements, recovering from failure. Such an AI agent is cheaper, faster, and, more importantly, more explainable.

Method 3. Network Layer and Session Identity: The Role of Mobile Proxies

Now for the layer developers most often underestimate and marketers most often overestimate. A developer thinks: "Hooked up a proxy — done." A marketer thinks: "A proxy will solve all my problems." The truth is in the middle: the network layer determines what the agent sees and how long it can operate, but it requires the same engineering care as the others.

Why an Agent Needs a Managed Network Layer at All

• Regional context. Prices, assortment, interface language, search results, shown ads — all depend on the exit point. An agent checking affiliate creatives or local prices must exit from the right region; otherwise the data is useless.
• Load distribution. A hundred parallel agents from one address look like an anomaly and create abnormal load on a site. Distribution across a pool of addresses is both proper behavior toward the resource and stability of your work.
• Session isolation. Different tasks and different accounts you legally operate must not overlap in network context.
• Resilience. Network failures and degradation of one channel must not halt the whole pipeline.

Why Mobile Proxies Specifically

Mobile proxies route traffic through cellular carrier networks. They have a property that makes them a natural choice for agents: carrier addresses are used simultaneously by a huge number of real subscribers and change constantly on reconnection. To a site, such traffic is indistinguishable from regular mobile internet users in that region, which is exactly what you need when the agent's goal is to see the site through the eyes of a regular visitor. Data center addresses, by contrast, are rarely associated with living people, and anti-bot systems treat them more strictly, applying tighter rate limits.

There's a second advantage specific to mobile audiences: a huge share of purchases and ad clicks happen from smartphones. An agent that checks a mobile landing page, mobile SERP, or a marketplace's mobile web version must also look like a mobile client at the network level. Mobile proxy plus mobile browser profile produce a consistent picture.

The Identity Consistency Principle

The main mistake of the network layer is inconsistency. The agent exits from one region over the network, but the browser timezone corresponds to another, the interface language to a third, and the screen resolution is a desktop monitor while the address is mobile. Sites notice such contradictions and react with increased scrutiny: showing more checks, limiting functionality, serving a stripped-down version. The architect's job is to build a session profile where all parameters are consistent: address region, timezone, language, device type, screen size. And this profile must be stable throughout a task.

Step-by-Step Network Layer Setup

1. Define the region matrix. Which countries and cities you need data from. One mobile proxy channel per point.
2. Bind the channel to a browser profile. One browser context, one channel, one task. Don't mix.
3. Configure address rotation policy. Two modes exist: hold the address for the duration of the task (needed for authenticated sessions and multi-step scenarios), and change the address between tasks (needed for collecting public data while distributing load). A good mobile proxy service offers rotation control via API and schedule.
4. Set rate limits. The agent must respect the site: human-like pauses between requests, a cap on concurrent sessions per domain. This isn't just ethics — it's practicality; sites you overload start returning errors specifically to you.
5. Comply with resource rules. Check the robots file and terms of use for the sites you work with. Public information for price and SERP monitoring is one thing; actions inside accounts are another, and they must only be performed within your rights to those accounts.
6. Build channel health checks. Before a task, the agent makes a test request: the address responds, the region is correct, latency is acceptable. Unhealthy channels are automatically excluded from the pool.
7. Log the network context of every task. Which channel, which address, which region, which server responses. Without this, you can't tell a model error from a network error.

Example Session Profile Configuration

{ "task_id": "price-monitor-ru-msk-042", "proxy_channel": "mobile-ru-msk-03", "rotation": "hold_until_task_end", "browser_profile": { "device": "mobile", "locale": "ru-RU", "timezone": "Europe/Moscow", "viewport": "390x844" }, "rate_limit": { "min_delay_ms": 1800, "max_parallel_per_domain": 2 } }

Note: the channel region, locale, timezone, and device type are consistent. That's the very contradiction-free identity we mean.

Bottleneck: Traffic Cost

Mobile traffic is more expensive than data center traffic, and the browser pulls images, fonts, and analytics scripts. The agent doesn't need most of that. Block media and third-party trackers at the browser level, as long as it doesn't affect page functionality. A 60–80 percent traffic savings is a typical result. The exception is visual agents that need the full picture; for them, choose which tasks really require screenshots.

Network Layer Checklist

• Each task exits through one mobile proxy channel of the required region.
• Browser parameters are consistent with the channel's region and device type.
• Rotation policy is chosen deliberately for the task type.
• Rate and concurrency limits per domain exist.
• Target resource usage rules are respected.
• The channel is tested before the task and excluded on degradation.
• Unnecessary media traffic is disabled.
• Network context is recorded in every task's log.

Method 4. Observability and Economics: How to Measure and Cut Costs

An agent without metrics is like an ad campaign without analytics: money goes out and it's unclear where. This method is about what to measure, how to debug, and where to find savings.

Five Key Web Agent Metrics

• Task success rate. And "success" must be verified automatically against the result schema, not by the agent's self-report. Agents tend to optimistically claim success.
• Steps per task. If it grows, the agent has started wandering; compare against a reference trajectory.
• Task cost. Model tokens plus traffic plus runtime time. Count in money, not tokens — that's more understandable to the business.
• Task time. Median and 95th percentile. The tail of the distribution usually points to looping.
• Failure cause categories. Network, site defense, model error, layout change, timeout. Without categorization, you don't know which layer to fix.

Task Trace as the Unit of Debugging

Every task should leave a trace: the sequence of steps, and for each — the observation (in compressed form), the model decision with rationale, the action, the postcondition check result, a screenshot at decision time. Such a trace lets you see in a minute exactly where things went wrong. Storing traces for all tasks is expensive; store them fully for failures and selectively for successes.

Step-by-Step Building of an Economical Agent

1. Measure the baseline cost. Run a hundred typical tasks and calculate the average cost and distribution. No baseline, no optimization.
2. Find the most expensive layer. Usually it's perception (60–80 percent of tokens). Apply Method 1.
3. Introduce model routing. Data extraction by schema, postcondition checks, simple choices — cheap model. Planning, failure recovery — expensive. A typical distribution in a mature system: 70–85 percent of calls go to the cheap model.
4. Cache what's stable. System instructions, tool descriptions, site dictionaries — all can be cached on the model provider's side, saving on repeated processing.
5. Replace the model with code where the trajectory has stabilized. If the agent has walked the same site the same way a hundred times, lock that path as a deterministic scenario with checks and keep the model only for handling deviations. This is called trajectory compilation, and it's the most powerful source of savings on mature scenarios.
6. Introduce budgets. A cost cap per task and per day with automatic halt. Agents that fall into a loop can burn a week's budget in an hour.

Reference Numbers

Based on our observations across typical monitoring and verification tasks, a naive agent on a flagship model with raw HTML spends on a ten-step task an amount equivalent to several cups of coffee, and takes two to three minutes. After applying the four methods, the same task costs 20–50x less and runs in 20–40 seconds, while the success rate grows from 50–60 to 85–95 percent. The spread is wide because it depends on the sites, but the order of magnitude is stable. Public benchmarks for autonomous web agents show a similar picture: the best systems solve about two-thirds of tasks, average ones half, and the gap is determined not so much by the model as by the engineering around it.

Observability Checklist

• Task success is verified automatically against a schema.
• Five metrics are collected and visible on a dashboard.
• Failures are categorized by layer.
• Traces of failed tasks are stored in full.
• There are budgets per task and per day.
• There is a regression task set that runs on any change to prompts, models, or tools.

Common Mistakes When Building Web Agents

Let's gather the rake steps almost every team steps on. We've mentioned some already, but repetition here is justified: these mistakes eat months.

Mistake 1. Starting with Full Autonomy

The team immediately builds a level-four agent that sets its own subtasks. The result is unpredictable behavior and undebuggable mess. Start with a semi-autonomous mode with a human in the loop, collect traces, stabilize, then raise autonomy.

Mistake 2. Trusting the Agent's Self-Report

The agent returns "task completed successfully," but the result data is empty or stale. Success verification must be external and formal: result schema, value ranges, required fields.

Mistake 3. Feeding the Model a Raw Page

The most expensive mistake in the literal sense. It also reduces quality: in noise, the model finds what it needs less well.

Mistake 4. One Address for All Tasks

A hundred parallel sessions from one data center address — guaranteed restrictions from sites and distorted data. The network layer needs to be designed, not tacked on as an afterthought.

Mistake 5. Inconsistent Session Identity

A mobile address from region A, a desktop browser with the timezone of region B, and the language of region C. Such sessions get a stripped-down experience and frequent checks.

Mistake 6. Too Many Tools

Forty available actions instead of eight. The model thinks longer, errs more in choosing, and the prompt bloats. A minimal set of primitives plus a few composite actions tailored to a specific scenario is the optimum.

Mistake 7. No Budgets

An agent that fell into a loop at night burns a month's model and traffic budget by morning. Hard budgets are not optional.

Mistake 8. Ignoring Resource Rules

Working with sites must stay within their terms of use and the law. The agent is your representative on the web, and its behavior is your responsibility. Public data for analytics, actions in your own accounts, respect for rate limits — yes. Everything else — no.

Mistake 9. Not Distinguishing Failure Types

"It didn't work" isn't a diagnosis. A network error is fixed on one layer, a layout change on another, a hallucination on a third. Without categorization, the team fixes the wrong thing.

Mistake 10. Not Defending Against Content Injection

A page is an untrusted source. Text on it may contain instructions that the model takes as commands. Perception filtering, explicit separation of data and commands in the prompt, a domain allowlist, and a ban on irreversible actions without confirmation are the mandatory minimum.

Mistake 11. No Regression Set

Changed the prompt — it got better on one site and worse on five others, but you found out a week later. A set of 30–50 reference tasks with automatic result verification, run on every change, saves you from this.

Tools and Resources for Building Web Agents

The ecosystem changes fast, so instead of specific versions, we'll give a map of categories and what to look at when choosing.

Browser Control

• Playwright — the de facto standard for new projects: support for all major browsers, context isolation, built-in element waiting, access to the accessibility tree. Most agent frameworks are built on top of it.
• Puppeteer — the historical predecessor for one browser family, still widely used.
• Selenium — the veteran, relevant where there's already a large testing infrastructure.

Browser Agent Frameworks

• Libraries that turn the browser into a set of tools for the model and implement the observe-and-act loop: open-source projects of the browser-use family, Stagehand, and similar. They already compress the page into a tree with IDs, so Method 1 in its basic form comes out of the box.
• General-purpose orchestrators with state graph support: LangGraph and similar. Useful for implementing the framework from Method 2.
• Official agent SDKs from model providers with computer-use mode. They deliver a visual agent turnkey, but demand special attention to cost.

Browser Runtimes

• Cloud remote browser services with session persistence, recording, and parallelism. They remove infrastructure headaches, but check whether they let you attach your proxies at the browser context level — this is critical for Method 3.
• Self-hosted deployment in containers — more control, more work. Justified at large volumes.

Network Layer

• Mobile proxies with API management. Key criteria: region selection down to city and carrier, address rotation control on demand and on schedule, channel stability, support for protocols your browser stack works with, and transparent traffic billing. A separate plus is the ability to pin a channel to a specific profile for the long term.
• Browser profile manager. For consistent session identity: timezone, language, screen size, device type. Can be a standalone product or a module of your system.

Observability

• Platforms for tracing model calls and agent steps with screenshot storage and cost accounting.
• Regular logging and metrics systems — don't neglect them; an agent's network and infrastructure metrics are no different from those of any service.

Quality Evaluation

• Public web agent benchmarks (task sets on real or recreated sites) — useful for understanding the ceiling of current models.
• Your own regression set — indispensable, because your sites and tasks are unique.

What to Read and Watch

Follow three directions. First — models with native computer use: they're rapidly getting cheaper and faster. Second — standards for agent traffic: the industry is discussing ways an agent can openly identify itself to a site via signed requests, and descriptor files by which a site explains to agents how to work with it correctly. Third — agentic browsers for end users: they shape expectations and change how sites treat automated visitors.

Case Studies and Results: How This Works in Practice

Below are four generalized scenarios from teams working with automation and mobile proxies. Numbers are rounded and given as reference points, not guarantees.

Case 1. Marketplace Price Monitoring for a Seller

Task. A seller with 600 SKUs wanted daily price and availability data from eight competitors on two platforms. Previously, a selector-based script did this, breaking every two weeks and taking two days to fix.

Solution. A DOM agent on the accessibility tree, a state framework of "search, card selection, extraction, validation," routing: cheap model for extraction, expensive only on failure. Network layer — a pool of mobile proxies of the required region, holding the address for the duration of a per-competitor task, a cap of two parallel requests per domain, 2–4 second pauses.

Result. Successful extraction rate in the first month — 93 percent versus 71 for the old script in "good" weeks. Fix time after a layout change — zero: the agent adapted itself in 9 out of 10 cases. Cost per card after trajectory compilation — comparable to a call to a paid data API, but with full control over freshness.

Case 2. Checking Ad Creatives and Landing Pages by Region

Task. An affiliate team ran campaigns in six regions and wanted to automatically verify that landing pages open correctly from mobile devices in each region, that redirects lead where they should, and that offers match the locale.

Solution. A hybrid agent: accessibility tree plus a mandatory screenshot of the final page. Session profiles strictly consistent: mobile proxy channel of the region, mobile screen size, matching language and timezone. Task result — a structured report with fields "opened, load time, final URL, content language, screenshot."

Result. Manual verification took one specialist about three hours a day. The agent does a full run in 12 minutes and launches every two hours. In the first month, 14 incidents of incorrect redirect region were detected, which previously were only spotted via conversion drops a day or two later. Ad budget savings are estimated by the team at tens of percent of the amount that used to go to non-working combinations.

Case 3. Regional SERP Audit for an SEO Agency

Task. The agency managed clients in twelve cities and wanted to see the actual SERP and search engine blocks for 300 queries in each city weekly.

Solution. A plan-and-execute agent: the "city per query" matrix is iterated by code, the model kicks in only for extracting and classifying SERP elements (organic, maps, shopping blocks, video). Network layer — mobile proxies with the channel pinned to the city, address rotation between queries, strict pauses.

Result. The cost of one verified query turned out to be several times lower than a subscription to a specialized service with comparable completeness, and more importantly — arbitrary SERP elements became extractable, which the service didn't have. The share of empty or invalid results is under 3 percent, all of which automatically go to re-verification.

Case 4. Website Acceptance Testing Before Release

Task. A small e-commerce team without a dedicated tester wanted to run user scenarios (search, cart, checkout up to the payment step) before each release on mobile and desktop profiles.

Solution. A semi-autonomous agent banned from irreversible actions (payment excluded at the forbidden-action list level). Scenarios are described in natural language, letting the product manager add new ones without a programmer. Mobile profiles run through mobile proxies so conditions are as close as possible to real users.

Result. A regression run of 40 scenarios — 25 minutes instead of half a workday manually. Over a quarter, the agent caught 9 regressions before they hit production. An interesting side effect: the agent's traces became documentation of user paths that didn't exist before.

What Successful Cases Have in Common

• The task had a formal result contract.
• Autonomy was bounded by a state framework.
• The network layer was designed as part of the architecture, not tacked on at the end.
• Cost and success were measured from day one.
• The model was used sparingly, deterministic code wherever possible.

FAQ: Questions That Come Up in Week Two of a Pilot

How does an AI agent fundamentally differ from an advanced parser?

A parser executes a predefined sequence and extracts data by fixed rules. An agent receives a goal, builds a plan itself, observes each action's result, and adapts. A parser is deterministic and cheap but fragile. An agent is flexible but more expensive and needs control. In practice, the optimum is a hybrid: the agent scouts and recovers from failures, while stable trajectories are compiled into deterministic code.

Which model should I choose for a web agent?

Not one, but at least two. A cheap and fast one for schema-based data extraction, checks, and simple decisions. A flagship for planning and failure recovery. A multimodal one is needed if you're plugging in screenshots. The selection criterion isn't an abstract ranking, but the result on your regression task set at a given budget.

Why does the agent pass the demo but its production success rate drop by half?

Demos are shown on familiar sites at a lucky moment. Production brings pop-ups, regional interface versions, slow loading, rate limits, layout changes. Each factor takes off a few percent of success. It's treated by the methods in this article: perception compression, a state framework with postcondition checks, a consistent network layer, and failure categorization to fix the right layer.

Why does an agent need mobile proxies if it's not doing anything forbidden?

Precisely because it's doing permitted things, it's important for it to see the site the way a regular user of the required region on the required device type sees it. Data center addresses don't give that experience: sites treat them more strictly, show more checks and stripped-down versions, and the regional context doesn't match. Mobile proxies provide traffic indistinguishable from that of real subscribers, natural address changes, and precise geography. Plus load distribution, which is equally useful to you and the sites you work with.

How often should I rotate the proxy address while the agent is working?

It depends on the task type. Multi-step scenarios within one session, especially with authentication in your own accounts, require holding the address until the task completes: changing the address mid-session looks anomalous to the site. Collecting public data from a large number of pages benefits from rotation between tasks. The universal rule: the address changes at task boundaries, not within them.

How do I defend against a page "reprogramming" the agent?

Four measures. Perception filtering: only structure and relevant text enter the model. Explicit separation in the prompt: all page content is data, not commands. A domain allowlist: the agent physically can't go to an external site. Protection of irreversible actions: payment, sending, deletion require human confirmation or are banned in the scenario. No single measure is absolute; together they reduce risk to acceptable levels.

How much does one web agent task cost?

The range is huge: from fractions of a cent to several dollars per ten-step task. The defining factors are the perception format (raw HTML versus accessibility tree yields a difference of tens of times), model choice, number of steps, and traffic. A naive implementation is expensive; after applying the four methods, a 20–50x savings is typical. Count cost in money per task from day one and set budgets.

Can I skip the browser and work only through site APIs?

Where an API exists and its terms allow — yes, and it's always cheaper and more reliable. But a huge portion of data important for marketing and e-commerce is available only through the interface: regional SERPs, ad display, real prices with personalization, landing page appearance. That requires a browser. A reasonable strategy is API where possible, browser agent where necessary.

How do I know the agent is ready to work unsupervised?

When on a regression set of 30–50 tasks the success rate is consistently above your threshold (usually 90 percent), failures are categorized and don't contain "unknown cause," irreversible actions are protected, budgets and alerts exist, and traces let you break down any incident in minutes. Until then — keep a human in the loop at least for sample result verification.

What will change in web agents over the next year or two?

Three trends. Models with native computer use will get cheaper and faster, shifting the balance toward visual agents. Commonly accepted ways will emerge for an agent to identify itself openly to a site, with the site explaining interaction rules to agents — this will make relations between automated clients and resources more transparent. And agentic browsers for regular users will accustom sites to the fact that a significant share of visitors act through an intermediary. For those working with automation, this means: engineering around the model, including the network layer, will remain the main competitive advantage, because the models themselves are quickly leveling out.

Conclusion: An Agent Is a System, Not a Model

If you take one thought from this article, it's this: the quality of a web agent is determined not by which model it has inside, but by how the layers around it are designed. Perception determines how much you pay and how well the agent understands the page. The control loop determines whether it gets lost. The network layer determines what it even sees and whether it can operate stably. Observability determines whether you learn about problems before they get expensive.

We've covered the seven-layer architecture and the bottleneck map, four practical methods with checklists, eleven common mistakes, a tool map, and four scenarios where it all worked. What to do next?

1. Pick one task with clear value and a formal success criterion. Price monitoring, landing page checks by region, SERP auditing — anything you do today by hand or with a fragile script.
2. Build a semi-autonomous agent on the accessibility tree with a state framework and a step budget. Don't chase autonomy.
3. Design the network layer right away. Mobile proxies of the required region, a consistent session profile, rate limits, respect for resource rules.
4. Turn on metrics from the first run. Success, steps, cost, time, failure categories.
5. Collect a hundred traces, build a regression set, and only then optimize: model routing, history compression, trajectory compilation.

The web was built for humans, and it's tough for agents out there. But that's precisely why a well-designed AI agent offers such an advantage: it does what only humans used to do, at machine speed and scale. The engineer's job is to make sure this machine sees clearly, thinks economically, acts carefully, and goes online like a law-abiding visitor. Then bottlenecks turn into clear engineering tasks, and the agent into a reliable employee that never gets tired.