Agentic Browser Automation: Domain Explainer#

Who this is for: You’ve seen a demo of an AI clicking through a website and you’re wondering whether it’s a real technique or a party trick. This page answers “is this domain relevant to me?” — not “which tool should I pick?” (that’s S1–S4).

Reading time: 5 minutes.

The Hardware Store Analogy#

Every hardware store sells two things that look related and aren’t.

The first is a key-cutting machine. You bring a key, it traces the exact profile, and it produces an identical copy. Fast, cheap, perfectly repeatable. It will make you ten thousand identical keys and never tire. What it cannot do is open a lock it hasn’t been given the key for — it has no idea what a lock is. It copies a shape.

The second is a locksmith. Slower, vastly more expensive, occasionally wrong. But you can hand them a door they’ve never seen and say “I need to get in,” and they will look at it, form a theory, try something, watch what happens, and adapt. They understand the goal, not the shape.

Traditional browser automation is the key-cutting machine. You record the exact sequence — click the element with this CSS selector, type into that field, submit — and it replays flawlessly, thousands of times, until the website’s designer moves a button. Then it produces a perfect copy of a key that no longer fits, and it does so silently.

Agentic browser automation is the locksmith. You describe the goal in words — “find the pricing page and tell me what the enterprise tier costs” — and a language model looks at the page, decides what to click, clicks it, looks again, and keeps going until it’s done or stuck.

The trade is exactly what you’d expect from that analogy. The locksmith costs more per job, takes longer, and occasionally gets it wrong. But the locksmith still works when the door changes, and the key-cutter doesn’t.

The Problem#

Enormous amounts of valuable functionality exist only behind a web interface.

There is no API for most of the web. Your supplier’s order portal, that government filing system, the SaaS tool your finance team lives in, the competitor’s pricing page, the legacy internal application whose vendor was acquired in 2019 — all of these have a user interface and nothing else. The data and the actions are right there on screen, and completely unreachable by ordinary code.

The traditional answer is scripted automation: write code that drives a real browser, targeting elements by selector. This works, and has worked for two decades. Its failure mode is specific and relentless.

Scripts break on cosmetic changes. A redesign that moves a button, renames a CSS class, or wraps a field in an extra div breaks a script that was working perfectly. The site’s function is unchanged; a human user wouldn’t notice. The script is broken anyway.

They break silently and at scale. You find out from missing data or a failed batch, often days later.

Maintenance dominates. Teams that automate against a dozen external sites spend more effort repairing scripts than they ever spent writing them. Every site you add is a permanent maintenance liability, and they don’t coordinate their redesigns.

They can’t handle variation. One supplier’s form has fields in a different order. Another asks an extra question. Each variant needs its own branch, and the branches multiply.

The underlying issue is that a selector-based script encodes what the page looked like, while what you actually cared about was what you were trying to do. Those were the same thing on the day you wrote it, and they drift apart forever after.

What This Layer Actually Does#

An agentic browser tool puts a language model inside the automation loop:

1. Observe — capture the current page state, as a structural description, an image, or both
2. Decide — the model determines the next action toward the stated goal
3. Act — click, type, scroll, navigate
4. Repeat — observe the new state and reassess, until done or stuck

The consequence is that instructions become intentions rather than coordinates. “Log in and download last month’s invoice” survives a redesign, because the model looks at whatever is on screen now and figures out where the login is — the same way you would.

That is the entire value proposition, and everything else in this domain is a consequence of it.

The Four Tiers, Which Get Confused Constantly#

This is the single most useful thing to understand before shopping, because vendors, comparison articles, and casual conversation blur four genuinely different products into one word.

Tier 1 — The driver. The library that actually controls a browser: Playwright, Puppeteer, and the underlying Chrome DevTools Protocol. It clicks and types when told precisely what to click and type. It contains no intelligence and never will. Every tier above is built on top of one of these.

Tier 2 — The agent framework. A library that wraps a driver in an LLM decision loop. You give it a goal; it runs the observe-decide-act cycle itself. This is what most people mean by “browser agent.”

Tier 3 — The MCP server. A different delivery model for the same capability: instead of being an agent, it exposes browser control as tools that some other agent — your coding assistant, your own harness — can call. The intelligence lives in the harness you already have; this just gives it hands.

Tier 4 — The hosted runtime. Where the browser process physically runs. Running hundreds of concurrent Chrome instances with realistic network identities is an infrastructure problem entirely separate from deciding what to click. These services solve that and nothing else.

The clarifying question is: who decides the next action?

• Tier 1: you do, in code you wrote
• Tier 2: an LLM does, inside the framework’s own loop
• Tier 3: an LLM does, inside your harness
• Tier 4: nobody — it’s a place for a browser to run

These stack; they don’t compete. A realistic deployment is an agent framework (2) driving Playwright (1) against a browser running on a hosted runtime (4). Comparing a framework against a runtime is a category error, and published comparisons make it routinely.

The Two Ways to Look at a Page#

Within tier 2, there’s a genuine technical fork worth understanding, because it predicts where a tool will succeed and fail.

DOM-driven tools feed the model a structured text description of the page — the element tree, accessibility labels, form fields. The model reasons over structure and returns an element to act on.

Vision-driven tools feed the model a screenshot. The model reasons over pixels and returns coordinates to click.

Neither is strictly better, and the difference maps onto real failure modes. DOM approaches are cheaper (text is cheaper than images), more precise, and blind to anything not in the DOM — canvas-rendered interfaces, images of text, visual layout carrying meaning. Vision approaches see the page as a human does, handle visually complex or non-standard interfaces, and cost more while being less precise about exactly which pixel constitutes the button.

Published measurements as of 2026 favour DOM-driven approaches on common tasks by a meaningful margin. Hybrid approaches — structure first, pixels when structure is insufficient — are where most serious tools have converged.

Trade-Offs Worth Understanding Before You Shop#

It is slow and expensive compared to a script. Every step is an LLM inference call. A scripted flow completing in two seconds might take a browser agent thirty, and cost real money per run. For a task you run ten thousand times a day against a page that never changes, a script is still correct. The agent earns its cost through resilience and variation, not throughput.

It is non-deterministic. The same instruction against the same page can produce different action sequences. Usually fine, occasionally not — and it means testing gives you a probability rather than a guarantee. For workflows that move money or submit legal filings, that distinction matters a great deal.

Reliability is genuinely imperfect. Published success rates on standard benchmarks sit somewhere in the 60–90% range depending on benchmark and task. That is remarkable compared to what was possible three years ago, and it is not the reliability of a working script. Plan for failure handling as a first-class concern, not an edge case.

The websites don’t want you there. Bot detection, CAPTCHAs, and rate limiting exist and are getting better. Much of the hosted-runtime industry’s value is navigating this, which places the whole domain in a permanent, somewhat adversarial relationship with the sites it operates against. This is a strategic consideration, not a technical detail.

Giving a model control of a real browser is a real security surface. It has your session cookies. It sees whatever is on screen. If it can be steered by text on a page it visits — and that is an active, unsolved class of attack — it can be steered into actions you did not intend, using your logged-in identity.

When You Need This Domain#

You probably need it if:

• You need data or actions from sites that offer no API and never will.
• You maintain scripted automation against external sites and the maintenance is winning.
• Your task varies across many sites doing conceptually the same thing.
• You’re building an agent whose usefulness depends on reaching the web.
• You need occasional access to something a script would be over-engineering for.

You probably don’t need it if:

• An API exists. Use it. This entire domain is a workaround for the absence of one, and a worse choice whenever one is available.
• Your target site is stable and the task is high-volume and identical every time — a script is faster, cheaper, and deterministic.
• The task must be exactly right every time with no tolerance for failure.
• You need it to run in milliseconds.

The honest middle ground, and where a lot of production systems land: scripts for the parts that are stable, agents for the parts that vary. Deterministic navigation to get to the right page, model reasoning for the step that differs across sites. Cheaper than pure-agent, more resilient than pure-script.

The One Thing to Take Away#

This domain converts brittle instructions into durable intentions.

The reason a script rots is that it records what a page looked like on a particular Tuesday. The reason an agent doesn’t is that it records what you were trying to accomplish, and re-derives the “how” every time.

You pay for that in latency, cost, and certainty. Whether that’s a good trade depends almost entirely on one question: how often does the page change, and how much does it cost you when it does?

If the answer is “never” and “nothing,” write a script. If you maintain automation against sites you don’t control, you already know what the answer is.

Where to Go Next#

• S1 — the four tiers and what’s in each
• S2 — how they work, and what the benchmark numbers actually measure
• S3 — five personas and which tier fits each
• S4 — which of these survive, in a domain with unusual adversarial risk

Related surveys: 1.118 (testing libraries — where Playwright is covered as a testing tool), 1.212 (AI coding agent harnesses — increasingly the consumers of tier 3), 2.074 (MCP, the protocol tier 3 speaks), 1.215 (LLM proxies — routing the model calls these agents make), 1.201 (agent frameworks generally).

browser-use#

Vendor: browser-use (Magnus Müller, Gregor Žunič — Zurich / San Francisco) Tier: 2 — agent framework Language: Python License: MIT Quadrant: DOM-driven × agent-first Verified: 2026-08-05

What It Is#

browser-use is the category’s centre of gravity by a very large margin. A Python library that takes a natural-language goal and runs the full observe-decide-act loop against a real browser until the task is complete or it gives up.

The design is deliberately agent-first: you do not describe steps, you describe an outcome. Every meaningful decision goes through live LLM inference. The agent observes page state, determines the next action, executes it, reassesses, and continues.

Its adoption is extraordinary and worth stating plainly, because it dominates every other signal in this category.

Adoption and Maturity#

108k stars places it among the most-starred AI projects in existence — roughly 4.5× Stagehand and Skyvern combined. For context within this survey’s own library, that exceeds the star count of every option in 1.215’s LLM proxy category put together.

Star counts measure attention rather than production use, and this project has benefited from unusually viral demo content. But the commit count (10,022) indicates sustained engineering rather than a demo that went viral and stalled, and the ecosystem effect is real: browser-use is the default assumption in most tutorials, integrations, and job-posting requirements in this space.

On the benchmark claim: the repository states 87.4% on the Odysseys leaderboard across 200 long-horizon tasks. Widely circulated secondary sources instead report “89.1% on WebVoyager.” That figure does not appear in the primary source, and WebVoyager and Odysseys are different benchmarks with different task sets. The primary claim is the one reported here; the secondary figure should be treated as unverified.

Key Capabilities#

Natural-language goals. The interface is an instruction, not a script. This is the whole point and it is what makes the tool resilient to layout change.

DOM-driven perception. The model receives a structured representation of the page — elements, labels, form fields — rather than pixels. Cheaper per step than vision, more precise about which element is being acted on, and blind to content that isn’t in the DOM.

Self-correcting loop. When an action fails or the page changes unexpectedly, the agent re-observes and re-plans rather than crashing. This is the behaviour that distinguishes tier 2 from tier 1 and it is the reason the maintenance burden differs so sharply.

Model-agnostic. Works across providers rather than being coupled to one lab’s model — which is exactly the kind of workload 1.215’s proxy layer exists to serve.

Python-native. Matters more than it sounds. The overwhelming majority of AI engineering happens in Python, so this integrates directly into the stack where agents are already being built, with no bridging.

License and Cost#

MIT. Genuinely permissive, no enterprise directory, no dual-license carve-out. The library itself costs nothing.

The real cost is inference. Every step is an LLM call, and a long-horizon task may take dozens of steps. This is the dominant operating expense of the entire category and it is easy to underestimate — a task that a script completes for free may cost meaningful money per run here. S2 examines the economics.

There is a commercial cloud offering from the same team for teams that would rather not operate the runtime themselves.

Trade-Offs vs Alternatives#

vs Stagehand — the defining comparison in tier 2, and it is a genuine philosophical split rather than a feature gap. browser-use is agent-first: the model decides everything, maximizing resilience and cost. Stagehand is hybrid: deterministic Playwright code for stable steps, model reasoning only where it varies. Stagehand costs less and behaves more predictably; browser-use handles situations you didn’t anticipate. Choose by whether you know in advance which parts of your flow are stable.

vs Skyvern — DOM against vision. browser-use reads structure; Skyvern looks at pixels. browser-use is cheaper and more precise on conventional web interfaces; Skyvern handles canvas-rendered and visually unconventional pages that have nothing useful in the DOM. Also a significant licensing difference: MIT against AGPL-3.0.

vs the tier-3 MCP servers — a different delivery model entirely, and the comparison most worth thinking about. browser-use is an agent. Playwright MCP and Chrome DevTools MCP give browser control to an agent you already have. If you’re building a standalone automation, browser-use is the right shape. If you already run an agent harness and want it to reach the web, tier 3 is less machinery for the same capability.

The Honest Weaknesses#

Cost and latency scale with task length. Every step is inference. Long-horizon tasks are slow and expensive, and the cost is proportional to how much the agent has to think — which is exactly what you can’t predict in advance.

Non-determinism. The same goal against the same page can produce different action sequences. Usually acceptable; genuinely disqualifying for workflows that must be exactly reproducible.

DOM blindness. Canvas-rendered interfaces, images of text, and layouts where visual position carries meaning are weak spots by construction. This is the price of the cheaper, more precise perception model.

Reliability is good, not guaranteed. 87.4% on a hard long-horizon benchmark is a genuinely strong result for this technology and it is not the reliability of a working script. Failure handling must be designed in.

Star count outruns production evidence. 108k stars is a real signal of attention; public accounts of large-scale production deployment are much thinner than that number suggests. This is not a criticism of the project — it is a caution against reading popularity as proven operational maturity.

S1 Verdict#

Carry to S2: yes — as the category reference point.

browser-use is where a reader in tier 2 should start, and the option every other agent framework is implicitly measured against. Its adoption is the dominant fact in the category, its MIT license is unencumbered, and Python-native is the right default for the ecosystem where agents actually get built.

S2 should examine the per-step economics, since inference cost is the category’s real operating constraint, and establish what the Odysseys benchmark measures — because the number most readers will encounter is from a different benchmark entirely.

Skyvern#

Vendor: Skyvern AI Tier: 2 — agent framework Language: Python (TypeScript SDK available) License: AGPL-3.0 (open core; proprietary anti-bot measures in managed cloud) Quadrant: Vision-driven × agent-first Verified: 2026-08-05

What It Is#

Skyvern is the vision-driven option: rather than feeding the model a structured description of the page, it feeds it what the page looks like, and the model reasons over the image.

The design rationale is stated directly by the project: code-defined XPath interactions break whenever website layouts change, so Skyvern relies on vision LLMs to learn and interact with websites instead. It is the most committed expression in this survey of the idea that a browser agent should see the web the way a person does.

Two things make it distinct beyond perception model: an explicit focus on form-filling and transactional workflows rather than general browsing, and a licensing posture unlike anything else in tier 2.

The License, Which Is the First Thing to Check#

AGPL-3.0, with proprietary anti-bot measures reserved to the managed cloud.

This is the single most consequential fact about Skyvern for most evaluators, and it is buried in most comparisons.

AGPL is strong copyleft with a network clause: if you modify Skyvern and make it available over a network, you must offer your modified source to users of that service. Many organizations — including a large share of enterprises — have blanket policies prohibiting AGPL dependencies in commercial products precisely because of this clause, and those policies are typically enforced by automated dependency scanning rather than by case-by-case judgment.

Compare directly: browser-use is MIT, Stagehand is MIT, both Playwright MCP and Chrome DevTools MCP are Apache-2.0. Skyvern is the only AGPL option in this survey.

This does not make it a bad tool. It makes it a tool whose licensing must clear legal review before its technical merits are worth evaluating, and for many buyers that review returns a no. Teams should establish their organization’s AGPL policy first — otherwise the evaluation is wasted effort.

The commercial cloud offering exists in part to resolve this, which is a coherent and common open-core structure: AGPL discourages competitors from hosting it, while paying customers get terms they can live with.

Adoption and Maturity#

22.7k stars puts it level with Stagehand and far behind browser-use. The commit count (6,356) is substantial — considerably higher than Stagehand’s — indicating serious sustained engineering.

On benchmarks: the repository claims 64.4% overall on WebBench and best-in-class performance on WRITE tasks (forms, logins, downloads). Widely circulated secondary sources instead report “85.85% on WebVoyager.” That figure does not appear in the primary source, and WebBench and WebVoyager are different benchmarks. The 64.4% WebBench figure is the primary claim and the one reported here.

The WRITE-task claim is the more useful signal anyway, and it is consistent with the architecture: filling forms correctly across visually varied layouts is exactly what vision-driven perception should be good at, and it is a harder, more commercially valuable problem than read-only browsing.

Key Capabilities#

Vision-based interaction. The differentiator. Handles pages where the DOM is unhelpful — canvas-rendered interfaces, image-heavy layouts, non-semantic markup, visual grouping that carries meaning no accessibility tree captures.

Layout-variation resilience. The strongest case for vision: the same conceptual form rendered differently across fifty supplier portals looks recognizably like a form in every one of them, while its DOM structure may share nothing.

Form and transaction focus. Product emphasis on completing workflows — logins, submissions, downloads — rather than general exploration.

Self-hosted or cloud. Full local deployment via pip or Docker Compose, or a managed service. The self-hosted path is real, subject to the license.

Workflow orchestration. More structure around multi-step, multi-site processes than a bare agent loop provides.

Trade-Offs vs Alternatives#

vs browser-use — the perception fork, and the clearest either/or in tier 2. browser-use reads the DOM: cheaper per step, more precise, blind to non-DOM content. Skyvern looks at pixels: costlier, sees everything a human sees, less precise about exact targets. Published measurements as of 2026 favour DOM-driven approaches on common tasks by roughly 12–17 percentage points — but “common tasks” means conventional web pages, which is precisely where vision’s advantage doesn’t apply. Choose vision for the pages that defeat DOM parsing, not as a general-purpose default.

And the licensing gap is decisive for many: MIT vs AGPL-3.0.

vs Stagehand — different structuring strategies. Stagehand structures with code and needs you to know the flow; Skyvern structures with vision and needs the page to be visually legible. For a known flow across known sites, Stagehand is cheaper. For the same form across fifty unknown sites, Skyvern is the better shape.

vs tier-3 MCP servers — Skyvern is a full workflow product, considerably more than a tool surface. Teams wanting browser capability inside an existing harness are not the buyer here.

The Honest Weaknesses#

AGPL-3.0 disqualifies it for many buyers before evaluation begins. Stated first because it is the most common outcome.

Vision is expensive. Image tokens cost more than text tokens, and every step processes a screenshot. This is the highest per-step cost model in tier 2 by a clear margin.

Vision localizes less precisely. Identifying which pixel constitutes the button is a harder problem than reading an element ID, and it is a real source of misclicks.

Lower benchmark score on general tasks. 64.4% on WebBench, against browser-use’s 87.4% on Odysseys — though these are different benchmarks and not directly comparable, which is exactly the confusion the secondary sources have created. The defensible reading is that Skyvern is strong on transactional WRITE tasks and less strong on open-ended browsing.

The comparison content problem is acute here. Skyvern publishes comparisons of its competitors — a “Browser Use vs Stagehand” article appears on skyvern.com. That material should be read as marketing.

S1 Verdict#

Carry to S2: yes — with the license as a gating question.

Skyvern is the right tool for a genuinely distinct problem: transactional workflows across visually varied sites where DOM parsing fails. The vision-first architecture is a real technical position, not a gimmick, and the WRITE-task focus targets the commercially valuable half of browser automation.

But AGPL-3.0 means the evaluation order is inverted for this option: establish whether your organization permits AGPL dependencies before assessing anything else, because for a large fraction of buyers that answer ends the evaluation regardless of merit.

S2 should size the vision cost premium and examine what WebBench measures, since the comparison most readers will make is against a number from a different benchmark.

Stagehand#

Vendor: Browserbase, Inc. Tier: 2 — agent framework Language: TypeScript (official Python implementation available) License: MIT Quadrant: DOM-driven × hybrid Verified: 2026-08-05

What It Is#

Stagehand is the hybrid answer in tier 2, and it is the option built around a specific critique of pure agents: most of a browser workflow is stable, and paying an LLM to re-derive it every time is waste.

Rather than handing the model the whole task, Stagehand lets you write ordinary deterministic Playwright code for the parts that don’t change, and drop into AI-driven steps only where the page varies or you don’t know the structure in advance. The two styles interleave in the same script.

It is developed and maintained by Browserbase — which is also tier 4 in this survey. That relationship is strategically significant and is examined in S4: the framework is free and excellent, and it is also the on-ramp to a paid runtime.

The API Shape, and Why It Explains the Product#

Stagehand’s primitives are the clearest expression of its philosophy:

• act() — perform a single natural-language action (“click the login button”)
• extract() — pull structured data off the page
• observe() — inspect what’s available before acting
• agent() — hand over a multi-step task entirely, browser-use style

The presence of both act() and agent() is the whole design. You choose the granularity of delegation per step. A workflow can be 90% deterministic code, 8% single AI actions, and 2% full agentic delegation — and you decide which is which.

This is the capability that distinguishes it, and it maps directly onto cost: if 80% of your workflow is deterministic Playwright and only 20% invokes a model, inference cost falls proportionally.

Adoption and Maturity#

23.7k stars is a strong second in tier 2 — roughly a fifth of browser-use’s, and comparable to Skyvern’s. The commit count is lower than its peers, consistent with a younger and more focused codebase built on Playwright rather than reimplementing the driver layer.

A correction worth making explicitly: widely circulated comparisons state that Stagehand is TypeScript-only and that Python teams must wrap it in a subprocess or sidecar. An official Python implementation exists (browserbase/stagehand-python, linked from the main repository). Teams should evaluate the Python implementation’s maturity relative to the TypeScript original — they are not necessarily at parity — but the “TypeScript shops only” framing found in secondary sources is not accurate as stated.

Key Capabilities#

Interleaved deterministic and AI steps. The core differentiator. Write what you know; delegate what you don’t.

Self-healing on cached actions. When a previously working action fails because the DOM shifted, Stagehand re-engages the model to find the new mapping and continues. This is the mechanism that gives hybrid code script-like cost with agent-like resilience, and it is the most technically interesting idea in tier 2.

Structured extraction. extract() returns schema-conforming data rather than prose, which matters a great deal when the output feeds a pipeline rather than a human.

Playwright underneath. Inherits Playwright’s cross-browser support, mature tooling, and debugging ecosystem rather than reimplementing the driver tier. Teams with existing Playwright investment can migrate incrementally.

Browserbase integration. Pairs natively with the hosted runtime, though it runs perfectly well against a local browser.

License and Cost#

MIT, unencumbered. Costs nothing to use.

The economics are the selling point. Because deterministic steps cost nothing and only AI steps invoke a model, a well-structured Stagehand workflow can be dramatically cheaper per run than an equivalent agent-first flow. The saving is real and it is proportional to how much of your workflow you can express deterministically.

The catch: that proportion is only knowable if you understand the target site’s structure in advance. For a workflow across dozens of sites you’ve never seen, the deterministic fraction approaches zero and the cost advantage disappears.

Trade-Offs vs Alternatives#

vs browser-use — the tier-2 decision. Stagehand wins on cost, predictability, and debuggability when you know your target sites. browser-use wins when you don’t, and on ecosystem size and Python-nativeness. The question is not which is better but whether your workflow’s structure is known in advance.

vs Skyvern — both are more structured than pure agents, in different ways. Stagehand structures by code; Skyvern structures by vision. Stagehand needs you to know the flow; Skyvern needs the page to be visually legible. Licensing differs sharply: MIT vs AGPL-3.0.

vs tier-3 MCP servers — Stagehand is the closest tier-2 option to tier 3 in spirit, since act() is essentially a single tool call. The difference is that Stagehand is a library you build a program with, while an MCP server is a capability you hand an existing agent.

The Honest Weaknesses#

The hybrid advantage requires foreknowledge. The cost saving comes from writing deterministic code for stable steps — which presumes you know which steps are stable. For exploratory work or long-tail site coverage, that advantage evaporates and you’re running an agent with extra ceremony.

Vendor relationship is worth understanding. Browserbase makes this free and excellent and also sells the runtime it integrates with most naturally. The framework runs fine locally; the gravitational pull toward the paid product is real and is a strategic consideration, not a defect.

Python implementation maturity is a live question. The official implementation exists; whether it tracks the TypeScript version’s features and release cadence should be verified against current state rather than assumed.

Smaller ecosystem than browser-use. Fewer examples, fewer integrations, fewer people who have hit your problem before.

Deterministic code is still selector-based, and selectors still rot. The self-healing mechanism mitigates this and does not eliminate it — the hybrid model inherits a share of the brittleness it was designed to escape, proportional to how much deterministic code you wrote.

S1 Verdict#

Carry to S2: yes.

Stagehand is the strongest option for a common and under-served case: a team automating a known set of sites, wanting agent resilience without agent economics. The interleaved model is the most sophisticated idea in tier 2, and the self-healing mechanism is the category’s best answer to the maintenance problem that motivates the whole domain.

S2 should quantify the cost difference against agent-first approaches and examine the self-healing mechanism, since that is what determines whether hybrid genuinely escapes selector rot or merely defers it.

S1 Rapid Discovery — Approach#

Stage goal: Map the category and produce a shopping-guide comparison.

Date executed: 2026-08-05

Category Definition#

In scope: Software that lets a language model drive a real web browser toward a stated goal — observing page state, deciding actions, and executing them — plus the delivery mechanisms and runtime infrastructure that make that practical.

The boundary test — who decides the next action?

This test is the organizing idea of the survey. It separates cleanly, it survives the fact that all four tiers talk about “browser automation,” and it explains why the tiers stack rather than compete.

Explicitly out of scope:

The 1.110.4 correction. The nearest existing slot, Browser Python Execution, is about running Python inside a browser via WebAssembly. It has no relationship to agent-driven browser control beyond sharing the word “browser.” This survey exists partly to stop that slot being mistaken for coverage of this domain.

Why This Category Needed Its Own Slot#

Checked against existing coverage:

• 1.118 Testing Libraries has a full playwright.md — Playwright is covered thoroughly, as a testing tool. Correct, and it stops at the driver tier.
• 1.110.4 is Pyodide/PyScript, a different subject entirely.
• 1.212 AI Coding Agent Harnesses covers agents that write code, several of which consume browser MCP servers — but the browser tier itself is unexamined.
• 2.074 MCP covers the protocol, not its browser implementations.

Nothing covered the agent tier, the browser MCP servers, or the hosted runtimes.

Selection Criteria#

Profiled in depth if it meets all four:

1. An LLM is in the loop, or the option exists to serve one (tiers 3 and 4).
2. Generally applicable — not tied to one vendor’s product or one site.
3. Production evidence — meaningful adoption, or first-party backing by a major vendor.
4. Maintained — verified activity within 90 days.

The Options Covered#

Tier 2 — Agent frameworks (full per-option treatment)

Tier 3 — MCP servers (covered together in mcp-servers.md)

Tier 4 — Hosted runtimes (covered together in hosted-runtimes.md)

Plus long-tail.md for the honest census.

The Two Axes#

Axis 1 — Perception: how does the model see the page?

DOM-driven feeds a structured text representation — element tree, accessibility labels, form fields. Cheaper, more precise, blind to anything not in the DOM. Vision-driven feeds screenshots. Sees what a human sees, handles canvas and non-standard interfaces, costs more and localizes less precisely.

Axis 2 — Autonomy: how much is decided by the model?

Agent-first means the model decides every step. Maximum resilience, maximum cost and variance. Hybrid means deterministic code for stable steps, model reasoning only where it varies. Cheaper and more predictable; requires knowing in advance which parts are stable.

                    DOM-DRIVEN                    VISION-DRIVEN
                 ┌────────────────────────────┬────────────────────────────┐
  AGENT-FIRST    │  browser-use               │  Skyvern                   │
  (model decides │  (+ tier-3 MCP servers,    │                            │
   every step)   │   driven by your harness)  │                            │
                 ├────────────────────────────┼────────────────────────────┤
  HYBRID         │  Stagehand                 │  (hybrid vision is where   │
  (code + model) │                            │   the field is heading)    │
                 └────────────────────────────┴────────────────────────────┘

Sources and Their Reliability#

This category’s information environment is worse than 1.215’s, and that survey already flagged its own as unusually polluted.

Comparison content is dominated by vendors comparing themselves to competitors — a “Browser Use vs Stagehand” comparison published by Skyvern, a third competitor, was among the top search results while researching this survey.

More seriously, benchmark figures circulating in secondary sources do not match primary sources. Three specific discrepancies found on 2026-08-05:

The pattern is that numbers get copied between articles while the benchmark name attached to them drifts. A reader comparing tools on secondary-source benchmark figures is comparing numbers that were never measured on the same test.

Handling applied throughout: adoption figures, licenses, and benchmark claims are taken from repositories and official documentation, dated, and attributed to the specific benchmark named by the source. Where a vendor published a comparison of its own product, that is stated inline.

Verification date for all figures: 2026-08-05. decay_class: fast.

Output#

• agent-browser-use.md, agent-stagehand.md, agent-skyvern.md — tier 2
• mcp-servers.md — tier 3
• hosted-runtimes.md — tier 4
• long-tail.md — census
• recommendation.md — S1 verdict

Tier 4 — Hosted Browser Runtimes#

Options: Browserbase, Steel.dev Verified: 2026-08-05

What This Tier Is#

Where the browser process actually runs.

Deciding what to click and running hundreds of concurrent Chrome instances are entirely different problems, and the second one is harder than it looks. A browser is a heavy, stateful, memory-hungry process. Running one on a laptop is trivial; running two hundred concurrently, each with a plausible network identity, surviving crashes, with session state that persists across steps, is an infrastructure discipline of its own.

Tier 4 solves that and nothing else. These are not alternatives to tier 2 or tier 3 — they are where tier 2 and tier 3 run. Published comparisons pitting Browserbase against browser-use are comparing a place against a decision-maker.

Why This Tier Exists At All#

Three problems that a local browser doesn’t have and a production deployment does:

Concurrency and cost. Each browser instance consumes hundreds of megabytes and real CPU. Scaling to meaningful concurrency means a fleet, and a fleet means autoscaling, health checks, and crash recovery for processes that crash more than most.

Network identity. Sites increasingly detect and block datacenter IPs, headless browser fingerprints, and automation signals. Getting a page to load at all can require residential proxies, fingerprint management, and CAPTCHA handling. This is specialized, adversarial, and constantly changing.

Session persistence. Long workflows need cookies and authentication to survive across steps and sometimes across runs. Managing that state across an ephemeral fleet is fiddly.

The third-party value here is concentrated in the second problem. Anyone can run containers with Chrome in them; keeping those browsers able to reach sites is the part that requires ongoing adversarial work — and it is exactly the part with the most uncomfortable strategic profile, examined in S4.

Browserbase#

The best-capitalized dedicated player in this tier, and strategically the most interesting company in the survey — because it operates at two tiers simultaneously.

Browserbase gives away an excellent tier-2 framework (Stagehand, MIT) and sells the tier-4 runtime it integrates with most naturally. That is a coherent and well-executed strategy: the framework is genuinely free and genuinely good, it runs fine against a local browser, and it creates a natural path to the paid product at the moment a team needs scale. It is the same shape as the open-core patterns in 1.215, executed across tiers rather than within a product.

Capabilities beyond raw browser hosting include managed sessions, session replay for debugging, and state persistence — the operational tooling that distinguishes a service from a container.

Steel.dev#

The open-source answer in tier 4, and the reason this tier isn’t a pure buy decision.

Self-hosting is the strategic differentiator. A team that cannot send browser traffic through a third party — because sessions carry authenticated access to sensitive systems — has exactly one option in this tier, and it is Steel. That constraint is common enough in regulated environments to make this a category-defining property rather than a nice-to-have.

The pricing is unusually legible. Roughly $0.05–$0.10 per browser-hour makes the build-vs-buy arithmetic straightforward — compare directly against what a container running Chrome costs you, plus the proxy and fingerprinting work you’d be taking on.

The free tier is substantial. 100 hours/month is enough for real development and low-volume production, not a trial.

Choosing Between Them#

The last row is the most important and the most skipped. Development, low-volume tasks, and anything running on a machine you already have need no tier-4 product at all. Playwright launches a browser perfectly well. This tier is an answer to scale and network identity, and adopting it before you have those problems is buying infrastructure for a workload you don’t have.

The Honest Weaknesses#

The value proposition is partly adversarial, and that is a strategic risk. A meaningful share of what these services provide is defeating bot detection — residential proxies, fingerprint management, CAPTCHA handling. That places the tier in a permanent arms race with the sites it operates against, and it carries legal and terms-of-service exposure that is the customer’s to manage. This is the most uncomfortable fact about tier 4 and it is discussed nowhere in the vendors’ marketing. S4 takes it up.

Cost scales with wall-clock time, not work done. Browser-hours are billed whether the browser is thinking, waiting on a slow page, or idle mid-task. Agent workflows are slow by nature — every step is an LLM call — so an agent-driven session burns browser-hours during inference. Tier 2’s latency is tier 4’s bill, and the two costs compound in a way neither vendor’s pricing page makes obvious.

Another dependency in a hot path. A runtime outage stops all automation, and there is no local fallback unless you built one.

Sessions carry real credentials. Whatever the browser is logged into, the runtime provider’s infrastructure handles. For Browserbase that is an unavoidable third-party trust decision; Steel’s self-hosted path is the answer.

S1 Verdict#

Carry to S2: yes — as infrastructure, not as an alternative to tiers 2 and 3.

The tier is real and necessary at scale, and irrelevant below it. The decision is genuinely simple: self-host if policy requires it (Steel), buy if it doesn’t (Browserbase or Steel Cloud), and skip the tier entirely until concurrency or bot detection makes it necessary — which for many readers is never.

S2 should examine the compounding cost model, since agent latency multiplied by browser-hour pricing is the category’s least obvious expense, and treat the adversarial positioning honestly.

The Long Tail#

Options meeting part of the category definition that did not warrant primary coverage, recorded so the census is honest. Each entry states why it sits here.

Verified: 2026-08-05

Computer-Use Models (Anthropic, OpenAI)#

Why they’re here: they do the same job from a completely different direction, and they are the most likely long-run disruption to tier 2.

Rather than a framework wrapping a model, these are models trained to operate computers — taking screenshots and emitting actions natively. No framework decides how to observe or what to prompt; the capability is in the model’s weights.

Why not primary: they are model capabilities, not software you adopt, so they belong to 3.200’s territory rather than this survey’s. They also compete with tier 2 in an interesting way: a sufficiently capable computer-use model makes the framework layer thinner, since the observe-decide-act loop moves into the model.

Note on the vision comparison: published 2025–2026 measurements put DOM-driven stacks 12–17 percentage points ahead of vision-driven approaches including computer-use models on common tasks. That gap is the strongest current argument for the framework layer continuing to exist, and it is exactly the kind of gap that closes.

Watch item: if computer-use model reliability reaches DOM-driven levels, tier 2’s value proposition narrows substantially. This is the category’s most significant strategic uncertainty and S4 takes it up.

Puppeteer MCP#

Why it’s here: a third first-party-ish MCP option in tier 3.

Chromium-focused, lighter than Chrome DevTools MCP, typically chosen for quick local screenshots or DOM extraction rather than deep debugging.

Why not primary: it occupies a narrow slice between Playwright MCP (cross-browser) and Chrome DevTools MCP (deep Chrome). For most readers one of those two is the better answer, and the adoption signal reflects that.

Browserless#

Why it’s here: an established tier-4 competitor predating the agent wave.

Headless browser hosting, positioned against Steel and Browserbase, with a longer history serving scraping and testing workloads.

Why not primary: its centre of gravity remains conventional headless automation rather than agent workloads, and it is less integrated with tier 2. A reasonable option for teams already using it; not where an agent-focused evaluation would start.

Firecrawl and the extraction-first wing#

Why it’s here: frequently mentioned in the same conversations, solving a narrower problem.

These focus on turning web pages into clean structured data — crawling and extraction — rather than acting on pages. Many use headless browsers internally.

Why not primary: read-only. No clicking, no form submission, no authenticated workflows. If the task is “get the content of these pages,” this wing is cheaper, faster, and more reliable than any browser agent. A meaningful number of teams evaluating browser agents actually want extraction and would be better served here — worth checking before adopting anything in tier 2.

Vendor Browser Agents (Claude in Chrome, and similar)#

Why they’re here: browser agency delivered as a product feature rather than a library.

Vendor-operated agents that browse on a user’s behalf inside a specific browser or assistant.

Why excluded from primary: not adoptable infrastructure. You cannot build a product on them the way you can on browser-use or an MCP server. They are end-user products, and they belong in 3.xxx territory.

But they matter competitively: for the persona whose need is “let me delegate a web task,” a vendor agent may fully satisfy it with no engineering at all. That is a real substitution risk for tier 2 at the low end.

Selenium#

Why it’s here: the historical incumbent, still enormous in installed base.

Why excluded: tier 1, and no LLM in the loop. The same reasoning that places Playwright in 1.118 places Selenium there. It appears in this category only as the thing teams are migrating away from.

Census Note#

Three observations from assembling this list.

The category is stratified, not consolidated. Unlike 1.215’s LLM proxies, where five options compete for the same job, this category’s serious options mostly occupy different tiers and stack rather than substitute. That makes “which should I choose” a worse-formed question here than in most surveys — the better question is “which tiers do I need at all.”

Adoption is extraordinarily concentrated at two points. browser-use (108k stars) and Chrome DevTools MCP (48.6k) tower over everything else, and they are in different tiers answering the same need two ways. That the second-largest project in the category is not an agent is the most interesting structural fact in this survey.

The information environment is the worst encountered in this library’s LLM cluster. Beyond the usual vendor-authored comparisons, benchmark figures are being copied between secondary sources with the wrong benchmark names attached — three separate instances documented in approach.md. A reader doing their own research will encounter confident, specific, incorrect numbers.

Tier 3 — Browser MCP Servers#

Options: Playwright MCP (Microsoft), Chrome DevTools MCP (Google) Licenses: Apache-2.0 (both) Verified: 2026-08-05

What This Tier Is#

A different delivery model for the same capability, and the most strategically interesting development in this category.

Tier 2 gives you an agent that browses. Tier 3 gives your existing agent hands. Rather than adopting a framework that runs its own decision loop, you attach a browser tool surface to a harness you already run — a coding agent, an assistant, your own orchestration — and the intelligence stays where it already lives.

The delivery mechanism is MCP (2.074), which means these servers work with any MCP-capable client rather than being coupled to one vendor’s agent.

Why this matters strategically: the question shifts from “which browser agent framework should I adopt?” to “should I adopt one at all, or just give my existing agent browser access?” For the very large population of teams already running an MCP-capable harness — a fast-growing group, per 1.212 — tier 3 is dramatically less machinery for substantially the same outcome.

The adoption numbers below suggest the market is answering that question decisively.

Chrome DevTools MCP (Google)#

48.6k stars makes this the second-most-adopted project in the entire survey, behind only browser-use — and ahead of Stagehand and Skyvern combined. For a project that is not an agent at all, that is a striking signal about where the category’s centre of gravity is moving.

Capabilities span far beyond clicking: navigation (6 dedicated tools), performance trace recording with actionable insights, Lighthouse audits, network request inspection, screenshots, heap snapshots for memory analysis, and console messages with source-mapped stack traces.

The distinguishing property is depth, not breadth. This is not a generic automation surface — it is the Chrome DevTools Protocol exposed to an agent. An agent using it can do things no tier-2 framework can: profile a page’s runtime performance, audit accessibility, inspect why a network request failed, analyze a memory leak. It is the difference between driving the browser and debugging it.

The cost is portability: Chrome and Chrome for Testing only, officially. Other Chromium browsers may work without guarantee. No Firefox, no WebKit.

A security note the project states itself, and which deserves amplification: the server exposes the content of the browser instance to MCP clients, allowing them to inspect, debug, and modify any data in the browser or DevTools. That is an enormous trust surface — if the browser holds authenticated sessions, an agent with this access effectively holds them too.

Playwright MCP (Microsoft)#

The cross-browser option, and first-party from the same organization that maintains Playwright itself (covered as a testing tool in 1.118).

The distinguishing property is determinism through the accessibility tree. Rather than screenshots or raw DOM, it presents the page’s accessibility structure — the same representation screen readers consume. That is a semantically meaningful, relatively stable view of a page: elements carry roles and labels rather than arbitrary class names.

Cross-browser support is the concrete advantage. Testing or automating against Firefox and WebKit is possible here and impossible with Chrome DevTools MCP.

7.3k stars is an order of magnitude below its Google counterpart. The likely explanation is scope: Chrome DevTools MCP’s 61 tools cover debugging and profiling workloads that appeal to a much broader set of developers than cross-browser automation does.

Choosing Between Them#

They are complementary more than competitive, and the practical guidance found across independent write-ups is to install both in lean modes and let the agent choose — cheaper than being wrong.

The clean framing: Playwright MCP is for driving the browser; Chrome DevTools MCP is for debugging it. Automation versus inspection.

Trade-Offs vs Tier 2#

What tier 3 gives you that tier 2 doesn’t:

• No new agent. The intelligence stays in the harness you already run and already trust. One less framework, one less loop, one less thing to operate.
• Portability. MCP is a protocol, so the server works with any compliant client. Not coupled to one framework’s abstractions.
• First-party backing. Microsoft and Google respectively — a different durability profile from a startup’s framework.
• Depth on Chrome’s side. Performance and debugging capabilities no tier-2 framework offers.

What tier 2 gives you that tier 3 doesn’t:

• A complete agent. Tier 3 is a tool surface; something must still decide what to do with it. If you don’t already have a harness, tier 3 is half a solution.
• Task-level abstractions. browser-use’s “accomplish this goal” and Stagehand’s extract() are higher-level than raw tool calls, and that abstraction is real work you’d otherwise do yourself.
• Purpose-built workflow structure. Skyvern’s orchestration has no tier-3 equivalent.
• Optimized loops. A framework can tune its observe-decide-act cycle; a generic harness calling generic tools cannot.

The Honest Weaknesses#

Chrome DevTools MCP is Chrome-only, officially and firmly. For cross-browser needs this is disqualifying rather than inconvenient.

Both are trust surfaces of unusual size. An agent with browser control has your sessions. Chrome DevTools MCP’s own documentation says it exposes browser content to MCP clients for inspection and modification. Combined with prompt injection from page content — an active, unsolved attack class — this is the most serious security consideration in the survey, developed in S2 and S4.

Quality depends on the harness. Tier 3’s outcome is a function of the agent driving it. The same server produces excellent results in a capable harness and poor ones in a weak one, which makes tier-3 evaluation genuinely harder than tier-2 evaluation.

Tool-call overhead. Fine-grained tools mean more round trips than a purpose-built loop would need, though a well-designed harness mitigates this.

S1 Verdict#

Carry to S2: yes — and this tier may matter more than tier 2 for many readers.

Chrome DevTools MCP’s 48.6k stars is the strongest signal in this survey that the category is shifting from “adopt a browser agent” toward “give your existing agent browser access.” For the growing population already running MCP-capable harnesses (1.212), tier 3 is less machinery for the same capability, with first-party vendor backing and permissive licensing.

S2 should examine what “61 tools” actually buys, how the accessibility-tree approach compares to DOM and vision perception, and treat the security surface seriously — it is the aspect of this category most likely to produce a serious incident.

S1 Recommendation — Category Verdict#

Date: 2026-08-05

The Category in One Paragraph#

Four tiers that stack rather than compete: a driver that clicks (1.118’s territory), an agent framework that decides, an MCP server that lends browser control to an agent you already have, and a hosted runtime where the browser physically runs. The question a reader should ask is not “which tool” but “which tiers do I actually need” — and for a growing number of readers the answer skips tier 2 entirely.

The Map#

                    DOM-DRIVEN                    VISION-DRIVEN
                 ┌────────────────────────────┬────────────────────────────┐
  AGENT-FIRST    │  browser-use  108k ★ MIT   │  Skyvern  22.7k ★ AGPL-3.0 │
                 │  Chrome DevTools MCP 48.6k │                            │
                 │  Playwright MCP  7.3k      │                            │
                 ├────────────────────────────┼────────────────────────────┤
  HYBRID         │  Stagehand  23.7k ★ MIT    │  (where the field is       │
  (code + model) │                            │   heading)                 │
                 └────────────────────────────┴────────────────────────────┘

  Tier 4 (runtime, orthogonal):  Browserbase ($67.5M)  ·  Steel.dev (OSS + hosted)

Six Findings That Survived S1#

1. The boundary test is “who decides the next action”#

You (tier 1, → 1.118), an LLM in the tool’s own loop (tier 2), an LLM in your harness (tier 3), or nobody (tier 4, it’s just where the browser runs). This separates cleanly and explains why the tiers stack. Comparisons that pit a framework against a runtime — common in published material — are comparing a decision-maker against a place.

2. The second-biggest project in the category is not an agent#

Chrome DevTools MCP has 48.6k stars — behind only browser-use’s 108k, and ahead of Stagehand and Skyvern combined. It is a tool surface, not an agent.

That is the most interesting structural fact here. It suggests the market is answering “which browser agent framework should I adopt?” with “none — I’ll give the agent I already have browser access.” For teams already running an MCP-capable harness (see 1.212, where that population is growing fast), tier 3 is far less machinery for substantially the same capability, with first-party vendor backing and Apache-2.0 licensing.

Readers should evaluate tier 3 before tier 2, which inverts how every published comparison frames the decision.

3. Secondary-source benchmark numbers are wrong, specifically and checkably#

Four discrepancies between circulated figures and primary sources, found on 2026-08-05:

The pattern: numbers get copied between articles while the benchmark name attached drifts. A reader comparing these tools on secondary-source figures is comparing numbers that were never measured on the same test. This is worse than 1.215’s vendor-marketing problem, because these figures look specific and authoritative.

4. Licensing splits the agent tier decisively#

browser-use MIT. Stagehand MIT. Both MCP servers Apache-2.0. Skyvern AGPL-3.0.

AGPL’s network clause means many organizations prohibit it outright, enforced by automated dependency scanning rather than case-by-case review. For those buyers the evaluation order inverts: establish the AGPL policy first, because a no ends the assessment regardless of technical merit. This is the most consequential single fact about Skyvern and it is buried in most comparisons.

5. DOM beats vision on common tasks — which is not where vision’s case lies#

Published measurements put DOM-driven stacks 12–17 percentage points ahead of vision-driven approaches on common tasks. But “common tasks” means conventional web pages, which is exactly where DOM parsing already works.

Vision’s case is the pages that defeat DOM parsing — canvas interfaces, image-based layouts, non-semantic markup, the same conceptual form rendered fifty different ways across supplier portals. Choose vision for that, not as a general default. The headline gap measures the wrong thing for the decision it’s used to justify.

6. Tier 2’s latency is tier 4’s bill#

Browser runtimes charge by wall-clock browser-hour (~$0.05–$0.10 at Steel). Agent workflows are slow because every step is an LLM call. The browser sits billing while the model thinks.

These two costs compound, and neither vendor’s pricing page makes that visible. It is the category’s least obvious expense and it falls hardest on exactly the agent-first, long-horizon workflows tier 2 markets most enthusiastically.

Provisional Positioning#

Not recommendations — those come in S3 and S4.

Carried to S2#

All tiers, with these questions:

1. Tier 3 vs tier 2 — what do you genuinely give up by skipping the framework layer? This is the decision most readers should be making and no published comparison frames it.
2. What do Odysseys, WebBench, and WebVoyager actually measure? Without this the benchmark numbers are noise, and readers will encounter them everywhere.
3. Stagehand’s self-healing — does hybrid escape selector rot or merely defer it?
4. The vision cost premium — image tokens per step, quantified.
5. The compounding cost model — agent latency × browser-hour pricing.

Cross-cutting question for S2: the security surface. An agent driving an authenticated browser holds your sessions, and Chrome DevTools MCP’s own documentation states it exposes browser content to MCP clients for inspection and modification. Combined with prompt injection from page content — an active, unsolved attack class — this is the aspect of the category most likely to produce a serious incident, and it is barely discussed in any vendor’s material.

browser-use — Technical Deep-Dive#

Verified: 2026-08-05

Architectural Overview#

browser-use implements the canonical agent-first loop with no deterministic escape hatch by design. You supply a goal; the framework owns every subsequent decision.

  goal (natural language)
        │
        ▼
  ┌──────────────────────────────────────────┐
  │  OBSERVE — serialize DOM to text         │
  │    element tree, labels, form fields,    │
  │    interactive elements indexed          │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  DECIDE — LLM call                       │
  │    given page + goal + history,           │
  │    emit next action                       │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  ACT — Playwright executes                │
  └──────────────┬───────────────────────────┘
                 │
                 └──► repeat until done or stuck

The critical design decision is in OBSERVE: the page is serialized to a text representation of interactive elements rather than raw HTML or a screenshot. Raw HTML is far too large and mostly irrelevant; a screenshot costs image tokens and loses precision. A filtered, indexed element list is compact, cheap, and unambiguous about what can be acted on.

This is what makes DOM-driven approaches cheaper per step than vision, and it is the architectural reason for the 12–17 point advantage on common tasks reported in independent measurement — the model receives a cleaner signal about what is actionable.

The Economics, Which Are the Real Constraint#

Every loop iteration is an LLM call. This is the dominant cost and the thing most underestimated at adoption.

The cost model:

  total cost ≈ steps × (context tokens + output tokens) × model rate

Where context grows with history — each step carries prior actions forward — so cost per step increases as a task progresses. A twenty-step task does not cost twice a ten-step task; it costs more, because later steps carry more context.

Practical consequences:

• Long-horizon tasks are superlinearly expensive.
• The 87.4% Odysseys result is on long-horizon tasks — precisely the expensive regime. Strong capability and high cost are the same fact.
• Context management (summarizing history rather than accumulating it) is the primary lever, and its aggressiveness trades cost against coherence.

Compared to a script: a scripted flow costs approximately nothing per run. browser-use costs real money every time. The agent is not competing on unit economics and never will — it competes on not breaking when the page changes, and on handling situations nobody scripted.

The break-even framing: agent cost per run against script maintenance cost amortized over runs. For a stable site run ten thousand times daily, scripts win overwhelmingly. For fifty sites that each change unpredictably, the maintenance term dominates and the agent wins. Most real workloads sit between, which is the argument for hybrid.

Non-Determinism and What It Means Operationally#

The same goal against the same page can produce different action sequences across runs. This is inherent — the model samples.

What it breaks:

• Test assertions on exact action sequences
• Reproducing a failure from a bug report
• Compliance regimes requiring demonstrable repeatability
• Cost prediction — the same task may take eight steps or eighteen

What it doesn’t break: outcomes, usually. Different paths reaching the same result is generally fine, and is precisely the flexibility being purchased.

The operational posture that works: assert on end state rather than path, log full action traces for post-hoc debugging, set hard step limits so a confused agent fails rather than looping expensively, and treat cost as a distribution rather than a number.

Perception Limits#

DOM serialization is the architecture’s strength and its precise failure boundary. It cannot see:

For conventional, reasonably semantic web pages — the large majority — none of these matter. For the pages where they do, DOM-driven perception fails in a way no amount of model capability fixes, because the information genuinely is not in the input.

This is the case for vision, and it is narrow but real. It is not a general superiority argument, which is how the DOM-vs-vision debate is usually mis-framed.

Model Agnosticism#

Works across providers rather than coupling to one lab. Practically important for two reasons.

Cost control: step cost varies enormously by model. A workload that is uneconomic on a frontier model may be fine on a cheaper one, and much of the loop — routine navigation — doesn’t need frontier reasoning.

This is exactly the workload 1.215’s proxy layer serves. An agent making thousands of model calls with varying difficulty is the canonical case for routing: cheap models for navigation, capable models for the hard decisions. The two categories compose naturally and neither survey’s vendors mention the other.

Failure Modes#

Getting stuck in loops. The agent tries something, it fails, it tries again similarly. Step limits are the backstop and should be set deliberately rather than left at defaults — this is the most common source of surprise cost.

Confident wrong actions. The model believes it has completed the task when it hasn’t. Harder than crashing, because nothing signals failure. End-state verification separate from the agent’s own judgment is the mitigation.

Cascading misunderstanding. An early wrong turn poisons subsequent context. The agent proceeds coherently from a false premise.

Cost runaway. A task that should take eight steps takes eighty. Without limits, this is discovered on an invoice — the same failure shape 1.215 documented for LLM proxy budgets, and the same answer: enforce a ceiling.

Deployment Profile#

Python library, pip-installable, no mandatory external state. Runs against a local browser via Playwright, or against a tier-4 runtime for scale.

Lighter than the equivalent in 1.215’s category — no database, no cache, no service tier. The operational burden is the browser and the model spend, not the infrastructure.

S2 Assessment#

The agent-first architecture is coherent and its costs are structural, not implementation defects. Every step being a model call is what delivers resilience; it is also what makes it expensive and non-deterministic. These are the same property.

DOM serialization is the right default — cheaper and more precise than vision on the pages most people automate, with a narrow, well-defined blind spot.

The economics are the binding constraint, not capability. Adoption decisions in this category are usually made on demos and revisited on invoices. Context growth making later steps costlier is the specific mechanism, and step limits are the specific control.

The 108k stars represent attention more than proven production scale. The engineering is real; public evidence of large unattended production deployment is thinner than the number implies.

Skyvern — Technical Deep-Dive#

Verified: 2026-08-05

Architectural Overview#

Skyvern inverts the perception decision: the model receives a rendered screenshot rather than a serialized element tree, and reasons about the page as an image.

  goal
    │
    ▼
  ┌───────────────────────────────────────────┐
  │  OBSERVE — screenshot                     │
  │    the page as rendered, pixels           │
  └───────────────┬───────────────────────────┘
                  ▼
  ┌───────────────────────────────────────────┐
  │  DECIDE — vision LLM                      │
  │    identify target visually,              │
  │    emit action + location                 │
  └───────────────┬───────────────────────────┘
                  ▼
  ┌───────────────────────────────────────────┐
  │  ACT — driver executes                    │
  └───────────────────────────────────────────┘

The project’s stated rationale is direct: code-defined XPath interactions break whenever layouts change, so vision LLMs learn and interact with sites the way a person does.

The architectural bet: visual appearance is more stable across sites and redesigns than DOM structure. For the specific problem of the same conceptual form rendered across many different sites, this is defensible — fifty supplier portals share no markup and all look recognizably like forms.

The Cost Premium, Quantified Structurally#

Vision is the most expensive perception model in tier 2, and the mechanism is worth being precise about.

Image tokens dominate. A screenshot consumes far more tokens than a filtered element list — typically an order of magnitude, depending on resolution and model. And unlike a DOM serialization, a screenshot cannot be filtered down to “just the interactive elements” without losing the information that justified using vision in the first place.

Every step pays it. The loop structure is identical to browser-use’s; only the per-observation cost differs. So the premium multiplies across the whole task.

Resolution is a direct cost-accuracy dial. Lower resolution is cheaper and loses small text and fine targets; higher resolution reads reliably and costs more. There is no setting that is cheap and precise.

The compounding problem: vision costs more per step and localizes less precisely, so misclicks add retry steps, each paying the premium again. The two effects reinforce rather than cancel.

Practical consequence: Skyvern’s economics are worst on long-horizon tasks and best on short transactional ones — which aligns exactly with its stated WRITE-task focus. The architecture and the product positioning are coherent.

Localization: The Hard Part of Vision#

Reading a page visually is the easy half. Acting on it requires converting “the submit button” into a specific place to click.

Why this is genuinely hard: the model must produce coordinates or a region, and coordinate precision is a known weakness of vision models. Small targets, dense layouts, and elements near each other are error-prone in a way element-ID targeting simply is not.

Why DOM approaches don’t have this problem at all: an element reference is exact. There is no localization step, no coordinate estimation, no adjacent-element risk.

This is the mechanical explanation for the 12–17 point gap on common tasks reported in independent measurement. It is not that vision models reason worse — it is that DOM-driven approaches skip an entire error-prone stage.

Where the gap inverts: when there is no element to reference. Canvas, images of text, purely visual state. Then DOM has nothing and vision has everything.

The WRITE-Task Focus#

Skyvern claims best-in-class on WebBench WRITE tasks — logins, forms, downloads — with 64.4% overall.

Why this is architecturally credible: form-filling is exactly where visual understanding helps most. A form’s visual structure — label above field, related fields grouped, required markers — is consistent across sites in a way its markup is not. And forms are typically short-horizon, which is where vision’s cost premium hurts least.

Why WRITE tasks matter commercially: reading is the cheap half of browser automation and often better served by extraction tools (see long-tail.md). Submitting, logging in, transacting — that is where the value and the consequences are.

The caveat carried from benchmarks.md: WebBench is published by Skyvern. The benchmark’s design is more rigorous than the alternatives on every axis, and a vendor’s score on a vendor’s benchmark is not independent evidence.

AGPL-3.0, Technically#

The licensing deserves technical framing because its implications depend on deployment shape.

The network clause (AGPL §13): if you modify the software and make it available to users over a network, you must offer those users your modified source.

How this plays out:

The practical reality overrides the legal nuance: most organizations do not litigate this per-case. They run automated dependency scanning with a blanket AGPL prohibition, and the build fails. For a large fraction of commercial buyers the answer is no before anyone reads §13.

Skyvern Cloud is the designed resolution — the managed service carries commercial terms plus proprietary anti-bot measures not in the open version. This is coherent open-core: AGPL deters competitors from hosting it, paying customers get workable terms.

Evaluation order for this option is inverted: establish the AGPL policy first. Every other consideration is downstream of that answer.

Deployment#

Self-hosted via pip or Docker Compose, or Skyvern Cloud.

Heavier than its tier-2 peers. Docker Compose implies multiple services — browser infrastructure, workflow orchestration, a UI. Closer to a platform than a library, and operationally more than pip install browser-use.

The proprietary split is worth noting: anti-bot measures are reserved to the managed cloud. So self-hosted Skyvern is genuinely less capable at reaching defended sites than Skyvern Cloud — not a licensing technicality but a functional difference that matters for exactly the hostile-site workloads WebBench measures.

Failure Modes#

Misclicks from imprecise localization. The characteristic vision failure. Adjacent elements, small targets, dense layouts.

Resolution-dependent blindness. Small text may be unreadable at cost-effective resolutions — a silent failure where the model confidently misreads.

Cost escalation on long tasks. The premium compounds; long-horizon work is where this architecture is least economical.

Dynamic visual state. Animations, transitions, lazy-loaded content mean a screenshot may capture an intermediate state. DOM approaches can wait for structural conditions; vision has a weaker equivalent.

S2 Assessment#

Vision-first is a legitimate architectural position with a narrow, real domain: pages where the DOM offers nothing useful, and transactional workflows across visually varied sites.

The cost premium and precision deficit are structural, not implementation gaps. Vision pays more per step and adds an error-prone localization stage that DOM approaches skip entirely. That is the mechanical source of the measured gap on conventional pages.

The WRITE-task focus is architecturally coherent and targets the commercially valuable half of the domain — but its evidence is a vendor benchmark.

AGPL-3.0 is the decisive practical fact. It is the only copyleft option in the survey, it is typically enforced by automated scanning rather than judgment, and it ends the evaluation for many buyers before merit is considered.

Self-hosted is functionally weaker than cloud on defended sites, because anti-bot measures are proprietary. Buyers evaluating the open version against hostile targets are not evaluating what the cloud delivers.

Stagehand — Technical Deep-Dive#

Verified: 2026-08-05

Architectural Overview#

Stagehand’s architecture is a direct answer to browser-use’s economics: if most of a workflow is stable, paying a model to re-derive it every run is waste.

Rather than owning the loop, Stagehand hands control back to you and offers four primitives you invoke at whatever granularity you choose.

  your program (TypeScript or Python)
      │
      ├─ page.goto('...')              ← plain Playwright, costs nothing
      ├─ page.click('#known-selector') ← plain Playwright, costs nothing
      │
      ├─ act("click the login button") ← one LLM call
      ├─ extract({ schema })           ← one LLM call, structured output
      ├─ observe()                     ← inspect available actions
      │
      └─ agent("book the cheapest flight")  ← full delegated loop, many calls

The design consequence: cost is proportional to how much you delegate, and you choose that per step. A workflow that is 90% deterministic navigation and 10% AI-assisted costs roughly 10% of an agent-first equivalent.

agent() matters as much as act(). It means Stagehand is not only the hybrid option — it can behave exactly like browser-use where you want that, within the same script. The product is the granularity control, not a fixed position on the spectrum.

Does Self-Healing Escape Selector Rot, or Defer It?#

S1 carried this question because Stagehand’s entire value proposition depends on it.

The mechanism: Stagehand caches resolved actions. On a subsequent run, a cached action is replayed directly — no model call, script-speed. When a cached action fails because the DOM shifted, Stagehand re-engages the model to find the new mapping, updates the cache, and continues.

What this genuinely achieves: the steady-state cost of a script with the recovery behaviour of an agent. In the common case nothing is spent; in the broken case it repairs itself instead of failing. That is a real and elegant result, and it is the best answer in the category to the maintenance problem that motivates the whole domain.

The honest answer to the question: it substantially escapes rot for AI-resolved steps, and does not escape it at all for hand-written deterministic steps.

The distinction matters and is not well communicated:

So the brittleness a Stagehand workflow retains is proportional to how much deterministic code you wrote — which is the same proportion that generates the cost saving.

This is the central trade and it is exact: every deterministic step is cheaper and more brittle; every act() step is costlier and self-healing. Stagehand doesn’t resolve the tension, it exposes the dial and lets you set it per step. That is a genuinely better design than either extreme, and it is not a free lunch.

The corollary for practitioners: use deterministic code for structural navigation that rarely changes (domains, well-known URLs, stable landmarks) and act() for the parts that actually vary. Using page.click() on a deep, obscure selector to save a model call is buying back the exact fragility you adopted the tool to escape.

Structured Extraction#

extract() returns schema-conforming data rather than prose. Architecturally this is the same observe-and-reason step with the output constrained to a caller-supplied schema.

Why it matters disproportionately: most browser automation exists to feed a pipeline, not a human. An agent that returns “the enterprise plan appears to cost around $500 a month” requires parsing and is unreliable. One that returns {plan: "enterprise", price: 500, currency: "USD", period: "month"} is directly usable.

This capability is the one most likely to be the actual reason a team picks Stagehand, and it gets less attention than the hybrid story.

Language Support, Corrected#

S1 recorded that secondary sources claim TypeScript-only. An official Python implementation exists (browserbase/stagehand-python), linked from the main repository.

What remains a genuine evaluation question: whether the Python implementation tracks the TypeScript original in features and release cadence. Ports frequently lag. Teams choosing Python should verify current parity on the specific primitives they need rather than assuming either parity or absence.

The TypeScript-first orientation is real — the main repository is TypeScript, 1,415 commits — and for a category where most AI engineering happens in Python, that is a meaningful ecosystem consideration even with a Python port available.

Playwright Foundation#

Stagehand builds on Playwright rather than reimplementing browser control. Consequences:

Inherited: cross-browser support, mature debugging tooling, trace viewer, established patterns, and a large body of existing knowledge (much of it covered in 1.118).

Migration path: a team with existing Playwright automation can adopt Stagehand incrementally — keep working code, replace only the brittle parts with act(). No other option in this survey offers incremental adoption from an existing investment, and for teams with substantial Playwright suites that is a significant practical advantage.

Security Posture, Incidentally#

Noted in security.md and worth restating here because it is under-marketed: deterministic steps cannot be prompt-injected. They are not model-mediated. Text on a page cannot influence page.click('#submit').

So the same dial that trades cost against brittleness also trades attack surface. A workflow that is 90% deterministic has 10% of the injection exposure of an agent-first equivalent.

This is a genuine architectural security advantage and Stagehand does not appear to mention it anywhere.

Failure Modes#

Cache staleness across structural redesigns. Self-healing handles incremental drift well. A wholesale redesign may invalidate many cached actions simultaneously, producing a cost and latency spike as everything re-resolves at once — the pattern being a sudden expensive run rather than a broken one.

Deterministic steps failing hard. By design, no recovery. Failure looks like an ordinary script failure.

Over-determinization. The natural pressure is to convert working act() calls into selectors to save cost, which reintroduces brittleness gradually and invisibly. Worth an explicit team convention.

Python parity gaps. See above.

S2 Assessment#

The hybrid model is the most sophisticated architecture in tier 2, and the self-healing cache is the category’s best answer to selector rot.

The answer to S1’s question is precise: rot is escaped for AI-resolved steps and fully retained for hand-written ones, in exact proportion to the cost saving. The dial is real and honest; there is no free lunch, and the documentation could be clearer that the saving and the fragility are the same knob.

Structured extraction may be the more common real reason to adopt it than the hybrid economics.

The incremental migration path from existing Playwright is unique in this survey and under-discussed.

The security property — deterministic steps are injection-proof — is a genuine advantage nobody is marketing.

S2 Comprehensive Analysis — Approach#

Stage goal: How these systems work, and where the architectural differences change outcomes.

Date executed: 2026-08-05

What S2 Is Trying to Settle#

S1 established four tiers, a perception fork, and an unusually unreliable information environment. S2 resolves five things:

1. Is tier 3 a real substitute for tier 2? The adoption numbers suggest the market thinks so. This is the decision most readers should be making and no published comparison frames it.
2. What do the benchmark numbers mean? Answered in benchmarks.md — the short version is that no two headline figures in this category are comparable.
3. Does hybrid escape selector rot, or defer it? Stagehand’s whole argument depends on this.
4. What does perception actually cost? DOM versus vision, per step.
5. How exposed is this to prompt injection? Answered in security.md — documented in production, unsolved, category-wide.

The Shared Architecture#

Every tier-2 and tier-3 option implements the same loop. Differences are in how each stage is realized, not in the shape.

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   ▼                                                 │
 OBSERVE ──────► DECIDE ──────► ACT ─────────────────┘
 page state      next action    click / type /
 as text or      from an LLM    navigate / scroll
 pixels

Observe is where DOM and vision diverge, and it drives both cost and capability.

Decide is an LLM call, always. This is the category’s dominant operating expense and its source of non-determinism.

Act is delegated to a tier-1 driver — nearly always Playwright or the Chrome DevTools Protocol. No option in this survey reimplements browser control. They all sit on the same foundation covered in 1.118, which is why tier 1 is out of scope here.

The economically important consequence: cost and latency scale with the number of loop iterations. Anything that reduces iterations — deterministic steps, better perception, a stronger model making fewer wrong turns — reduces cost proportionally. That single fact explains most of the architectural variation in tier 2.

Method#

Primary sources for architectural claims — repositories, official documentation. Secondary sources are used only for the DOM-vs-vision comparative measurement, and are labelled as such.

Benchmark figures are reported with the benchmark named and its design described. Given S1’s findings, no figure is quoted without its benchmark.

Vendor-published comparisons are identified inline wherever cited.

Code samples are kept to API signatures illustrating a structural point, per methodology.

The Cross-Cutting Question: Is Tier 3 a Substitute for Tier 2?#

Framed before the individual analyses because it reframes everything else.

The adoption data is striking. Chrome DevTools MCP has 48.6k stars against Stagehand’s 23.7k and Skyvern’s 22.7k — more than either tier-2 competitor to browser-use, despite not being an agent at all.

The substitution logic: if you already run an MCP-capable harness, a browser MCP server gives that harness browser control. You get the capability without adopting a second agent framework with its own loop, its own prompts, and its own operational surface.

Where the substitution holds: interactive and semi-interactive work. A developer asking their coding agent to check whether a page renders correctly, a researcher having an assistant look something up, anything where a human is in the loop and the harness already exists.

Where it breaks down: unattended production automation. Tier 3 gives you tools, not a program. Something must decide what to do with them, handle failure, retry, and run on a schedule. A general harness driving generic tools is not optimized for a thousand-executions-a-day workflow, and building that orchestration yourself is substantially the work tier 2 already did.

The honest framing this yields, developed across the individual analyses: tier 3 substitutes for tier 2 in interactive use and complements it in production. The 48.6k stars are real and they largely represent the interactive population — developers giving their existing assistant browser access — rather than production automation migrating away from frameworks.

That is still a significant finding, because the interactive population is much larger than the production one, and it is not who tier 2’s marketing addresses.

Files in This Stage#

• benchmarks.md — what Odysseys, WebBench, and WebVoyager measure, and why no cross-benchmark comparison is valid
• security.md — indirect prompt injection: documented in production, unsolved, category-wide
• agent-browser-use.md — the agent-first loop and its economics
• agent-stagehand.md — the hybrid model and whether self-healing escapes selector rot
• agent-skyvern.md — vision perception, its cost premium, and the AGPL boundary
• mcp-servers.md — tool-surface delivery; what 61 tools buys
• hosted-runtimes.md — the compounding cost model
• feature-comparison.md — the matrix and its limits
• recommendation.md — technical verdict

What the Benchmark Numbers Actually Measure#

Verified: 2026-08-05

This file exists because S1 found that the figures circulating for this category are attached to the wrong benchmark names, and because the three benchmarks in play measure such different things that no cross-benchmark comparison in this category is valid.

A reader will encounter these numbers everywhere. This is what they mean.

The Three Benchmarks#

WebVoyager#

The original and most-cited web-agent benchmark. Tests DOM reasoning, form filling, and multi-step navigation within a single popular site.

What it doesn’t test: cross-site workflows, long-horizon reasoning, authentication, anti-bot infrastructure, or the long tail of the web. Fifteen well-known, well-structured sites is a friendly environment.

This is the benchmark most secondary sources cite — and neither browser-use nor Skyvern claims a WebVoyager score in their primary materials.

WebBench#

Nearly nine times WebVoyager’s task count across thirty times as many sites, and the only benchmark of the three that measures the infrastructure as well as the agent — whether you can get past Cloudflare and CAPTCHA at all.

The READ/WRITE split is the important design decision. READ tasks are information retrieval. WRITE tasks — logging in, completing forms, downloading files — are where commercial value concentrates and where failure has consequences. Separating them is more informative than a single blended score.

Published by Skyvern. This must be stated: WebBench is a Skyvern-created benchmark, and Skyvern reports its own 64.4% on it. That does not make the benchmark bad — its design is more rigorous than WebVoyager’s on every axis — but a vendor’s score on a vendor’s benchmark is not independent evidence.

Odysseys#

The hardest benchmark on the axis it measures, and the most methodologically interesting.

Rubric grading rather than pass/fail is the key difference. A long-horizon task is rarely wholly succeeded or wholly failed — an agent may complete four of six sub-goals. Binary scoring discards that; rubrics capture it. It also means Odysseys scores are not success rates in the way WebVoyager’s are, which alone makes cross-benchmark comparison invalid.

Live-internet evaluation means the environment changes between runs. More realistic than a frozen snapshot, less reproducible.

Why the Circulating Comparisons Are Meaningless#

The comparison a reader will encounter, in some form, across many articles:

browser-use scores 89.1%, Skyvern scores 85.85% — both on WebVoyager.

Neither figure appears in either project’s primary materials. What the primary sources actually claim:

Setting 87.4% beside 64.4% and concluding browser-use is ~23 points better is wrong in at least four independent ways:

1. Different task counts — 200 vs 5,750.
2. Different site breadth — a handful of deep tasks vs 452 sites including the hostile long tail.
3. Different scoring — rubric partial credit vs task completion.
4. Different subject — WebBench scores the infrastructure’s ability to get past Cloudflare and CAPTCHA alongside the agent’s reasoning. A low WebBench score may reflect blocked page loads rather than bad decisions.

A rubric-graded score on 200 curated long-horizon tasks and a blended score across 5,750 tasks on 452 sites including anti-bot challenges are not the same kind of quantity. They cannot be subtracted.

What Can Honestly Be Said#

About browser-use: strong on long-horizon, cross-site reasoning, measured by rubric on live sites. That is a genuinely hard problem and 87.4% is a genuinely strong result.

About Skyvern: claims best-in-class on WRITE tasks — forms, logins, downloads — which is consistent with its vision-first architecture and is the commercially valuable half of browser automation. Its 64.4% overall is on a far broader and more hostile task set than either alternative benchmark, and on a benchmark it authored.

About Stagehand: no comparable published benchmark figure was found in primary sources. Its argument is economic (deterministic steps cost nothing) rather than accuracy-based, which is a coherent position that benchmarks of this kind don’t measure.

Across the category: the DOM-vs-vision finding — DOM-driven stacks 12–17 points ahead on common tasks — is the most useful published comparison, because it holds the task set fixed and varies the approach. That is what a comparison needs to do.

The Structural Problem#

There is no neutral, independent, cross-tool benchmark for this category.

WebVoyager is the closest to neutral and is the oldest and least representative of real workloads. WebBench is the most rigorous in design and is published by a competitor. Odysseys measures a dimension the others don’t and only some tools report it.

Each vendor reports the benchmark that flatters its architecture — which is not dishonest, since each architecture genuinely is better at what its preferred benchmark measures. But the aggregate effect is that no two headline numbers in this category are comparable, and secondary sources have compounded the problem by relabelling them.

Practical guidance: benchmark scores in this category should inform what a tool is shaped for, never which tool is better. Read the benchmark’s design, not its number. If your workload is long-horizon cross-site research, Odysseys is the relevant signal. If it is filling forms on obscure sites behind Cloudflare, WebBench is — and its infrastructure component is measuring something you genuinely need.

And test on your own sites. In a category where every published number is measured on a different corpus by an interested party, a small evaluation on the sites you actually target is worth more than every benchmark in this file.

Feature Comparison#

Verified: 2026-08-05

How to read this: the options here mostly occupy different tiers and stack rather than substitute, so a single matrix is more misleading in this category than in most. Matrices are given per tier, with cross-tier comparison handled in prose. The individual S2 files are the analysis; this is the index.

Tier 2 — Agent Frameworks#

⚠️ The benchmark row is not comparable. Different benchmarks, different task counts (200 vs 5,750), different site breadth (deep vs 452 sites), different scoring (rubric vs task completion), and WebBench additionally scores infrastructure. See benchmarks.md.

Tier 3 — MCP Servers#

The framing that makes this table make sense: Playwright MCP is for driving the browser; Chrome DevTools MCP is for debugging it. They are complementary, and the common guidance is to install both.

Tier 4 — Hosted Runtimes#

Cross-Tier: What Each Tier Costs You#

The Rows That Aren’t in Any Matrix#

The things that actually decide adoptions here, none of which is a feature:

1. Whether you already run an agent harness. If yes, tier 3 may be the whole answer and tier 2 is machinery you don’t need. This single question reorders the entire evaluation and appears in no published comparison.

2. Whether AGPL is permitted. Binary, usually enforced by automated dependency scanning rather than judgment, and it ends the Skyvern evaluation before merit is considered.

3. Whether you know your target sites in advance. Decides whether Stagehand’s hybrid saving is real or theoretical. Known sites → large saving. Unknown long tail → the deterministic fraction approaches zero and you’re running an agent with extra ceremony.

4. Whether an API exists. If yes, this entire category is the wrong answer. The most valuable question in the survey and the one nobody selling anything will ask you.

5. Whether the task is read or write. Read-only work is often better served by extraction tools (long-tail.md) — cheaper, faster, more reliable. Browser agents earn their cost on write workloads: logins, forms, transactions.

6. What happens when it gets it wrong. Non-determinism plus 60–90% task success means failure is a routine operating condition, not an edge case. Workflows with no tolerance for a wrong action need a human in the loop regardless of tool.

Cost Structure Across Tiers#

Not a feature comparison — the thing most likely to surprise after adoption.

The compounding effect: agent latency is billed twice — once as inference, once as browser-time. Deterministic steps avoid both. This is the strongest quantitative argument for hybrid architectures and it spans two vendors, so neither surfaces it.

Legend#

✅ supported · ❌ not available · ⚠️ partial or with caveats

Tier 4 — Hosted Runtimes, Technical Deep-Dive#

Verified: 2026-08-05

What This Tier Actually Solves#

Three problems, in ascending order of how hard they are to solve yourself.

1. Concurrency. A browser instance consumes hundreds of megabytes and real CPU. Meaningful concurrency means a fleet with autoscaling, health checks, and crash recovery for processes that crash more than most. Difficulty: moderate. Any competent platform team can run containers with Chrome in them.

2. Session persistence. Cookies and auth surviving across steps and runs, on an ephemeral fleet. Difficulty: moderate. Fiddly, well-understood.

3. Network identity. Getting the page to load at all — past bot detection, datacenter IP blocks, headless fingerprinting, and CAPTCHAs. Difficulty: high, and permanently so. This is adversarial, constantly changing, and requires ongoing work against opponents who are actively improving.

Essentially all the durable third-party value is in problem 3. Problems 1 and 2 are engineering you could do. Problem 3 is a treadmill you’d have to run forever.

That concentration is the tier’s commercial foundation and its strategic weakness — S4 takes up the latter.

The Compounding Cost Model#

S1 flagged this as the category’s least obvious expense. The mechanism:

Runtimes bill by wall-clock browser-hour. Steel publishes ~$0.05–$0.10/hour.

Agent workflows are slow because every step is an LLM call. A step takes seconds — the model reads the page, reasons, responds.

The browser is billing during all of it. It sits open, consuming a paid hour, while the model thinks.

  agent step:  [ observe ][ ── model thinks ── ][ act ]
  browser:     [ ══════════ billing throughout ══════ ]
                            ↑
                    most of the elapsed time,
                    zero browser work happening

The consequence: the same task costs more in browser-hours when run by a slow agent-first framework than by a fast hybrid one — on top of costing more in inference. The two expenses move together rather than trading off.

Worked intuition: a task taking 20 agent steps at ~5 seconds of model latency each occupies the browser for roughly two minutes doing nothing. At $0.10/hour that is fractions of a cent per run — negligible at low volume, and meaningful at ten thousand runs a day, where it is essentially a tax on model latency.

Why this matters for tool selection: it is an argument for Stagehand’s deterministic steps that neither Stagehand nor the runtimes make. Deterministic steps execute in milliseconds. Every step you don’t delegate is browser-time you don’t buy and inference you don’t pay for. The hybrid saving is roughly double what the framework comparison alone suggests.

Neither vendor’s pricing page surfaces this, because it spans two vendors.

Browserbase#

The two-tier strategy is the architecturally interesting fact. Browserbase gives away an excellent tier-2 framework and sells the tier-4 runtime it integrates with most naturally.

This is well-executed and worth reading clearly:

• Stagehand is genuinely MIT, genuinely good, and runs fine against a local browser. It is not crippled.
• The integration with Browserbase is smoothest, and the moment a team needs scale or network identity, the path is already paved.
• Adoption of the free framework generates qualified demand for the paid runtime.

Structurally this is the open-core pattern documented in 1.215 — free data path, paid control plane — executed across tiers rather than within one product. Arguably a cleaner version, since the free component is entirely usable standalone and there is no license boundary to dispute.

Capabilities beyond hosting: managed sessions, session replay for debugging, state persistence. Session replay is the genuinely differentiated one — debugging a non-deterministic agent that failed on run 4,712 is close to impossible without a recording, and this is the category’s answer to the observability problem that S3’s personas keep running into.

Steel.dev#

Self-hosting is the category-defining differentiator, and its importance is constraint-driven rather than preference-driven.

Browser sessions carry authenticated access to whatever the agent logs into. For a team automating against internal systems or handling regulated data, routing those sessions through a third party is frequently prohibited outright. Steel is the only option in this tier for those buyers — not the best option, the only one.

The pricing is unusually legible, which makes build-vs-buy tractable: ~$0.05–$0.10 per browser-hour compares directly against a container running Chrome, plus the proxy and fingerprinting work you would inherit. For most teams the arithmetic favours buying until volume is substantial, because problem 3 is the expensive part and it doesn’t appear in a container cost estimate.

The free tier is substantial — 100 hours/month supports real development and low-volume production rather than a trial.

The self-hosting caveat that matters: self-hosted Steel gives you problems 1 and 2. It does not give you the residential proxy pools and fingerprint management that solve problem 3. Teams self-hosting for compliance reasons are typically automating internal systems that don’t have bot detection — which is exactly the case where that gap is irrelevant. The alignment is fortunate rather than designed.

When This Tier Is Unnecessary#

Worth stating technically, because it is the most common correct answer.

Playwright launches a browser. Locally, in CI, in a container you already run. For development, low-volume production, and anything on infrastructure you have, tier 4 adds cost and a dependency for no benefit.

The tier becomes necessary at exactly two thresholds:

1. Concurrency exceeding what your infrastructure comfortably runs — genuinely parallel workloads, not a task running every few minutes.
2. Target sites actively blocking you — the point where problem 3 becomes yours.

Below both, this tier is infrastructure for a workload you don’t have.

Failure Modes#

Runtime outage stops everything. No local fallback unless deliberately built. Standard hot-path dependency risk.

Cost surprise from long-running sessions. A stuck agent holds a browser open, billing. The agent-side step limit is also the runtime-side cost control — the two are the same lever, which is not obvious.

Session state on third-party infrastructure. Credentials the browser holds are handled by the provider. Unavoidable with Browserbase; Steel’s self-hosted path is the answer.

Anti-bot arms race regressions. A detection improvement on the target side can break working automation with no change on your side. Providers respond, but there is a window, and it is outside your control.

S2 Assessment#

The tier’s durable value is concentrated in network identity — the adversarial problem. Concurrency and session management are engineering you could do; problem 3 is a permanent treadmill.

The compounding cost model is the tier’s least obvious property: agent latency is billed as browser-time, so slow frameworks cost more here and in inference. It is an unmarketed argument for hybrid architectures.

Browserbase’s two-tier strategy is the cleanest open-core execution in either this survey or 1.215 — the free component is fully usable standalone and there is no license boundary to dispute.

Steel’s self-hosting is a constraint-satisfier, not a preference. For buyers who cannot route sessions through third parties it is the only option, and its gap on problem 3 happens to align with those buyers’ typically-internal targets.

Most readers need neither, yet.

Tier 3 — Browser MCP Servers, Technical Deep-Dive#

Verified: 2026-08-05

Architectural Overview#

Tier 3 inverts the tier-2 relationship. The agent loop lives in a harness you already run; the server provides only the browser capability, exposed as MCP tools.

  ┌─────────────────────────────────────────┐
  │  YOUR HARNESS (coding agent, assistant, │
  │  custom orchestration) — owns the loop  │
  └──────────────┬──────────────────────────┘
                 │  MCP protocol (2.074)
                 ▼
  ┌─────────────────────────────────────────┐
  │  MCP SERVER — tool surface only         │
  │   navigate · click · type · screenshot  │
  │   inspect · trace · audit               │
  └──────────────┬──────────────────────────┘
                 ▼
            real browser

What moves and what doesn’t: OBSERVE and ACT are provided by the server. DECIDE stays in your harness. The server has no opinion about what should happen next — it answers questions and performs actions.

The consequence that matters: outcome quality is a function of the harness, not the server. The same server produces excellent results driven by a capable agent and poor ones driven by a weak one. This makes tier-3 evaluation genuinely harder than tier-2 evaluation — you cannot assess the server independently of what drives it.

Chrome DevTools MCP — What 61 Tools Buys#

48.6k stars, Apache-2.0, maintained by Google’s Chrome DevTools team, Chrome and Chrome for Testing only.

The tool surface is the product, and its composition reveals the intent:

This is not a browser automation surface. It is the Chrome DevTools Protocol exposed to an agent.

That distinction is the whole point. No tier-2 framework can profile a page’s runtime performance, run a Lighthouse audit, inspect why a network request failed, or analyze a memory leak. Those aren’t automation capabilities — they’re developer capabilities, and they explain the adoption gap.

Why 48.6k stars makes sense in that light: the addressable population isn’t “teams building browser automation,” it’s “developers with a coding agent who want it to see the browser.” That is an enormously larger group, and it is the population 1.212 documents as growing fast.

Source-mapped stack traces deserve specific note — it means an agent debugging a production issue gets traces mapped back to original source rather than minified bundles. That is the difference between an agent that can meaningfully help debug and one that reads gibberish.

The Chrome-only constraint is firm: officially Chrome and Chrome for Testing, other Chromium browsers unsupported, latest Extended Stable Chrome committed. No Firefox, no WebKit — disqualifying for cross-browser work, irrelevant for debugging your own app.

Playwright MCP — Accessibility-Tree Determinism#

~7.3k stars, Apache-2.0, Microsoft, cross-browser.

The distinctive design decision is the perception model: neither raw DOM nor screenshots, but the accessibility tree — the same representation screen readers consume.

Why this is a genuinely good idea:

• Semantically meaningful. Elements carry roles and labels (“button, Submit”) rather than arbitrary class names. The model reasons about what things are rather than how they’re marked up.
• More stable than the DOM. A redesign that restructures markup usually preserves accessible roles, because those are what make the site usable at all.
• Compact. Smaller than raw DOM, far cheaper than screenshots.
• Exact targeting. Like DOM approaches, no coordinate estimation — the localization problem that costs vision approaches accuracy simply doesn’t exist.

The dependency: sites with poor accessibility markup yield a poor tree. A <div> soup with click handlers and no ARIA is nearly as opaque here as to a screen reader. There is a pleasing irony that agents work best on accessible sites, and a real limitation that many sites aren’t.

Cross-browser support is the concrete differentiator and the only reason to choose this over Chrome DevTools MCP for pure automation.

On the star gap: 7.3k vs 48.6k does not indicate quality. It indicates addressable population. Cross-browser automation is a specialist need; agent-assisted Chrome debugging is close to universal among web developers.

The Substitution Question, Resolved#

approach.md framed this; here is the technical answer.

What tier 3 gives you that tier 2 doesn’t:

• No second agent loop to operate, prompt, or debug
• Protocol portability — works with any MCP client, not one framework’s abstractions
• First-party vendor backing (Microsoft, Google) rather than startup maintenance
• Debugging depth on Chrome that no framework offers
• Permissive Apache-2.0 on both

What tier 2 gives you that tier 3 doesn’t:

• A program. Tier 3 is a capability; something must still orchestrate it, handle failure, retry, and run on a schedule. That orchestration is substantially what tier 2 already built.
• Task-level abstractions. extract({schema}) and “accomplish this goal” are higher than raw tool calls, and the gap is real engineering.
• Loop optimization. A purpose-built framework tunes observe-decide-act; a general harness calling generic tools makes more round trips for the same outcome.
• Unattended operation. Harnesses are built for interactive use. Running one unattended a thousand times a day is not what they’re shaped for.

The resolution: tier 3 substitutes for tier 2 in interactive work and complements it in production.

The 48.6k stars are real and mostly represent the interactive population — developers giving an existing assistant browser access. That population dwarfs the production- automation population, which is why the adoption numbers look like a tier-2 disruption and mostly aren’t one.

But it is still a significant finding, because tier 2’s marketing addresses the production case while a large share of people evaluating tier 2 actually have the interactive need — and would be better served by tier 3 with far less machinery.

Security, Amplified#

Covered fully in security.md; the tier-3-specific amplifier restated because it is serious.

The harness driving a browser MCP server is typically a general-purpose agent with other tools — filesystem, shell, code execution. An indirect prompt injection that hijacks a browsing step is not confined to the browser; it reaches whatever else that harness can do.

Chrome DevTools MCP’s own documentation states the server exposes browser content to MCP clients, allowing inspection and modification of any data in the browser or DevTools. That is accurate and appropriately stark. An agent with this access holds whatever the browser holds.

Tier 2’s blast radius is the browser. Tier 3’s is the harness. That is a meaningful difference and it argues for dedicated browser profiles and scoped credentials more strongly here than anywhere else in the survey.

Deployment#

Both install as MCP servers into a client’s configuration. No infrastructure, no service tier, no database — the lightest deployment in the survey by a wide margin.

The practical guidance recurring across independent write-ups: install both in lean modes and let the agent choose, since it costs little and being wrong costs more. They are complementary rather than competitive.

S2 Assessment#

Chrome DevTools MCP is a developer-tools product that happens to enable automation, and its adoption reflects that. 61 tools spanning profiling, auditing, and memory analysis serve a population far larger than browser-automation teams.

Playwright MCP’s accessibility-tree approach is the most elegant perception model in the survey — semantic, stable, compact, exactly targetable — and its adoption is limited by addressable population rather than quality.

The substitution is real but narrower than the star counts suggest: interactive yes, unattended production no.

Tier 3 carries the survey’s largest security blast radius, because the harness it extends usually holds more than a browser.

S2 Recommendation — Technical Verdict#

Date: 2026-08-05

What S2 Settled#

S1 left five questions. All five resolved, and two changed the picture materially.

1. Is tier 3 a substitute for tier 2? — Partly, and along a clean line#

Tier 3 substitutes for tier 2 in interactive work and complements it in production.

Tier 3 gives you a capability, not a program. Something must still orchestrate it, handle failure, retry, and run on a schedule — which is substantially what tier 2 already built. Harnesses are shaped for interactive use, not for running unattended a thousand times a day.

But the interactive population is far larger than the production one, which explains Chrome DevTools MCP’s 48.6k stars without them representing a tier-2 exodus.

The finding that matters for readers: tier 2’s marketing addresses the production case, while a large share of people evaluating tier 2 actually have the interactive need — and would be better served by tier 3 with far less machinery. Evaluate tier 3 first. No published comparison frames the decision this way.

2. What do the benchmark numbers mean? — Nothing comparable#

Three benchmarks measuring genuinely different things:

• WebVoyager: 643 tasks, 15 friendly sites, short single-site. The one everyone cites and neither browser-use nor Skyvern actually claims.
• WebBench: 5,750 tasks, 452 sites, READ/WRITE split, scores infrastructure too (Cloudflare, CAPTCHAs). Published by Skyvern.
• Odysseys: 200 long-horizon live-internet tasks, rubric-graded (6.1 rubrics/task), cross-site.

Setting browser-use’s 87.4% (Odysseys) beside Skyvern’s 64.4% (WebBench) is invalid four ways over: different task counts, different site breadth, different scoring semantics, and WebBench partly measures whether the page loaded at all rather than whether the agent reasoned well.

Benchmark scores here indicate what a tool is shaped for, never which tool is better. Test on your own sites.

3. Does hybrid escape selector rot? — Exactly proportionally#

Stagehand’s self-healing cache replays resolved actions at script speed and re-resolves via the model when the DOM shifts. Genuinely elegant.

But rot is escaped only for AI-resolved steps and fully retained for hand-written ones — in exact proportion to the cost saving. Every deterministic step is cheaper and more brittle; every act() step costs more and self-heals. Stagehand exposes the dial rather than resolving the tension, which is a better design than either extreme and is not a free lunch.

Practical rule: deterministic code for structural navigation that rarely changes; act() for what actually varies. Using a deep selector to save one model call buys back precisely the fragility you adopted the tool to escape.

4. What does vision cost? — More per step, and it compounds#

Image tokens run roughly an order of magnitude above a filtered element list, every step pays it, and resolution is a direct cost-accuracy dial with no cheap-and-precise setting.

The compounding problem: vision costs more per step and localizes less precisely, so misclicks add retries that pay the premium again.

The mechanical source of the 12–17 point DOM advantage is not reasoning quality — it is that DOM approaches skip an entire error-prone stage. An element reference is exact; a coordinate estimate is not. Vision’s genuine case is pages where no element reference exists: canvas, images of text, purely visual state.

5. How exposed is this to prompt injection? — Fully, and it is unsolved#

Documented in production (Unit 42, December 2025), rising (Google: +32% relative, Nov 2025–Feb 2026), and treated by security researchers as fundamental rather than a bug awaiting a patch.

No tool choice mitigates it. Every option is exposed, because the exposure is a direct consequence of the capability being valuable: an authenticated browser, a model that acts on text it reads, and untrusted input from arbitrary sites.

Tier 3 carries the largest blast radius — the harness it extends usually holds filesystem and shell tools too, so a hijacked browsing step can reach far beyond the browser.

Three Findings That Emerged in S2#

Deterministic steps are injection-proof, and nobody markets this. Text on a page cannot influence page.click('#submit'). So Stagehand’s cost dial is simultaneously an attack-surface dial: a 90% deterministic workflow has 10% of the injection exposure. This is a real architectural security advantage that appears in no vendor material.

Agent latency is billed twice. Runtimes charge by wall-clock browser-hour; agent steps are slow because every one is a model call; the browser bills while the model thinks. So a slow framework costs more in inference and more in browser-hours. The two compound rather than trade off — and because the effect spans two vendors, neither pricing page shows it. The hybrid saving is roughly double what a framework-only comparison suggests.

Browserbase’s two-tier strategy is the cleanest open-core execution across both this survey and 1.215. Free MIT framework (Stagehand) at tier 2, paid runtime at tier 4. The free component is fully usable standalone against a local browser, and there is no license boundary to dispute — structurally sounder than gating features within one product.

Technical Standing#

Carried to S3#

The technical picture supports personas differing on constraints and context, not feature preference:

1. Do you already run an agent harness? Reorders the whole evaluation; decides whether tier 2 is needed at all.
2. Do you know your target sites? Decides whether hybrid’s saving is real.
3. Is AGPL permitted? Binary; gates Skyvern before merit.
4. Read or write workload? Read-only is often better served outside this category.
5. Attended or unattended? Decides tier 3 vs tier 2, and sets the security posture.
6. Does an API exist? If yes, none of this applies.

S3 builds personas around these.

The Security Surface#

Verified: 2026-08-05

S1 flagged this as the aspect of the category most likely to produce a serious incident and the one least discussed in vendor material. It warrants its own file because the threat is no longer hypothetical, and because it is a category-wide property that no tool choice mitigates.

The Structural Problem#

An agentic browser tool combines three things that are individually manageable and collectively dangerous:

1. An authenticated browser session. The agent operates as you. It has your cookies, your logins, your permissions. That is the entire point — an agent that can’t log in can’t do useful work.
2. A language model that acts on text it reads. The model’s instructions and the page’s content arrive in the same context. There is no architectural separation between “what my user asked” and “what this webpage says.”
3. Untrusted input from arbitrary websites. The agent visits pages controlled by people who are not you.

Put together: text on a webpage can issue instructions to a model that holds your credentials. That is indirect prompt injection, and it is the defining security problem of this category.

It Is Happening in the Wild#

This moved from theoretical to documented during 2025–2026:

• Palo Alto Networks Unit 42 documented the first real-world instance of malicious indirect prompt injection in December 2025, confirming production occurrence rather than lab demonstration.
• Google observed a 32% relative increase in the malicious category between November 2025 and February 2026.
• Independent research and security vendors — including Brave’s published analysis — treat indirect prompt injection as a fundamental, unsolved challenge rather than a bug class awaiting a patch.

Documented attack pattern: hidden instructions on a page hijack the agent mid-task, redirect it to an attacker-controlled form, silently fill that form with conversation history or session data, and submit it. The user sees a task that appeared to complete.

Why Agents Are Worse Than Chatbots Here#

A chatbot with web search reads untrusted content and produces text. The blast radius is a wrong answer.

An agentic browser tool reads untrusted content and takes actions with your credentials. Published analysis identifies the specific amplifiers:

• Autonomous multi-source retrieval — it visits pages nobody reviewed
• Chained tool calls — one compromised step poisons everything downstream
• Reduced user oversight — the value proposition is not watching every step
• Persistent session state — a compromise can outlive the page that caused it

The last point deserves emphasis. Research on context-manipulation attacks shows web agents are susceptible to corrupted memory — an injection can persist in the agent’s context beyond the malicious page, influencing later, otherwise-legitimate steps.

Where Each Tier Sits#

Tier 2 (agent frameworks) — full exposure. The framework’s loop is what reads page content and decides actions. Mitigation quality varies by implementation and none of the three primary options claims to solve it.

Tier 3 (MCP servers) — full exposure, plus an amplifier. The harness driving the server is typically a general-purpose agent with other tools — filesystem, shell, code execution. An injection that hijacks a browsing step in a coding agent can potentially reach capabilities far beyond the browser.

Chrome DevTools MCP states this in its own documentation: the server exposes browser content to MCP clients, allowing them to inspect, debug, and modify any data in the browser or DevTools. That is an accurate and appropriately alarming description. An agent with this access holds whatever the browser holds.

Tier 4 (hosted runtimes) — the runtime doesn’t cause this and doesn’t prevent it. It does add a consideration: sessions with real credentials are held on third-party infrastructure. Steel’s self-hosted path is the mitigation for buyers where that matters.

What Actually Helps#

No option in this survey solves indirect prompt injection, because it is not currently solvable at the tool layer. What follows reduces blast radius rather than preventing compromise.

Credential isolation — the highest-value control. Give the agent a dedicated account with the minimum access the task requires. Never the browser profile holding your real sessions. An agent that can only reach one supplier portal can only damage that.

Separate browser profiles. A dedicated profile per task class, never the personal one. Trivially cheap and eliminates the worst outcomes.

Domain allowlisting. Restrict navigation to expected domains. This directly defeats the documented pattern of redirecting to attacker-controlled forms.

Human confirmation on consequential actions. Purchases, submissions, deletions, anything sending data outward. This reintroduces the oversight the value proposition removes — which is the honest trade, and it is why fully autonomous agents against untrusted sites remain a bad idea regardless of tool.

Treat page content as hostile input, always. The same posture as user-supplied data in any application. Never let it be interpreted as instruction where you can avoid it.

Egress monitoring. Log where the agent navigates and what it submits. The documented attacks involve exfiltration to attacker-controlled endpoints, which is detectable if anyone is looking.

Prefer hybrid where the flow is known. Stagehand’s deterministic steps are not model-mediated and cannot be injected. Every step you express as code rather than delegation is a step that cannot be hijacked. This is an under-appreciated security argument for the hybrid architecture and it is not one Stagehand markets.

What This Means for the Category#

This is a category-level risk with no tool-level solution. A reader cannot choose their way out of it. Every option is exposed, and the exposure is a direct consequence of the capability being valuable.

The practical consequence is a constraint on where this technology belongs:

Reasonable: agents operating against sites you control or trust, with scoped credentials, under supervision, on tasks whose worst-case failure is acceptable.

Not reasonable, currently: fully autonomous agents with real credentials operating against arbitrary untrusted sites without oversight — which is, unfortunately, close to the demo that sells the category.

Vendors do not say this. The research literature is unambiguous, the attacks are documented in production, and the trend is upward. Any adoption plan for this category that does not include a credential-isolation and blast-radius answer is incomplete, and this survey treats that as a gating requirement rather than a recommendation.

Carried to S4#

Whether this is a transient problem or a permanent property of the architecture is the category’s central strategic question. Current research consensus leans toward fundamental — the model cannot reliably distinguish instructions from data when both arrive as text, and no proposed mitigation has closed it.

If that holds, it caps how autonomous these systems can responsibly become, which in turn caps the category’s addressable use cases well below what the marketing implies.

S3 Need-Driven Discovery — Approach#

Stage goal: WHO needs this and WHY. Personas and constraints, not implementation.

Date executed: 2026-08-05

How These Personas Were Constructed#

S2 established that this category’s options mostly occupy different tiers and stack rather than substitute, so “which tool” is a worse-formed question here than in most surveys. The better question is “which tiers do I need at all” — and that is decided by context, not preference.

Six constraints do the work:

1. Do you already run an agent harness? Reorders everything. If yes, tier 3 may be the entire answer.
2. Attended or unattended? Interactive work suits tier 3; unattended production needs tier 2’s orchestration.
3. Do you know your target sites in advance? Decides whether Stagehand’s hybrid saving is real or theoretical.
4. Read or write workload? Read-only is frequently better served outside this category.
5. Is AGPL permitted? Binary; gates Skyvern before merit is considered.
6. Does an API exist? If yes, none of this applies.

Each persona below is a distinct combination. They are not company sizes — two teams in one company routinely belong to different personas, and the developer persona coexists with the operations persona inside the same building.

Two personas are included deliberately that most surveys would omit: the reader who needs nothing from this category, and the reader whose real need is extraction rather than agency. Both are large populations that vendor material never addresses.

What These Personas Are Not#

Per RAIL 0, these serve any reader in this domain. None is derived from a particular requester’s scenario, and no persona’s needs feed back into S1/S2 verdicts or the survey’s scope and recommendation metadata.

Personas#

Output#

use-case-*.md per persona, plus recommendation.md mapping personas to tiers and tools.

S3 Recommendation — Who Should Use What#

Date: 2026-08-05

The Persona → Tier Map#

Every option is the best answer for someone and the wrong answer for someone else. There is no category winner, and the tiers stack rather than compete.

What Actually Decides It#

The six constraints, in the order they eliminate options:

1. Does an API exist? If yes, this whole category is the wrong answer. One hour to check, routinely skipped, and it can save a project. The most valuable question in the survey and the one nobody selling anything will ask.

2. Do you already run an agent harness? This reorders everything. If yes and the work is interactive, tier 3 is likely the entire answer and tier 2 is machinery you don’t need. This is the survey’s most common mis-adoption: developers adopting a standalone Python agent framework to solve a problem their existing harness solves with a config entry.

3. Attended or unattended? Tier 3 substitutes for tier 2 in interactive work and complements it in production. Harnesses aren’t shaped for running unattended a thousand times a day.

4. Do you know your target sites? The cleanest split in the survey. Known → Stagehand’s deterministic fraction is high and the hybrid saving is real. Unknown → that fraction is zero and agent-first is the only thing that scales. Personas 2 and 3 are the same technology in opposite regimes.

5. Read or write? Read-only is often better served by a crawler — cheaper, faster, deterministic. Browser agents earn their cost on write: logins, forms, transactions.

6. Is AGPL permitted? Binary, usually enforced by automated dependency scanning rather than judgment, and it ends the Skyvern evaluation before merit is considered.

Four Patterns Across Personas#

The largest population isn’t who the category markets to. Chrome DevTools MCP’s 48.6k stars — ahead of Stagehand and Skyvern combined, and not an agent — is best explained by persona 1. Every published comparison asks “which browser agent framework?” For the biggest audience the answer is none, and the action is a config entry.

Stagehand’s cost dial is also a security dial and a compliance dial. Deterministic steps cannot be prompt-injected, and their page content is never transmitted to a model provider. For persona 2 that is attack-surface reduction; for persona 4 it is a data-flow control that may decide whether the project is permitted at all. Neither Stagehand nor anyone else markets this, and it is the most under-recognized finding across S2 and S3.

Where the page content goes is the question nobody asks. Every observe step transmits what’s on screen to a model provider. For persona 4 that content is regulated data. No vendor material in this category discusses it. This makes 1.215’s proxy layer near-mandatory for sensitive workloads, and pairs it with 1.209 where policy demands fully-local inference.

Non-determinism is disqualifying in exactly one place. Persona 5’s regression suite. A test’s value is its determinism; an agentic test cannot do a test’s job. Agents should help author and diagnose deterministic tests, never replace them.

The Composition Patterns#

Persona 2 — known portals plus a tail:

  Stagehand      → the 12 known portals (deterministic + act())
  browser-use    → the long tail nobody ever automated
  local browsers → no tier 4 needed at this scale

Persona 3 — breadth at volume:

  browser-use    → agent-first across unknown sites
  Browserbase /  → concurrency + network identity (genuinely required here)
    Steel Cloud
  LLM router     → 1.215; cheap models for navigation, capable for hard calls
    (1.215)         at this volume, a material cost lever

Persona 4 — regulated, internal:

  Stagehand           → maximize deterministic steps (cost, security, AND data flow)
  self-hosted Steel   → only if concurrency demands it; often unnecessary
  self-hosted proxy   → 1.215, so page content never leaves the perimeter
  self-hosted models  → 1.209, where policy requires fully-local inference

What Carries to S4#

S3 answered who fits what today. The personas raise durability questions S4 must address:

1. Persona 1 depends on tier 3 staying first-party and free. Both servers are vendor-funded developer tooling. What happens if that changes?
2. Persona 2 and 4 are betting on Stagehand, which is published by a company whose revenue comes from a tier they may never buy. Is that sustainable?
3. Persona 3’s activity is adversarial by nature. The anti-bot arms race is a permanent treadmill with legal exposure. Where does that end?
4. Everyone is exposed to prompt injection, which research treats as fundamental rather than fixable. Does that cap how far this category can go?
5. Computer-use models threaten the framework layer. If models get natively good at operating browsers, what is tier 2 for?

That last one is the category’s central strategic uncertainty, and S4 takes it up directly.

Persona 1: The Developer With a Coding Agent#

Who They Are#

A working software developer who already uses an AI coding agent daily — one of the harnesses surveyed in 1.212. They write and debug web applications. The agent already reads their code, runs their tests, and edits files.

What it cannot do is look at the page.

Constraint profile:

The Problem They Experience#

The agent is debugging blind. It reads the component, reasons about what should render, and confidently proposes a fix for a bug it cannot see. The developer becomes a manual feedback loop: run the app, look, screenshot, paste, describe what’s wrong. That copy-paste cycle is most of the friction in agent-assisted frontend work.

“It works on my machine” is unverifiable by the agent. It cannot confirm the fix actually fixed anything. Verification is entirely the human’s job.

Runtime problems are invisible. A layout breaking only at a certain viewport, a request failing only when authenticated, a memory leak after ten minutes of use — none of this is in the source. The agent has no access to the running system’s behaviour.

Performance work is guesswork. “Why is this page slow?” needs a profile, a trace, a Lighthouse run. The developer produces those manually and translates findings back to the agent in prose.

Why This Layer Fits#

For this persona the value is closing the loop: the agent proposes a change, applies it, looks at the result, and iterates — without a human ferrying observations back and forth.

Notably, they don’t want an agent. They already have one, they trust it, and it knows their codebase. Adding a second agent framework with its own loop and prompts would be strictly worse: two agents that don’t share context, one of which knows nothing about the code.

They want their existing agent to grow hands. That is precisely tier 3.

What Fits Their Constraints#

Tier 3, and for most of this persona that’s the whole answer.

Chrome DevTools MCP is the strongest fit, and this persona is the reason it has 48.6k stars:

• 61 tools spanning far more than clicking. Performance traces, Lighthouse audits, network inspection, heap snapshots, console messages with source-mapped stack traces.
• Source mapping is the detail that matters most. An agent reading minified bundle traces is useless; one reading traces mapped to original source can actually debug.
• Chrome-only is a non-issue here. They develop in Chrome. Cross-browser is a QA concern (persona 5), not a development-loop concern.
• Apache-2.0, zero infrastructure. A config entry in the harness. Nothing to operate.

Playwright MCP fits alongside it when cross-browser checks matter or when the accessibility tree gives more stable targeting. The recurring independent guidance — install both in lean modes and let the agent pick — is sound and cheap.

Tier 2 does not fit this persona, and this is the survey’s most common mis-adoption. A developer evaluating “browser agents” encounters browser-use’s 108k stars and adopts a standalone Python agent framework to solve a problem their existing harness could solve with a config entry. More machinery, separate context, no benefit.

What They Sacrifice#

The security blast radius is the largest in the survey, and this persona is the most exposed to it. Their harness typically holds filesystem access, shell execution, and their repository — so an indirect prompt injection from a page the agent visits can reach far beyond the browser.

Chrome DevTools MCP’s own documentation is explicit that it exposes browser content to MCP clients for inspection and modification.

The mitigations that matter here:

• A dedicated browser profile for agent use. Never the personal profile with production credentials, email, and banking sessions. This is cheap and eliminates the worst outcomes.
• Local development targets, not arbitrary sites. Pointing the agent at localhost is low-risk; browsing the open web while holding shell access is not.
• Awareness that “look at this page” means “let untrusted text into a context with shell access.”

No unattended capability. Tier 3 in a harness is interactive by nature. When this persona later needs scheduled automation, that’s a different tier and a different project.

Decision Criteria#

Choose Chrome DevTools MCP if: developing web applications in Chrome and wanting the agent to debug, profile, and verify. Default for this persona.

Add Playwright MCP if: cross-browser behaviour matters, or accessibility-tree targeting proves more stable.

Install both if: unsure. Low cost, and the agent picks.

Do not choose tier 2 unless a genuine unattended automation need appears — at which point re-read as persona 2 or 3.

Do not choose tier 4. Local browsers are free and adequate.

The Insight This Persona Represents#

This is the largest population in the category, and it is not who tier 2 markets to.

Chrome DevTools MCP at 48.6k stars — ahead of Stagehand and Skyvern combined, and it isn’t even an agent — is best explained by this persona. Every published comparison frames the decision as “which browser agent framework?” For this reader the correct answer is none of them, and the correct action is a config entry in a harness they already run.

The category’s most useful advice for its largest audience is therefore: check whether your existing agent can just be given browser access. If yes, stop there.

Persona 3: The Data Team Facing the Long Tail#

Who They Are#

A data or research team whose job is gathering information from across the web at breadth — market intelligence, competitive monitoring, public-record collection, academic data gathering, lead research. Five to twenty people, at least half of them technical.

Their defining characteristic is breadth over depth: hundreds or thousands of sites, most visited rarely, all doing conceptually the same thing in different ways.

Constraint profile:

The Problem They Experience#

Per-site development doesn’t scale past a point. Writing an extractor per site works for twenty sites and collapses at five hundred. The team becomes a script factory, and the factory’s output decays as fast as it’s produced.

The sites have nothing in common structurally. Five hundred company career pages, or supplier catalogues, or municipal planning portals — every one is different markup for the same concept. There is no shared selector strategy because there is no shared structure.

Coverage is the metric, and it’s stuck. They can reach 60% of their target list and the remaining 40% each need bespoke work that is never worth it individually. That long tail is permanently out of reach.

Anti-bot measures block them at scale. Volume across many domains triggers exactly the defenses that tier 4 exists to handle.

Why This Layer Fits#

This persona has the strongest case in the survey for agent-first automation, and it is the mirror image of persona 2.

Persona 2 knows its sites, so deterministic code is cheap and the hybrid dial pays. This persona knows nothing about most of its targets, so the deterministic fraction approaches zero — Stagehand’s advantage evaporates precisely here, and an agent that figures out each site from scratch is the only approach that scales across breadth.

The economics also invert. Per-run cost is higher, but there is no per-site development cost at all, and per-site development was the binding constraint.

The Caveat That Comes First#

Many teams matching this description want extraction, not agency — and would be far better served outside this category.

If the task is “get the content of these pages,” a crawling and extraction tool is cheaper, faster, more reliable, and dramatically simpler than a browser agent. No LLM in the loop per step, no non-determinism, no browser-hours.

Browser agents earn their cost when the task requires acting: logging in, navigating past interaction gates, filling search forms, clicking through pagination that isn’t in the URL, dismissing interstitials, handling session state.

The honest test: could a well-configured crawler get this? If yes, use one — see long-tail.md for that wing. If reaching the data requires a sequence of interactions that differs per site, this category is right.

A meaningful share of this persona should stop reading here and go use a crawler.

What Fits Their Constraints#

browser-use is the strongest fit for those who genuinely need agency.

• Agent-first handles unknown sites, which is the entire requirement. No per-site development is the value proposition.
• DOM-driven perception is the right economics at volume. At thousands of runs, vision’s premium per step compounds into a serious number, and most target sites are conventional enough for DOM to work.
• Python-native fits where data teams already live.
• Model-agnostic, which matters enormously here — see below.
• MIT, so licensing is a non-issue.

Tier 4 is genuinely necessary for this persona, unlike most others:

• Concurrency across hundreds of sites exceeds what local infrastructure handles comfortably.
• Anti-bot measures at volume across many domains are exactly the adversarial problem runtimes solve, and it is the one problem they solve that you genuinely cannot easily solve yourself.
• Browserbase or Steel Cloud, depending on whether self-hosting is required. Note that self-hosted Steel lacks the anti-bot layer — which for this persona is the main reason to be there.

1.215’s proxy layer belongs in this architecture. Thousands of agent runs making varied-difficulty model calls is the canonical routing case: cheap models for routine navigation, capable models for hard decisions. At this volume that routing is a large fraction of total cost, and neither category’s vendors mention the other.

What They Sacrifice#

Cost at volume, and it compounds three ways. Inference per step, browser-hours during model latency, and retries when the agent misjudges. This persona is the most exposed to the compounding cost model in the entire survey. Step limits are essential, not optional.

Reliability at the tail. 60–90% task success across thousands of runs means hundreds of failures. Acceptable for aggregate research; unacceptable if any single result is load-bearing. The pipeline needs to treat failure as routine and track coverage honestly.

Legal and terms-of-service exposure. Automated access at volume against sites that don’t want it is the uncomfortable centre of this persona’s activity. The anti-bot capabilities that make it possible are adversarial by design. This is the persona for whom that exposure is real rather than theoretical, and it is a business decision, not a technical one.

Non-determinism in a data pipeline. The same page may yield slightly different extractions across runs. Schema-constrained extraction helps; it does not eliminate the variance.

Decision Criteria#

First: confirm you need agency, not extraction. If a crawler could do it, use one.

Choose browser-use if: targets are numerous, unknown, and require interaction. Default for this persona.

Choose Skyvern if: targets are visually hostile — canvas, image-based, non-semantic — and AGPL clears policy. The vision premium is expensive at this volume, so this should be a considered choice, not a default.

Add tier 4 (Browserbase or Steel Cloud): near-mandatory at this scale, for concurrency and network identity both.

Add an LLM router (1.215): at this volume, model routing is a material cost lever.

Do not choose Stagehand for the unknown long tail — its advantage requires foreknowledge this persona doesn’t have. It remains a good choice for whatever subset of sites is known and stable.

The Structural Observation#

This persona and persona 2 are the same technology used in opposite regimes, and comparing their conclusions is the clearest illustration of why this category has no single winner:

Same category, same problem statement, opposite answers — decided entirely by whether the sites are known in advance.

Persona 6: The Team That Needs Something Else Entirely#

Who They Are#

A team that has arrived at this category after seeing a compelling demo — an AI booking a flight, filling a form, navigating a site unaided — and concluded this is the answer to their problem.

For a substantial fraction of them, it isn’t. Three cheaper, simpler, more reliable answers sit adjacent to this category, and nobody selling browser agents will point them out.

This persona is here because a survey that only describes adopters overstates its category’s necessity.

Redirect 1: An API Exists#

The single most valuable question in this survey: has anyone checked?

This entire domain is a workaround for the absence of an API. Where one exists it is better on every axis without exception:

Where teams miss an existing API:

• Undocumented but present — the site’s own frontend calls something; open the network tab
• Available on request, or on a higher tier
• A partner or bulk-data programme nobody asked about
• A third-party aggregator already normalizing this data
• Available as a data export nobody looked for

The check costs an hour and can save a project. It is skipped constantly, because the demo was exciting and the API question is boring.

Redirect 2: The Need Is Extraction, Not Agency#

If the task is “get the content of these pages,” this is the wrong category.

Crawling and extraction tools fetch pages, render where necessary, and return structured content. No LLM in the loop per step, no non-determinism, no browser-hours, far cheaper and faster.

Browser agents earn their cost only when the task requires acting:

The test: write down the steps a person takes. If every step is “load a URL, read it,” use a crawler. If the steps include interactions that differ per site, you’re in the right place.

A meaningful share of persona 3 — the long-tail data team — actually belongs here.

Redirect 3: The Site Is Stable and the Volume Is High#

If your target doesn’t change and you run the task constantly, write a script.

A Playwright script (1.118) costs nothing per run, executes in seconds, and does the same thing every time. A browser agent costs money per run, takes far longer, and varies.

The agent’s advantage is resilience to change. If nothing changes, you are paying for insurance against a risk you don’t have.

The break-even is site count and change frequency, not volume:

• One stable site, run constantly → script, overwhelmingly
• Twelve sites redesigning once a year each → that’s monthly breakage, forever → agent
• Hundreds of unknown sites → agent, no other option scales

Count redesigns, not transactions.

The Fourth Case: Wait#

Even with a genuine need, this technology is young enough that waiting is sometimes right.

Signals that waiting is reasonable:

• The task’s failure cost is high and 60–90% success isn’t close to enough
• The workflow is fully autonomous with no human checkpoint available
• Targets are hostile and you’re not prepared for an ongoing arms race
• Nobody on the team can own it

Signals that waiting is not reasonable:

• Scripted automation is actively decaying and consuming real time
• Manual work is a measurable, ongoing cost
• Failure is cheap and detectable
• A human checkpoint fits naturally into the workflow

What This Persona Should Actually Do#

1. Check for an API. One hour. Do this first, always.
2. Determine whether the need is reading or acting. Reading → crawler.
3. Count your sites and their change rate. One stable site → script.
4. If you still need this, re-read as persona 1, 2, 3, or 4 depending on whether you have a harness, know your sites, or face the long tail.
5. If you do adopt, start with the smallest real task — not the impressive one — and measure cost and success rate on your own sites before committing.

The Honest Framing#

This category is genuinely useful and it is over-marketed relative to its reliability. The demos are real and they show the good runs.

The value is converting brittle instructions into durable intentions. That trade is excellent when pages change unpredictably and you’re paying for it in maintenance. It is poor when an API exists, when the task is pure reading, or when the target is stable.

The mistake this persona is at risk of is adopting a probabilistic, per-step-billed, prompt-injectable system to solve a problem that had a deterministic, free, secure answer that nobody checked for.

Check for the API.

Persona 2: The Operations Team Automating Known Portals#

Who They Are#

A back-office, finance, logistics, or revenue-operations team inside a mid-sized company. Not primarily engineers — though one or two can write Python — and their work involves moving data and actions between systems that were never designed to talk to each other.

They have a fixed, known set of external portals: a dozen supplier systems, a couple of carrier sites, a bank, a government filing portal, two SaaS tools without usable APIs. Those targets change slowly. The work against them repeats daily or weekly.

Constraint profile:

The Problem They Experience#

Someone is doing this by hand. A person logs into eleven portals every morning, downloads reports, re-keys figures into a spreadsheet, and submits forms. It takes hours, it’s error-prone, and it’s the least satisfying job in the department.

Scripts were tried and they rotted. Someone technical built Selenium or Playwright automation two years ago. It worked beautifully, then supplier four redesigned, then supplier seven added a cookie banner, then the bank changed its login flow. Now half the scripts are disabled and nobody has time to fix them. The scripts didn’t fail all at once — they failed one at a time, continuously, forever.

Failures are silent and expensive. A script that submits a form incorrectly may not surface for weeks. In a write-heavy workflow that means wrong orders, missed filings, or duplicate submissions.

Every new supplier is a project. Onboarding means writing new automation, and the backlog is long enough that some suppliers are simply never automated.

Why This Layer Fits#

This persona has the category’s canonical problem: the maintenance term has overtaken the build term. They aren’t automating something new; they’re trying to stop the automation they have from decaying.

That is exactly the trade the domain offers — pay more per run, in exchange for runs that keep working when pages change.

Their write-heavy profile also puts them squarely where browser agents earn their cost. Read-only work is often better served by extraction tools; logging in, filling forms, and submitting is where a real browser and real reasoning are genuinely required.

What Fits Their Constraints#

Stagehand is the strongest fit, and this persona is the reason the hybrid model exists.

• They know their sites. The condition on which the hybrid saving depends is fully satisfied. Navigation to a known portal, a known login URL, a known report page — all deterministic and free. Only the parts that actually vary invoke a model.
• Self-healing addresses the exact failure that burned them. When supplier four redesigns, a cached action misses, the model re-resolves it, and the workflow continues. That is the specific pain that killed their scripts.
• Deterministic steps cannot be prompt-injected. For a write-heavy workflow with real credentials submitting real forms, a mostly-deterministic script has a fraction of the attack surface of an agent-first equivalent. This matters more for this persona than any other and neither Stagehand nor anyone else markets it.
• extract({schema}) returns structured data straight into their spreadsheet or database rather than prose someone has to parse.
• Cost stays predictable, which matters for a team whose budget is not an engineering budget.

browser-use fits for the long tail — the suppliers nobody ever automated because each was a project. Agent-first handles unknown sites without per-site development, which is precisely where their backlog is.

The mature architecture is both: Stagehand for the eleven known portals, browser-use for the tail. They compose fine; nothing forces one choice.

Skyvern fits if the portals are visually awful — and legacy supplier portals often are. Canvas widgets, table-based layouts, forms with no semantic markup. But AGPL must clear policy first, and in a company with a compliance function it frequently won’t.

What They Sacrifice#

Determinism, in a write-heavy workflow. This is the sharpest trade for this persona. Non-determinism plus imperfect task success means the automation will sometimes do the wrong thing — and “the wrong thing” here is a submitted form, not a wrong answer.

Confirmation on consequential actions is not optional for this persona. Anything that submits, purchases, or files should be reviewed or at minimum verified against end state before it counts as done. That reintroduces some manual work, and it is the honest price of automating write operations with a probabilistic system.

Ongoing cost where there was none. Scripts cost nothing per run; agents cost per step. For daily runs across a dozen portals this is modest, and it needs a budget line where previously there wasn’t one.

A new skill in the team. Someone must own the workflows. Lighter than maintaining Selenium, but not zero.

Credential concentration. The automation holds logins to eleven external systems. Scoped accounts with minimum permissions, not the finance lead’s personal credentials.

Decision Criteria#

Choose Stagehand if: the site set is known and stable, the workflow is repetitive, and cost predictability matters. Default for this persona.

Add browser-use if: there’s a long tail of one-off or rarely-used portals where per-site development was never justified.

Choose Skyvern if: portals are visually complex and DOM-hostile — and AGPL clears policy. Check that first.

Consider tier 4 only if: portals actively block automation, or concurrency exceeds what a single machine handles. Many teams at this scale need neither.

Do not choose tier 3 — no existing harness, and this is unattended work that harnesses aren’t shaped for.

The Business Case, Honestly#

The value here is not labour replacement, and framing it that way usually oversells.

The value is the maintenance asymptote. Scripted automation has an ongoing repair cost that grows with the number of sites and never ends. Agentic automation trades that for a per-run cost that is predictable and doesn’t grow with site count.

The break-even is about site count and change frequency, not volume. One stable site run constantly: keep the script. Twelve sites that each redesign once a year: that’s a redesign every month, forever, and the agent wins decisively.

This persona should count their sites and their redesigns, not their transactions.

Persona 5: The QA Engineer#

Who They Are#

A test engineer or SDET who owns an end-to-end test suite. They already use Playwright — covered as a testing tool in 1.118 — and they maintain hundreds of tests against their own application.

They are in this survey because they sit exactly on the boundary between 1.118 and 1.216, and the vendors in both categories are courting them with overlapping claims.

Constraint profile:

The Problem They Experience#

Selector maintenance is a permanent tax. Every frontend refactor breaks tests. The tests are correct about intent and wrong about markup. The team has adopted data-testid conventions, which helps and requires discipline nobody enforces consistently.

Flaky tests erode trust. Timing, animation, async state. A suite that fails 3% of the time for no reason is a suite people start ignoring, and then it protects nothing.

Writing tests is slow. Each new feature needs new tests, and writing them is mechanical, tedious work that competes with exploratory testing — which is where a good QA engineer’s judgment actually pays.

Coverage has gaps nobody admits. Some flows are too fiddly to automate reliably, so they’re tested manually or not at all.

The Critical Distinction for This Persona#

Do not replace deterministic tests with agentic ones.

This is the most important guidance in this file, because the category’s marketing points the opposite way.

A test’s value comes from being deterministic. It asserts the same thing every run, so a failure means the application changed. An agentic test that “figures out how to log in” does something different each run — and when it fails you cannot tell whether the app broke or the agent had a bad day.

A non-deterministic test is not a weaker test. It is a different artifact that cannot do a test’s job. Replacing a flaky test with an agentic one trades a 3% flake rate for an unquantifiable one, and loses the property that made it a test.

Where agentic capability genuinely helps QA:

Where it doesn’t: the committed regression suite. That stays deterministic.

The pattern: agents help you produce and maintain deterministic tests. They don’t replace them.

What Fits Their Constraints#

Playwright MCP is the best fit for the authoring and diagnosis loop:

• Cross-browser — Chromium, Firefox, WebKit. QA is where cross-browser genuinely matters, unlike persona 1’s development loop. This is the persona for whom Playwright MCP’s main differentiator is decisive.
• Accessibility-tree targeting produces suggestions grounded in roles and labels rather than brittle class names — which is exactly the selector strategy a good test suite wants anyway. The agent’s natural output is better test code than most humans write by default.
• Same underlying tool as their suite, so generated code fits the existing project.
• Apache-2.0, first-party Microsoft, no infrastructure.

Chrome DevTools MCP complements it for diagnosis — network inspection, console with source-mapped traces, performance profiling. When a test fails in CI and nobody knows why, this is the tool that finds out.

Stagehand fits for the genuinely un-automatable flows — the ones currently untested because they’re too fiddly. Its self-healing cache plus deterministic steps is closer to test-shaped than any agent-first option, and its act() steps can cover the parts that defeated conventional selectors. Use deliberately and sparingly, and know that these are not deterministic tests.

Tier 4 does not fit. CI runners run browsers. That’s what they’re for.

Agent-first frameworks do not fit this persona’s core work. browser-use against your own app is exploratory testing, which is legitimate and is not a regression suite.

What They Sacrifice#

Nothing, if the boundary is respected. This is the rare persona that can adopt the category’s benefits without giving up what they have — because the adoption is additive to authoring and diagnosis, not a replacement for the suite.

Everything, if the boundary is crossed. A regression suite rebuilt on agentic execution is no longer a regression suite. It cannot tell you whether the application changed, which is its entire function.

Cost in CI if agentic steps land in the suite. Deterministic tests are free per run; agentic steps are not, and a suite running on every commit multiplies that immediately.

Review discipline on generated tests. An agent that drafts tests will draft plausible tests that assert the wrong thing. Generated tests need the same review as generated code — arguably more, because a bad test is worse than no test: it provides false confidence.

Decision Criteria#

Choose Playwright MCP if: you want agent help authoring and diagnosing Playwright tests across browsers. Default for this persona.

Add Chrome DevTools MCP if: failure diagnosis needs network, console, or performance depth.

Choose Stagehand if: specific flows resist conventional automation and you accept they’re not deterministic tests.

Do not: rebuild the regression suite on agentic execution. Keep the suite deterministic; use agents to build and maintain it.

The Boundary With 1.118#

For clarity, since this persona spans both surveys:

The rule: if an LLM is deciding what happens next, it’s 1.216. If you wrote what happens next, it’s 1.118. The best QA setups use both, with a clear line between them — and drawing that line explicitly is the most valuable thing this persona can do.

Persona 4: The Regulated Internal-Systems Team#

Who They Are#

A platform or automation team inside a bank, insurer, hospital system, government agency, or defense contractor. The systems they automate against are internal: a legacy claims system, an ERP with a web front end, a case-management application whose vendor was acquired in 2019 and whose API was never finished.

Their constraint is not that the sites are hard. It is that the credentials are radioactive.

Constraint profile:

The Problem They Experience#

The system has no API and never will. The vendor is gone, or the integration costs more than the department’s annual budget, or the roadmap answer is “next year” and has been for six.

People are the integration layer. Staff re-key data between systems all day. It’s expensive, error-prone, and everyone knows it.

Robotic process automation was tried. An RPA platform was purchased, workflows were built, and they broke on the first interface update. The licenses are still being paid. This persona is frequently on their second or third attempt at this problem and is appropriately sceptical.

Every dependency is audited. Licensing, data flow, and vendor relationships all get reviewed. Ambiguity is a finding, and findings block deployments.

Sessions carry serious access. The automation logs into systems holding patient records, transaction histories, or case files. Where those credentials go is the central question, before anything else.

Why This Layer Fits#

Their internal systems are precisely the case the domain was built for: web interfaces that will never have APIs, changing unpredictably, with no vendor to petition.

They also have an advantage no other persona has: their targets have no bot detection. Internal systems don’t defend against automation. The adversarial problem that dominates tier 4’s value proposition is entirely absent here — which changes the tier-4 calculus completely.

What Fits Their Constraints#

Self-hosting everything is non-negotiable. This eliminates Browserbase and any hosted runtime, not on merit but on a constraint that precedes merit.

Steel.dev self-hosted is the only tier-4 option, if tier 4 is needed at all — and often it isn’t, since concurrency against internal systems is usually modest.

The gap in self-hosted Steel is irrelevant here, and this is a genuinely fortunate alignment: self-hosted Steel lacks the proprietary anti-bot layer, and this persona’s targets have no anti-bot measures. The limitation that would disqualify it for persona 3 costs this persona nothing.

Stagehand fits the workflow shape best. Internal systems are known and stable-ish, so the deterministic fraction is high. And deterministic steps cannot be prompt-injected — for a workflow with credentials into a claims system, that is a security property worth choosing on, not merely a cost saving.

browser-use fits for teams preferring Python and a single dependency, accepting higher per-run cost and full model mediation.

Skyvern is very likely excluded on AGPL. This persona is the most likely in the survey to have automated dependency scanning with a blanket copyleft prohibition. Worth confirming before evaluating — but expect a no.

Tier 3 fits a narrower interactive case: an analyst using a governed agent harness to work through a system interactively. Distinct from the scheduled automation and typically under separate governance.

What They Sacrifice#

They operate everything. Browsers, agent runtime, model access. For a platform team that’s normal work, and it must be staffed rather than assumed.

Model access is its own governance question, and it is the one this persona most often overlooks. Page content — which in this persona means patient records, claim details, case files — is sent to a model provider on every step. That is a data-flow question of exactly the kind their compliance function exists to review.

This makes 1.215’s proxy layer close to mandatory for this persona, not optional: self-hosted routing, keeping prompts inside the perimeter, pointing at self-hosted inference (1.209) where policy requires it. Adopting browser automation without addressing where the page content goes is an incomplete design, and it is the most common gap in this persona’s plans.

Non-determinism in consequential writes. Submitting a claim incorrectly is materially worse than a wrong search result. Human confirmation on consequential actions is required here, which caps the automation benefit and is the correct trade.

Audit trails must be built. Regulators will ask what the automation did and why. Complete action logging is a requirement, not an observability nicety.

Decision Criteria#

Choose Stagehand + self-hosted browsers if: internal systems are known, workflows are write-heavy, and minimizing model-mediated steps is a security goal as well as a cost one. Default for this persona.

Choose browser-use if: Python-only is preferred and higher per-run cost is acceptable.

Add self-hosted Steel if: concurrency genuinely exceeds local capacity. Frequently unnecessary.

Add a self-hosted LLM proxy (1.215) if: page content is sensitive — which it is, by definition, for this persona. Treat as mandatory.

Do not choose: any hosted runtime, or Skyvern without an explicit AGPL exemption.

The Consideration Nobody Raises#

The page content goes to a model provider.

Every observe step sends what’s on screen to an LLM. For this persona, what’s on screen is the regulated data their entire compliance posture is built around.

This is completely absent from every vendor’s material in this category — the marketing discusses automation capability, not data flow. Yet for a hospital automating a claims system, “we send screenshots of patient records to a third-party model provider on every step” is a sentence that ends projects.

The mitigations are real and must be designed in from the start:

• Self-hosted inference (1.209) behind a self-hosted proxy (1.215), so content never leaves
• Provider agreements with appropriate data terms where fully-local isn’t feasible
• Maximizing deterministic steps — content in a deterministic step is never sent anywhere
• Redaction before observation, where the workflow permits

The last two make Stagehand’s hybrid model a compliance architecture, not just a cost optimization — every step expressed as code is a step whose page content was never transmitted. That reframing is the single most useful thing this persona can take from the survey.

S4 Strategic Discovery — Approach#

Stage goal: What survives, and what happens to you if your choice doesn’t.

Date executed: 2026-08-05

Three Category-Level Risks#

Unusually for a survey, the dominant strategic risks here are category-level rather than vendor-level. No tool choice mitigates them, so they are assessed once, before the individual options.

Risk 1: Computer-Use Models May Absorb Tier 2#

The most significant strategic uncertainty in this category.

Anthropic and OpenAI ship models trained to operate computers — taking screenshots and emitting actions natively. No framework decides how to observe or what to prompt; the observe-decide-act loop moves into the model’s weights.

If those models become reliably good at browser tasks, what is tier 2 for?

A framework’s value is currently: perception engineering (how to serialize a page usefully), loop management, prompting, error recovery, action abstractions. Every one of those is work the model doesn’t do well enough alone — today.

The current evidence says the gap is real: published 2025–2026 measurements put DOM-driven stacks 12–17 percentage points ahead of vision-driven approaches, including computer-use models, on common tasks. S2 established the mechanical reason — DOM approaches skip an error-prone localization stage entirely.

Why that gap may not persist: it is a model-capability gap, and model-capability gaps have closed repeatedly and fast. Nothing about coordinate localization is fundamentally unsolvable.

Why tier 2 may survive anyway — and this is the more likely outcome:

• DOM serialization is genuinely better input, not a workaround. Feeding a model exact element references will probably always beat asking it to estimate pixel coordinates, regardless of how good vision gets.
• Orchestration isn’t perception. Retries, step limits, structured extraction, caching, scheduling — none of that is model capability.
• The hybrid argument is economic and survives any model improvement. Deterministic steps cost nothing. A better model doesn’t make an LLM call cheaper than not making one.

Assessment: computer-use models likely compress tier 2’s perception value and leave its orchestration value intact. Frameworks get thinner, not obsolete. The options most exposed are those whose differentiation is purely perception — which is Skyvern’s position precisely.

What to watch: computer-use model scores approaching DOM-driven levels on the same benchmark. That is the signal, and it is measurable.

Risk 2: Prompt Injection Is Unsolved and May Be Unsolvable#

Documented in production (Unit 42, December 2025), rising (Google: +32% relative, November 2025 – February 2026), and treated by security researchers as fundamental rather than a bug awaiting a patch.

The mechanism is architectural: a model cannot reliably distinguish instructions from data when both arrive as text. An agent with browser access holds authenticated sessions and reads attacker-controlled content. No proposed mitigation has closed this.

The strategic consequence, if it holds: it caps how autonomous these systems can responsibly become. And the category’s most valuable use cases — unattended automation against untrusted sites — are precisely the ones the risk most restricts.

That is a ceiling on addressable market, not merely a security caveat. A category whose safe operating envelope is “attended, or against trusted sites, with scoped credentials” is a meaningfully smaller category than the demos imply.

No option is differentially exposed except in blast radius: tier 3’s is the largest (the harness usually holds shell and filesystem tools too); Stagehand’s deterministic steps are the only genuine reduction available anywhere in the survey.

Risk 3: Tier 4’s Value Is Adversarial by Construction#

A meaningful share of hosted-runtime value is defeating bot detection — residential proxies, fingerprint management, CAPTCHA handling.

This is a permanent arms race with well-funded opponents, and it carries legal and terms-of-service exposure that is the customer’s to manage, not the vendor’s.

Three ways this could go:

• Continues as-is. Both sides invest, neither wins, the service stays valuable. Most likely near-term.
• Detection wins durably. Anti-bot improves faster than evasion; the tier’s value erodes toward plain browser hosting, which is commodity infrastructure.
• Legal or regulatory pressure. Enforcement against automated access at scale would hit this tier hardest.

The asymmetry worth noting: teams automating internal systems (persona 4) get tier 4’s concurrency value with none of the adversarial exposure — their targets don’t defend against them. Teams automating the open web at volume (persona 3) carry all of it.

Assessment Framework#

Each option is evaluated on:

1. Business model durability — does the way it makes money support continued investment?
2. Governance risk — who decides its future?
3. Exit cost — what does leaving actually cost?
4. 5-year outlook — with the specific signal that would falsify it.

Then mapped to Conservative, Performance-First, and Adaptive strategic paths.

Files in This Stage#

• browser-use-viability.md
• stagehand-viability.md
• skyvern-viability.md
• mcp-servers-viability.md
• hosted-runtimes-viability.md
• recommendation.md

browser-use — Strategic Viability#

Verified: 2026-08-05

Position#

The category’s dominant open-source project by adoption: 108,000 GitHub stars, 10,022 commits, MIT, Python. Founded by Magnus Müller and Gregor Žunič, operating between Zurich and San Francisco, with a commercial cloud offering alongside the library.

108k stars places it among the most-starred AI projects in existence — roughly 4.5× Stagehand and Skyvern combined, and more than double the star count of every option in 1.215’s LLM-proxy category put together.

Business Model Durability#

Open-source library plus a commercial cloud service. The conventional structure for this kind of project, and its durability depends on a conversion rate that isn’t public.

What supports it: enormous top-of-funnel. A library with this much attention generates a very large pool of potential customers, and teams that outgrow local execution need somewhere to run browsers at scale — which the same team can sell them.

The structural tension: the natural upsell is a hosted runtime, which puts them in tier 4 against Browserbase ($67.5M raised) and Steel. That is a well-capitalized, infrastructure-heavy market where the adversarial anti-bot treadmill is the real product. Competing there is a different business from maintaining a popular library.

The MIT license means the library cannot be enclosed. Unlike 1.215’s LiteLLM — where an open-core boundary dispute (#34241) creates genuine ambiguity about what stays free — there is no enterprise directory here and no carve-out. The library is permissively licensed throughout, and monetization must come from services rather than from gating features.

That is a cleaner position for users and a harder one for the company.

Governance Risk#

Low on licensing, moderate on concentration.

MIT with no carve-out means a fork is always available and always legal. 10,022 commits represent substantial accumulated engineering, and the contributor base — while not independently verified for this survey — is plausibly large given the adoption.

The concentration question: this is a young company with a small founding team and a project that became extremely popular very fast. The failure mode is not abandonment but divergence of attention — the commercial cloud absorbing engineering focus while the library coasts.

The specific thing that would signal trouble: provider and model support falling behind, or the library’s release cadence slowing while the cloud product ships. In a category where model capabilities change monthly, standing still is losing ground.

The reassuring counterweight: at 108k stars, a maintenance slowdown would be highly visible and a fork would attract contributors. Popularity of this magnitude is itself a durability mechanism.

Exit Cost#

Low, and this is a genuine strategic advantage.

Ports easily: the interface is a natural-language goal. There is no schema, no configuration language, no accumulated state, no proprietary format. Switching to another agent-first framework means rewriting invocation code, not re-deriving logic.

Doesn’t port: prompt tuning specific to browser-use’s loop, and any integration built around its Python API surface. Both modest.

The deeper point: because these frameworks are thin wrappers over Playwright plus a model, none of them accumulates much lock-in. The category as a whole has unusually low switching costs, which is good for buyers and hard for vendors — and it is the main reason the strategic risks here are category-level rather than vendor-level.

5-Year Outlook#

Likely still here. 108k stars, 10,022 commits, MIT, and a clear market position do not evaporate. The library will very probably exist and be maintained in some form.

The real question is whether tier 2 still matters, which is the category-level risk from approach.md rather than anything specific to this project.

browser-use’s specific exposure to that risk is moderate. Its differentiation is partly perception engineering — DOM serialization, which computer-use models could eventually subsume — and partly orchestration, retries, and ecosystem, which they won’t. The DOM-serialization advantage may actually persist regardless of model capability, since exact element references are simply better input than coordinate estimation.

What would falsify a positive outlook: release cadence slowing while the cloud product ships; computer-use models reaching DOM-driven accuracy on the same benchmark; or a pivot that deprioritizes the library.

What would strengthen it: sustained release velocity, published production case studies at scale (currently the thinnest part of its evidence base), or foundation-style governance.

Organizational Fit#

Best for: teams facing unknown or long-tail sites, working in Python, needing autonomous operation without per-site development. Persona 3 primarily, and persona 2’s tail.

Poor for: teams that already run an agent harness and need interactive capability (persona 1 — tier 3 is less machinery), and teams with known stable sites where hybrid is cheaper.

The caution worth repeating: 108k stars measures attention, and public evidence of large unattended production deployment is thinner than the number implies. Adopters should pilot on their own sites rather than inferring operational maturity from popularity.

Strategic Paths#

Conservative: Good fit. MIT with no carve-out, huge community, low exit cost, forkable. The main conservative caution is operational rather than strategic — pilot before committing, set hard step limits, and treat 60–90% task success as a design constraint rather than a caveat.

Performance-First: Strong on capability (87.4% on Odysseys long-horizon tasks is the best published result in the survey for that class of work), weak on cost. Agent-first is the most expensive architecture per run, and context growth makes long tasks superlinearly costly. Choose it for capability, budget for it accordingly, and pair with an LLM router (1.215) to control model spend.

Adaptive: Excellent fit. Lowest lock-in in the category, model-agnostic, MIT. If the category shifts — computer-use models absorbing perception, or tier 3 absorbing interactive use — a browser-use investment is among the cheapest to walk away from.

Tier 4 — Hosted Runtimes, Strategic Viability#

Verified: 2026-08-05

Position#

Business Model Durability#

The tier’s economics are sound and its moat is uncomfortable.

S2 established that tier 4 solves three problems: concurrency (moderate difficulty), session persistence (moderate), and network identity (high, permanent). Essentially all durable third-party value is in the third — and that value is adversarial by construction.

Concurrency and session management are engineering any competent platform team could do. Residential proxy pools, fingerprint management, and CAPTCHA handling are a treadmill you would otherwise run forever against well-funded opponents.

So the business is real, and it is a business built on staying ahead of bot detection.

Browserbase’s two-tier strategy is the strongest commercial structure in either this survey or 1.215: give away an excellent MIT framework at tier 2 (Stagehand), sell the runtime at tier 4. The free component is fully usable standalone, there is no license boundary to dispute, and the conversion trigger — needing scale or network identity — is a genuine need rather than an artificial gate.

Steel’s position is different and narrower: open source with a hosted tier, priced legibly (~$0.05–$0.10/browser-hour, 100 free hours/month). Its strategic asset is that self-hosting is possible at all — which for regulated buyers makes it the only option in the tier rather than the best one.

Governance Risk#

Browserbase: venture-backed, 2024-founded, $67.5M raised at ~$300M. Requires a growth trajectory. The usual venture pressures apply — pricing changes, strategy shifts, acquisition. No open-source escape hatch for the runtime itself, though Stagehand’s MIT license means the framework survives regardless of what happens to the company.

That split is worth appreciating: a team using Stagehand against local browsers is insulated from Browserbase’s corporate fate. A team dependent on the runtime is not.

Steel: open source, so the code persists. But self-hosted Steel lacks the proprietary anti-bot layer, which for open-web workloads is the main reason to be in this tier at all. The open-source escape hatch is therefore partial — it protects your ability to run browsers, not your ability to reach defended sites.

The Adversarial Risk, Assessed#

This is the tier’s defining strategic uncertainty and it deserves a direct verdict.

Three trajectories:

1. The arms race continues (most likely, near term). Both sides invest, neither wins decisively, the service stays valuable and prices hold. Detection improves, evasion improves, customers keep paying for someone else to run that treadmill.

2. Detection wins durably. Anti-bot measures — increasingly AI-assisted themselves — outpace evasion. Tier 4’s differentiated value erodes toward plain browser hosting, which is commodity infrastructure with commodity margins. This would be an existential compression of the tier’s economics, not merely a setback.

3. Legal or regulatory pressure. Enforcement against automated access at scale, or platform terms-of-service litigation, would hit this tier hardest — the vendors provide the capability, but the exposure sits with the customer.

The asymmetry that matters for buyers: teams automating internal systems (S3 persona 4) get tier 4’s concurrency value with none of the adversarial exposure — their targets don’t defend against them. Teams automating the open web at volume (persona 3) carry all of it, and it is a business risk rather than a technical one.

Practical guidance: a team whose automation depends on defeating bot detection has a strategic dependency on an arms race outside its control. That is worth stating in a risk register, and it is discussed nowhere in either vendor’s marketing.

Exit Cost#

Low for Steel, moderate for Browserbase.

Ports easily: both expose browser sessions over standard protocols. Switching runtimes is largely a connection-string change, and the tier-2 or tier-3 layer above is unaffected.

Doesn’t port:

• Session replay history (Browserbase) — the debugging record for non-deterministic agents. Genuinely valuable and genuinely non-portable.
• Anti-bot capability — whichever provider’s evasion works for your targets. Moving may mean losing access to sites.
• Accumulated fingerprint/proxy configuration tuned to specific targets.

The general rule holds: the software layers in this category have very low lock-in; the adversarial capability is where the stickiness lives, and it is the part you cannot replicate yourself.

5-Year Outlook#

Browserbase: likely still here. Well-capitalized, clear position, sound two-tier strategy, and a real technical moat. The risks are venture-shaped (pricing, strategy, acquisition) plus the tier-wide adversarial uncertainty.

Steel: likely still here as open source, with its hosted business dependent on the same arms race. The self-hosted path persists regardless, which is a genuine durability property for regulated buyers.

The tier as a whole: exists as long as (a) browsers are expensive to run at scale and (b) sites resist automation. (a) is permanent. (b) is the uncertainty.

What would falsify a positive outlook: a durable shift in favour of detection; legal enforcement against automated access; or hyperscalers commoditizing managed browser infrastructure, which would compress margins toward hosting rates.

What would strengthen it: continued growth in agent workloads, which drives demand for concurrency independent of the adversarial question.

Organizational Fit#

Best for: high-volume open-web automation (persona 3), where both concurrency and network identity are genuinely binding.

Steel self-hosted specifically for: regulated teams (persona 4) — and note the fortunate alignment that their internal targets have no bot detection, so the missing anti-bot layer costs them nothing.

Not needed by: personas 1, 2, and 5 in most cases. Playwright launches a browser; CI runners run browsers. Most readers do not need this tier, and adopting it before concurrency or blocking becomes a real problem is buying infrastructure for a workload that doesn’t exist.

Strategic Paths#

Conservative: Steel, self-hosted where policy requires it; Browserbase where managed is acceptable and the adversarial exposure is understood and documented. Conservative buyers should specifically avoid depending on anti-bot capability — an automation whose viability rests on winning an arms race is not a conservative architecture, whatever the vendor’s current success rate.

Performance-First: Browserbase for managed capability and session replay, which is the category’s best answer to debugging non-deterministic agents at scale. Remember from S2 that browser-hours bill during model latency — the fastest framework is also the cheapest runtime bill, and the two compound.

Adaptive: Steel, for the self-hosting option even if you don’t exercise it. Keeping the ability to move off a hosted runtime is cheap insurance in a tier whose long-term economics depend on an arms race nobody can call.

Tier 3 — MCP Servers, Strategic Viability#

Verified: 2026-08-05

Position#

Two first-party servers from the two companies that build browsers and developer tooling:

Chrome DevTools MCP is the second-most-adopted project in this survey — ahead of Stagehand and Skyvern combined, despite not being an agent.

Business Model Durability — A Different Question Entirely#

Neither of these is a business. Both are developer-relations investments by companies whose actual products are elsewhere.

That is the most important strategic fact about tier 3, and it changes every part of the assessment.

Why they exist:

• Google benefits when developers build against Chrome and when Chrome DevTools remains the reference debugging environment. An MCP server that makes Chrome the browser AI agents can see into is straightforwardly strategic for the platform.
• Microsoft benefits when Playwright remains the default cross-browser automation framework, and when Azure and GitHub’s AI tooling has strong browser capabilities.

Why this is a strong durability signal:

• Marginal cost is near zero. Both are thin layers over protocols and engines the companies already maintain for other reasons. Neither needs to justify its own P&L.
• No conversion pressure. There is no free tier to erode, no enterprise edition to gate features into, no license boundary to dispute. Apache-2.0 throughout, permanently.
• Strategic alignment is stable. Both companies’ interests in browser-platform relevance are long-term and structural, not tied to a funding round.

Compare directly to tier 2: browser-use must eventually convert its 108k stars into revenue; Stagehand exists to sell a runtime; Skyvern trades reach for AGPL defensibility. Tier 3 has none of these pressures. This is the most commercially insulated tier in the survey.

The counterweight: developer-relations investments can be cut, and platform strategies change. Neither company owes anyone continuity. But the pattern for first-party developer tooling of this kind — Playwright itself, DevTools itself — has been sustained investment over many years.

Governance Risk#

Lowest in the survey on licensing. Apache-2.0 for both, first-party, no dual licensing, no carve-outs, no ambiguity. A legal review is one sentence and produces no findings — the same advantage 1.215 identified for Bifrost, and for the same reason.

Vendor risk is minimal but not zero. Both are backed by companies that will exist. The risk is deprioritization rather than disappearance, and Apache-2.0 means a fork is always available — though forking a thin layer over the Chrome DevTools Protocol is only as useful as your access to that protocol, which Google controls.

The Chrome-only constraint is a strategic dependency worth naming. Chrome DevTools MCP’s capability is coupled to Chrome’s protocol. Google controls that protocol, its evolution, and what it exposes. That is a soft form of platform dependency that Apache-2.0 does not mitigate.

Exit Cost#

The lowest in the survey, essentially by construction.

Ports trivially: MCP is a protocol (2.074). Servers are interchangeable at the protocol level, and the harness driving them is yours. Switching is a configuration change.

Accumulates nothing: no state, no proprietary formats, no cached artifacts, no infrastructure. Uninstalling is deleting a config entry.

This is the strongest adaptive position in the survey. Adopting tier 3 forecloses almost nothing, which is exactly what you want from a capability you’re adding to an existing harness.

5-Year Outlook#

The most durable options in the survey. First-party, permissively licensed, near-zero marginal cost, strategically aligned with their vendors’ long-term platform interests, and no monetization pressure to distort them.

Tier 3’s exposure to the category-level risks is also the mildest:

• Computer-use models: tier 3 benefits rather than suffers. Better models make the harness driving these tools more capable. The server is plumbing; improved intelligence upstream improves outcomes with no change to the plumbing. Tier 3 is the one part of this category that gets better as models improve.
• Prompt injection: tier 3 carries the largest blast radius (the harness usually holds filesystem and shell tools), which is a genuine and serious counterweight. This is where tier 3 is most exposed.
• Adversarial arms race: essentially not applicable. These aren’t fighting bot detection.

What would falsify a positive outlook: either project going quiet for several quarters, Google restricting DevTools Protocol access, or MCP itself being displaced by a competing protocol (see 2.074).

What would strengthen it: MCP standardization deepening, and the harness population (1.212) continuing to grow — which drives tier 3 adoption directly.

The Strategic Observation#

Chrome DevTools MCP at 48.6k stars is the most interesting data point in this survey.

A tool surface with no agent in it has out-adopted every purpose-built browser agent framework except one. The explanation from S2 and S3 is that its addressable population — developers who already run an AI coding agent and want it to see the browser — is far larger than the population building browser automation.

The strategic implication for the category: tier 2’s addressable market may be smaller than its marketing assumes, because a large share of people who think they need a browser agent framework actually need to give an existing agent browser access.

That does not make tier 2 obsolete — S2 established tier 3 doesn’t do unattended production work — but it does mean the category’s growth may accrue disproportionately to the tier with no business model behind it. Free, first-party, permissively licensed infrastructure absorbing the largest segment is a difficult competitive environment for tier 2 vendors.

Organizational Fit#

Best for: anyone already running an MCP-capable harness who needs interactive browser capability. Personas 1 and 5.

Poor for: unattended production automation. Tier 3 gives a capability, not a program.

Requires: a harness. Without one, tier 3 is half a solution.

Strategic Paths#

Conservative: Strongest fit in the survey. Apache-2.0, first-party, zero infrastructure, zero exit cost, no commercial pressure. The one serious conservative caution is the security blast radius — dedicated browser profiles and scoped credentials are mandatory, not advisory, because the harness usually holds far more than a browser.

Performance-First: Chrome DevTools MCP’s 61 tools include capabilities — performance tracing, Lighthouse, heap snapshots — that no other option in the survey offers at all. For debugging and profiling work this is not merely the best option, it is the only one.

Adaptive: The best adaptive position available. Protocol-portable, stateless, no lock-in, and it improves automatically as the models driving it improve. Install both, let the agent choose, and lose nothing if the category shifts underneath you.

S4 Recommendation — Strategic Verdict#

Date: 2026-08-05

There Is No Category Winner, and Barely a Category Contest#

The options here mostly occupy different tiers and stack rather than substitute. The strategic question is not “which tool survives” but “which tiers will still be worth having, and what happens to each if the models get much better.”

The Seven Durable Findings#

1. The boundary test is “who decides the next action”#

You (tier 1 → 1.118), an LLM in the tool’s loop (tier 2), an LLM in your harness (tier 3), or nobody (tier 4). This survives product churn and explains why the tiers stack.

2. The second-largest project in the category is not an agent#

Chrome DevTools MCP: 48.6k stars — ahead of Stagehand and Skyvern combined. Its addressable population (developers who already run a coding agent) dwarfs the population building browser automation.

The strategic implication: the category’s growth may accrue disproportionately to the tier with no business model behind it — free, first-party, Apache-2.0 infrastructure from Google and Microsoft with near-zero marginal cost and no conversion pressure. That is a difficult competitive environment for tier 2 vendors.

And readers should evaluate tier 3 first, which inverts how every published comparison frames the decision.

3. Published benchmark numbers in this category are not comparable#

Three benchmarks measuring different things — WebVoyager (643 tasks, 15 friendly sites), WebBench (5,750 tasks, 452 sites, scores infrastructure too, authored by Skyvern), Odysseys (200 long-horizon live tasks, rubric-graded).

browser-use’s 87.4% (Odysseys) and Skyvern’s 64.4% (WebBench) cannot be subtracted. And the figures circulating in secondary sources — “89.1% WebVoyager,” “85.85% WebVoyager” — appear in neither project’s primary materials. Numbers are being copied between articles with the wrong benchmark names attached.

Benchmark scores indicate what a tool is shaped for, never which is better. Test on your own sites.

4. Deterministic steps are the only real mitigation for three separate problems#

Stagehand’s cost dial is simultaneously a security dial and a compliance dial:

• Cost: a deterministic step makes no LLM call and occupies no billed browser-hour
• Security: text on a page cannot influence page.click('#submit') — it is not model-mediated, so it cannot be prompt-injected
• Compliance: page content in a deterministic step is never transmitted to a model provider

Nobody markets this, including Stagehand. It is the most under-recognized finding in the survey, and it is model-independent — better models never make a call cheaper than not making one.

5. Prompt injection is documented in production and treated as fundamental#

Unit 42 documented the first real-world case in December 2025; Google observed a 32% relative increase Nov 2025–Feb 2026; researchers treat it as architectural rather than a patchable bug.

No tool choice mitigates it. Tier 3 carries the largest blast radius — the harness usually holds shell and filesystem tools too.

The strategic consequence is a ceiling on addressable market: a category whose safe envelope is “attended, or against trusted sites, with scoped credentials” is meaningfully smaller than the demos imply.

6. Agent latency is billed twice#

Runtimes charge by wall-clock browser-hour; the browser bills while the model thinks. So a slow framework costs more in inference and more in browser-hours — they compound rather than trade off. The hybrid saving is roughly double what a framework-only comparison suggests, and because the effect spans two vendors, neither pricing page shows it.

7. Where the page content goes is the question nobody asks#

Every observe step transmits what’s on screen to a model provider. For regulated workloads that content is the regulated data itself. No vendor material in this category discusses it. This makes 1.215’s proxy layer near-mandatory for sensitive workloads, paired with 1.209 where policy demands fully-local inference.

The Category’s Central Uncertainty#

Will computer-use models absorb tier 2?

Current evidence says the gap is real — DOM-driven stacks lead vision approaches by 12–17 points on common tasks, because DOM skips an error-prone localization stage. But that is a model-capability gap, and those close.

The likely outcome: computer-use models compress tier 2’s perception value and leave its orchestration value intact. Frameworks get thinner, not obsolete.

Exposure by option:

Tier 3 is the one part of this category that gets better as models improve.

Strategic Paths#

Conservative — minimize the risk of being stranded#

Tier 3 (Chrome DevTools MCP + Playwright MCP) is the strongest conservative position in the survey: Apache-2.0, first-party Google and Microsoft, zero infrastructure, zero exit cost, no commercial pressure to distort the roadmap. Mandatory caveat: dedicated browser profiles and scoped credentials. The blast radius here is the largest in the survey.

Tier 2: Stagehand. MIT, no license ambiguity, incremental adoption from existing Playwright, deterministic steps are auditable and injection-proof, and its differentiation survives model improvement.

Tier 4: Steel self-hosted where policy requires; Browserbase where managed is acceptable. Avoid depending on anti-bot capability — an automation whose viability rests on winning an arms race is not a conservative architecture.

Avoid: Skyvern under a conservative posture — AGPL is a procurement finding, the fork escape is degraded by the proprietary anti-bot split, and it is the most exposed to the category’s central uncertainty.

Performance-First — best capability today#

browser-use for long-horizon autonomy: 87.4% on Odysseys is the best published result in the survey for that class of work. Budget for it — agent-first is the most expensive architecture, and context growth makes long tasks superlinearly costly. Pair with an LLM router (1.215).

Stagehand for cost-performance, remembering the saving is roughly double the naive estimate.

Chrome DevTools MCP for debugging and profiling — 61 tools including performance traces, Lighthouse, and heap snapshots that no other option offers at all.

Skyvern only where vision is genuinely required — canvas, image-based layouts, no useful DOM. A targeted choice, never a default.

Adaptive — maximize the ability to change course#

Tier 3 is the best adaptive position available. Protocol-portable, stateless, no accumulated state, uninstalling is deleting a config entry — and it improves automatically as models improve.

browser-use for tier 2: lowest lock-in, model-agnostic, MIT.

Steel for tier 4, for the self-hosting option even if unexercised.

Avoid: Skyvern (AGPL constrains what you build around it, and the cloud’s anti-bot layer is lock-in that isn’t in the code), and heavy investment in Stagehand’s hybrid partition if you expect your site set to change from known to unknown.

Risk Summary#

The Posture That Serves Every Reader#

Check for an API first. One hour, routinely skipped, and it can save a project.

Check whether your existing harness can just be given browser access. For the largest population in this category, tier 3 is the whole answer and tier 2 is machinery they don’t need.

Distinguish reading from acting. Read-only work belongs to crawlers — cheaper, faster, deterministic. Browser agents earn their cost on write workloads.

Maximize deterministic steps wherever the flow is known. They are simultaneously cheaper, unbillable in browser-hours, injection-proof, and never transmit page content to a model provider. Four benefits, one decision.

Isolate credentials and use dedicated browser profiles. Not advisory. Prompt injection is documented in production and unsolved, and this is the control that bounds the damage.

Keep the regression suite deterministic. Agents help you author and diagnose tests; they cannot do a test’s job.

Test on your own sites. Every published number in this category was measured on a different corpus by an interested party.

Refresh Guidance#

decay_class: fast. Re-verify at every cycle:

1. Computer-use model scores against DOM-driven stacks on the same benchmark — the single highest-value check. If the 12–17 point gap closes, tier 2’s perception value compresses and Skyvern’s position is most affected.
2. Chrome DevTools MCP adoption and tool count — the proxy for whether tier 3 continues absorbing the interactive segment.
3. Benchmark claims against primary sources — this survey found four discrepancies between circulated figures and repositories. Re-check rather than trusting secondary sources.
4. Prompt injection mitigations — if anyone credibly closes this, the category’s ceiling moves. Current consensus says fundamental.
5. Stagehand’s Python implementation parity — determines whether it reaches the Python majority of AI engineering.
6. Skyvern’s licensing posture — AGPL is the gating fact; any change would materially widen its addressable market.
7. Star counts, funding, pricing — all move monthly in this category.

Skyvern — Strategic Viability#

Verified: 2026-08-05

Position#

22.7k stars, 6,356 commits, AGPL-3.0 with proprietary anti-bot measures reserved to the managed cloud. Python, vision-driven, focused on transactional WRITE workflows.

Level with Stagehand on stars, well ahead on commits — substantial sustained engineering. Also the author of WebBench, the most rigorously designed benchmark in the category.

Business Model Durability#

Classic AGPL open-core, and it is coherently constructed.

Why the structure works commercially:

• AGPL deters competitors from hosting it. That is precisely what AGPL is for, and it protects the cloud business from a hyperscaler wrapping the project as a service.
• The proprietary anti-bot split is the real moat, and it is smarter than the license. Self-hosted Skyvern gets you the agent; it does not get you past Cloudflare. For the hostile-site workloads Skyvern targets, the free version is functionally weaker in exactly the dimension that matters most. That converts far more reliably than a feature gate would.
• WebBench is strategic infrastructure. Authoring the category’s most rigorous benchmark — one that scores infrastructure alongside agent reasoning — establishes thought leadership and defines the evaluation axis on which Skyvern’s architecture looks strongest. Entirely legitimate, and it should be read as positioning.

The commercial risk: AGPL narrows the top of the funnel severely. Many enterprises prohibit AGPL by automated policy, so a large share of the potential audience never evaluates the product at all. The company trades reach for defensibility, which is a deliberate bet and a real constraint on growth.

Governance Risk#

Highest licensing friction in the survey; moderate vendor concentration.

The AGPL assessment, stated plainly: this is not a risk that the license might change — it is the risk that the license already excludes you. Automated dependency scanning with blanket copyleft prohibition is common, and it returns a no before anyone evaluates merit. For a large fraction of commercial buyers this is decisive and permanent.

Fork viability is technically real and practically limited. AGPL guarantees the code stays available, but a fork inherits the AGPL obligations that made it unusable for enterprises in the first place, and it would not inherit the proprietary anti-bot layer. A fork of Skyvern is a meaningfully less capable artifact than a fork of an MIT project — the license protects the code and the moat is outside the code.

Vendor concentration: 6,356 commits indicates genuine engineering, but this is a single-company project without the community breadth that makes browser-use’s 108k stars a durability mechanism.

Exit Cost#

Low, in a way that is slightly ironic.

Ports easily: natural-language task descriptions, like all agent-first frameworks. No proprietary schema or accumulated state.

Doesn’t port: workflow orchestration configuration, and — critically — anything that depended on the cloud’s anti-bot capability. A team that succeeded against defended sites using Skyvern Cloud cannot replicate that with a self-hosted alternative, because the capability was never in the open code.

The asymmetry: leaving Skyvern for another agent framework is easy. Leaving Skyvern Cloud for anything self-hosted means losing access to sites you could previously reach. That is real lock-in, and it sits in the proprietary layer rather than in the software.

5-Year Outlook — The Most Exposed Option in the Survey#

Skyvern faces the category’s central strategic risk more directly than anything else here.

approach.md assessed that computer-use models likely compress tier 2’s perception value while leaving orchestration value intact.

Skyvern’s differentiation is perception. Vision-driven interaction is the product’s defining characteristic and its stated rationale. If frontier models become natively excellent at operating browsers from screenshots — which is exactly what computer-use models are trained to do — then the thing Skyvern built is the thing the model now does.

The current gap protects it: DOM-driven stacks lead vision approaches by 12–17 points on common tasks, and S2 identified the mechanical reason (DOM skips an error-prone localization stage). But that is a model-capability gap, and those close.

What survives even if the gap closes:

• Workflow orchestration — retries, multi-step structure, scheduling. Model-independent.
• The anti-bot layer — proprietary, adversarial, and genuinely hard. This may be the more durable asset, and it is notably not the thing the product is marketed on.
• WRITE-task specialization — form-filling reliability is partly domain engineering, not raw perception.

The strategic read: Skyvern’s most durable asset is probably its proprietary anti-bot capability rather than its vision architecture — which would make it, in five years, more of a tier-4-adjacent company than a tier-2 framework. That is a viable path and a different company from the one being marketed today.

What would falsify a positive outlook: computer-use models reaching DOM-driven accuracy; AGPL adoption friction proving fatal to growth; or the open core stagnating while the cloud advances.

Organizational Fit#

Best for: transactional WRITE workflows across visually varied sites where DOM parsing genuinely fails — and where AGPL is permitted.

Poor for: anything AGPL-prohibited (a large share of commercial buyers), long-horizon tasks (the vision cost premium compounds badly), and conventional web pages (where DOM approaches are cheaper and more accurate).

Requires: confirming the AGPL policy first. The evaluation order is inverted for this option and every other consideration is downstream of that answer.

Strategic Paths#

Conservative: Weakest fit in the survey. AGPL is a finding in procurement, the fork escape hatch is degraded by the proprietary split, and the architecture is the most exposed to model-capability shifts. Conservative buyers with a genuine vision requirement should consider Skyvern Cloud under commercial terms rather than self-hosting the AGPL core — it resolves the licensing question and is the only version with the anti-bot capability.

Performance-First: Good only where vision is genuinely required — canvas interfaces, image-based layouts, no useful DOM. Elsewhere it is the most expensive perception model in the category with lower accuracy. This is a targeted choice, not a default.

Adaptive: Poor fit. AGPL constrains what you can build around it, the cloud’s anti-bot capability is real lock-in that isn’t in the code, and the architecture is the most exposed to the category’s central uncertainty. An adaptive posture wants optionality, and this option forecloses more of it than any alternative here.

Stagehand — Strategic Viability#

Verified: 2026-08-05

Position#

23.7k stars, 1,415 commits, MIT, TypeScript with an official Python implementation. Published and maintained by Browserbase, Inc. — which is simultaneously tier 4 in this survey.

That dual position is the central strategic fact and cuts both ways.

Business Model Durability — The Two-Tier Strategy#

Stagehand is not Browserbase’s product. It is Browserbase’s funnel.

Browserbase’s revenue comes from the hosted runtime. Stagehand is given away, MIT, fully functional against a local browser, and integrated most smoothly with the paid runtime.

Why this is a strong position for users:

• The framework has no monetization pressure on it. There is no enterprise tier to gate features into, no license boundary to dispute (contrast 1.215’s LiteLLM #34241), and no incentive to cripple the free version. Browserbase makes money when you need scale, not when you need features.
• It is genuinely usable standalone. Running Stagehand against a local browser forever, paying nothing, is a supported path — not a crippled trial.
• S2 assessed this as the cleanest open-core execution across both this survey and 1.215, precisely because the free and paid components sit at different tiers with no boundary to argue about.

Why it is a risk:

• The framework’s continued investment depends on it converting. If Browserbase concludes Stagehand drives insufficient runtime revenue, the rational move is to reduce investment. The framework is a cost centre justified by a funnel hypothesis.
• $67.5M raised at ~$300M valuation requires a growth trajectory. Strategy changes under that pressure are normal, and a funnel is more expendable than a revenue line.
• 1,415 commits is the lowest of the tier-2 primaries — consistent with a younger, more focused codebase built atop Playwright, and also with a smaller engineering allocation than a company’s core product would receive.

The structural comparison worth making: browser-use’s library is the company’s identity; Stagehand’s library is a marketing expense for a different product. Those have different durability profiles under pressure, and it is the same pattern 1.215 found with Bifrost being adjacent to Maxim’s core business.

Governance Risk#

Low on licensing — MIT, no carve-out, no gated features. A fork is legal and viable.

Moderate on strategic alignment. The framework’s roadmap serves Browserbase’s runtime business. Features that drive runtime adoption get built; features that help users avoid needing a runtime are, at best, not prioritized.

This is not a criticism — it is a rational strategy, executed transparently. But a user should understand that the framework’s interests and the vendor’s interests align only up to the point where you’d otherwise buy the runtime.

The Python implementation is the concrete place to watch. An official port exists, and whether it tracks the TypeScript original in features and cadence is a live question. Ports maintained as a secondary priority tend to lag, and the majority of AI engineering happens in Python — so a lagging port would meaningfully narrow the addressable audience.

Exit Cost#

Low to moderate — the highest in tier 2, and still low in absolute terms.

Ports easily: the act()/extract()/observe() primitives map conceptually onto alternatives.

Doesn’t port:

• Deterministic Playwright code — actually this ports better than anything, since it is ordinary Playwright and would survive a move to any Playwright-based tool, or to no tool at all.
• Cached resolved actions — the self-healing cache is Stagehand-specific state and is lost. Not catastrophic; it re-warms.
• The hybrid structure itself — a workflow carefully partitioned into deterministic and AI steps has embedded design decisions that don’t transfer to an agent-first framework. Moving to browser-use means giving up the partition entirely, which is giving up the cost model.

The interesting asymmetry: migrating away from Stagehand to a pure agent framework is easy but expensive (you lose the cost saving). Migrating to Stagehand from existing Playwright is uniquely easy — keep working code, replace only brittle parts. No other option in the survey offers incremental adoption from an existing investment.

5-Year Outlook#

Likely still here, with a caveat about who maintains it.

Browserbase is well-capitalized and Stagehand serves its strategy. The framework is probably maintained for as long as the funnel logic holds.

The strategic advantages that survive category shifts:

• The hybrid cost argument is model-independent. Better models don’t make an LLM call cheaper than not making one. Deterministic steps cost zero and always will. This is the most durable value proposition in tier 2, because it doesn’t depend on any capability gap persisting.
• The security property is also model-independent. Deterministic steps cannot be prompt-injected — and since approach.md assesses injection as fundamental rather than fixable, an architecture that structurally reduces model-mediated steps gets more valuable over time, not less.
• The compliance property likewise. Page content in a deterministic step is never transmitted to a model provider (S3 persona 4).

Against computer-use models specifically, Stagehand is the least exposed option in tier 2. Its differentiation is orchestration and economics, not perception. A model that sees pages perfectly still costs money per call, and Stagehand’s argument is about not making the call.

What would falsify the outlook: Browserbase deprioritizing the framework, the Python implementation stagnating, or an acquisition that changes the funnel logic.

Organizational Fit#

Best for: teams with known target sites (persona 2), regulated teams minimizing model-mediated steps for security and data-flow reasons (persona 4), and teams with existing Playwright investment wanting incremental adoption.

Poor for: unknown long-tail sites, where the deterministic fraction approaches zero and the advantage disappears (persona 3).

Requires: knowing which parts of your workflow are stable. That is the condition the whole value proposition rests on.

Strategic Paths#

Conservative: Strong fit, and arguably the strongest in tier 2. MIT, no license ambiguity, low exit cost, deterministic steps are auditable and injection-proof, and the incremental migration path means you can adopt without abandoning what works. The vendor risk is real but bounded by the license.

Performance-First: Best economics in tier 2 by a wide margin — and note from S2 that the saving is roughly double what a framework comparison suggests, because deterministic steps avoid both inference cost and billed browser-hours. The caveat is that the saving scales with foreknowledge.

Adaptive: Reasonable but not the strongest. The hybrid partition embeds design decisions that don’t transfer, so a workflow heavily invested in the structure is somewhat committed to it. Offset by deterministic Playwright code being the most portable artifact in the survey — it survives leaving the category entirely.