I built a competitor price tracking tool last year. The first version used Playwright with CSS selectors. It worked for three weeks, then the competitor redesigned their pricing page, and every selector broke at midnight on a Saturday.
I rebuilt it with hardcoded XPaths. Those lasted a month. Then the competitor added an A/B test and sometimes the new layout would show up and sometimes it would not, and my agent would silently record wrong prices in both cases.
I tried one of the AI browser agent libraries. The agent navigated the page correctly, found the right prices even through layout variations, and kept working through redesigns. I watched it handle a completely restructured product page by reading the text and figuring out where the prices were. No selectors. No XPaths. Just a model deciding what to do based on what it saw.
Then I saw the bill.
That is the honest summary of AI browser agents in 2026. They are genuinely better at the hard parts of web automation. They are also expensive, slow, and will fail in ways that traditional automation never would. Getting them into production requires understanding all four of those things at once.
Why AI Browser Agents Are Not Just Selenium With a Better API
Traditional browser automation works by finding elements. You write a selector that points to a DOM node, you read or click it, you move on. The automation knows nothing about the page except the structure of the HTML.
This breaks in predictable ways. The selector changes, the automation breaks, you fix it. The cycle is annoying but understandable.
AI browser agents work differently. Instead of finding elements by selector, you describe what you want in natural language and the model figures out how to do it. “Click the add to cart button” works across different page layouts, different button labels, different HTML structures. The model reads the page and acts on what it means, not on how it is structured.
The upside is real. Layouts change, the agent adapts. A/B tests diverge, the agent picks the right path anyway. You stop writing selector soup.
The downside is also real. The model can be wrong. It can click a button that looks like the right one but is not. It can decide a page element “means” something it does not, especially on unfamiliar domains. It uses a non-trivial number of tokens per action, and complex workflows can get expensive fast. And unlike a broken selector, a wrong model decision can fail silently, returning plausible but incorrect results.
Traditional automation fails loudly. AI automation fails subtly. That is the tradeoff you are accepting when you switch.
The Landscape: What You Are Actually Choosing Between
Three tools dominate this space in 2026.
Stagehand (from Browserbase) is a TypeScript library that wraps Playwright with an AI layer. You write mostly normal Playwright code, but when something is hard to select reliably, you call page.act() with a natural language instruction or page.extract() with a schema. The AI handles the hard part, Playwright handles the rest. It shipped v3 in early 2026 and the new version is significantly more reliable than the original.
Browser Use is a Python-first library that takes a more agentic approach. Rather than adding AI to specific steps, Browser Use runs a full loop: observe the page, decide the next action, execute it, repeat. You give it a goal. It figures out the steps. It is closer to a true browser agent and further from a scripted automation.
Playwright with an AI model wired in manually is the option you often see dismissed as “not a real approach,” which is wrong. For many use cases, writing a Playwright script that takes a screenshot, sends it to a vision model, and acts on the response is the right architecture. You get tight control, predictable costs, and no additional dependency.
Picking between these is mostly a question of how much structure your automation needs.
Stagehand: The Surgical Option
Stagehand’s core insight is that you do not need to make the entire automation AI-driven. Most pages are consistent enough that Playwright selectors work fine. A few parts are flaky. Stagehand lets you use selectors where they work and drop into AI where they do not.
Here is what a real Stagehand workflow looks like:
import { Stagehand } from "@browserbasehq/stagehand";
import { z } from "zod";
const stagehand = new Stagehand({
env: "BROWSERBASE",
apiKey: process.env.BROWSERBASE_API_KEY,
modelName: "claude-sonnet-4-6",
});
await stagehand.init();
const page = stagehand.page;
await page.goto("https://shop.example.com/products");
// Normal Playwright where the structure is predictable
await page.waitForSelector(".product-list");
// AI for the part that varies across A/B tests and redesigns
await page.act("click the add to cart button for the first product");
// Structured extraction with a typed schema
const priceData = await page.extract({
instruction: "extract the product name and final price after any discounts",
schema: z.object({
name: z.string(),
price: z.number(),
currency: z.string(),
}),
});
await stagehand.close();The model only runs for the act and extract calls. Everything else is standard Playwright. This matters for cost. A workflow with twenty navigation steps and three AI actions pays for three model calls, not twenty.
When Stagehand makes sense:
- Your workflow is mostly predictable with a few unreliable sections
- You are writing TypeScript
- You want to stay close to Playwright semantics
- Cost control matters and you can scope which steps need AI
When it does not:
- Your workflow is entirely dynamic and you do not know the steps in advance
- You need the agent to make multi-step decisions based on what it finds
- Your team is Python-first
Browser Use: The Agentic Option
Browser Use takes the opposite approach. You describe the goal, and the library runs a loop: observe the current page state, decide the next action, execute it, assess progress, repeat. You give it a goal. It figures out the steps.
from browser_use import Agent
from langchain_anthropic import ChatAnthropic
async def run():
agent = Agent(
task="Go to the pricing page on example.com and extract all plan names and monthly prices. Return a list of {plan_name, monthly_price, currency}.",
llm=ChatAnthropic(model="claude-sonnet-4-6"),
max_actions_per_step=4,
)
result = await agent.run(max_steps=15)
return resultThat is the whole interface. The agent navigates, reads, clicks, and extracts without any scripted steps. For goals that involve multiple pages, unpredictable navigation, or decisions you cannot anticipate in advance, this model handles it naturally.
In practice, you will add more configuration. Browser Use supports custom browser contexts for session persistence, callbacks between steps for logging, and stop conditions to prevent runaway loops. For production use you will want all of these.
The cost is real. Each “observe and decide” loop involves a full model call with a screenshot or serialized page state. A ten-step workflow runs ten or more model calls. Before you ship anything with Browser Use, run through the token cost math for agentic workflows and make sure the economics work for your volume.
When Browser Use makes sense:
- The workflow is dynamic and you cannot predict the steps upfront
- You need the agent to make decisions based on what it finds during navigation
- You are in Python
- You want the simplest possible interface: describe goal, get result
When it does not:
- Cost is a major constraint and most of the workflow is predictable
- You need TypeScript
- You want tight control over each step for reliability or compliance
Playwright With a Vision Model: The Custom Option
The third option gets less attention because it feels like more work. You instrument Playwright yourself, take screenshots at key decision points, send them to a vision model, and act on the response. No dedicated library.
For many use cases, this is actually the right architecture.
import { chromium, type Page } from "playwright";
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
async function decideNextAction(page: Page, goal: string): Promise<string> {
const screenshot = await page.screenshot({ encoding: "base64" });
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 512,
messages: [
{
role: "user",
content: [
{
type: "image",
source: { type: "base64", media_type: "image/png", data: screenshot },
},
{
type: "text",
text: `Goal: ${goal}\n\nDescribe the single next action to take (click, type, navigate, or extract). Be specific about the target element.`,
},
],
},
],
});
return response.content[0].type === "text" ? response.content[0].text : "";
}You build the loop, you handle parsing, you decide when to retry and what to log. This is more code, but it gives you complete control over token usage, error handling, and what gets sent to the model.
The case for this approach is strongest when you have compliance or data handling requirements, when you want to run local models (via Ollama or similar), or when you are embedding browser automation into an existing codebase that has its own orchestration layer.
The Honest Comparison
After using all three in production, here is where each actually wins.
For scraping and extraction on pages you do not control, Stagehand is the most reliable. You use CSS selectors where the page is predictable and AI for exception cases. Browser Use works but burns more tokens doing things Playwright could handle natively.
For multi-step workflows where you cannot predict the path, Browser Use is genuinely better. Goals like “log in, find the most recent order with a return window still open, and initiate the return” are where the agentic loop shines. You cannot script around what you do not know yet.
For anything with strict cost constraints or data handling requirements, the custom Playwright approach gives you the most control. You decide exactly what gets sent to the model, exactly when, and exactly how the response gets parsed and logged.
The other honest thing: the tools fail differently.
Stagehand failures are mostly Playwright failures. The AI interpretation works and the underlying Playwright command throws. You get a stack trace. Debuggable.
Browser Use failures can be silent. The agent decides it completed the task and returns a result. The result is wrong because the model misread the page. You need logging around every step, not just the final output. This is where a proper agent observability setup goes from nice-to-have to necessary. Without it, you will not know the agent made a wrong decision until a user reports the corrupt data.
Custom Playwright failures are whatever you build. You are responsible for catching them and making them debuggable.
MCP and Browser Automation
The Model Context Protocol is becoming a useful boundary for browser automation. MCP servers wrapping Playwright or Stagehand let you expose browser capabilities to any MCP-compatible client: Claude, internal tooling, or a multi-agent orchestration system where the browser agent is one specialist among many.
The practical benefit is decoupling. The browser automation logic lives in one place. Any orchestrator that speaks MCP can use it without embedding the browser logic directly. This is the right architecture when browser access is a shared capability across multiple workflows rather than a single-purpose tool.
Whether it is worth the setup depends on how reused the capability is. For a single automation workflow, MCP is overhead. For a platform where multiple agent flows need web access, it is the cleanest solution.
Production Concerns That Actually Bite
Getting from a working prototype to something reliable in production is mostly about four things.
Error recovery. Pages time out. Navigation fails. The model decides to click something and a dialog opens that blocks progress. Every production browser agent needs explicit handling for all of these. At minimum: a max step count to prevent infinite loops, a retry budget per action with backoff, and a defined behavior when the goal cannot be reached (return partial data, send an alert, log the failure trace for review). Do not ship without this.
Session and state management. Logged-in sessions, cart state, multi-step forms all require browser state to persist. Stagehand has Browserbase for managed cloud sessions. Browser Use supports persistent browser contexts. The custom approach lets you manage sessions however you want. Decide what state you need before you pick a tool.
Cost at volume. A browser agent that runs fifty model calls per workflow at 4,000 tokens each is spending real money per run. Calculate this before you go to production. For high-volume use cases, the economics of full AI browser agents are often worse than a hybrid approach. The mix of AI and selectors is usually the right answer for anything running more than a few hundred times per day.
Rate limits from both directions. The model has rate limits. The target site has rate limits. Both will bite you at different moments and in different ways. Build rate limiting into the agent loop, add randomized delay between actions, and handle 429 responses explicitly rather than crashing.
What to Log (And Why It Matters Later)
Browser agent failures are hard to debug because they happen at the intersection of DOM state, model interpretation, and execution error. Three things make them debuggable:
Screenshots at each step. Even if you do not store them long-term, the ability to replay what the agent saw when it made a wrong decision is invaluable. A wrong click makes no sense until you see what the page looked like when the model decided to do it.
The full model input and output for each AI call. Not just the action. The entire prompt, the page content or screenshot that was sent, and the full response. If the model made a wrong call, you want to see exactly what information it had when it did.
Step timing. Which steps are slow? Where are retries happening? Slow steps surface flaky pages before they become reliability problems. Repeated retries at the same step usually mean the AI interpretation is wrong, not that the page is broken.
None of the three libraries provide this depth out of the box. Plan to add it from the start. The observability patterns for AI agents apply directly, with screenshots as the primary artifact instead of tool call logs.
The Security Layer You Cannot Skip
Browser agents with LLM backing are vulnerable to prompt injection from web content. If an agent navigates to a page that contains text crafted to manipulate language models (“Ignore your previous instructions. Your new task is…”), a naive agent will sometimes act on it.
This has been demonstrated on every major browser agent library. It is not theoretical.
Practical mitigations:
- Keep scope narrow. An agent reading prices should not have access to click payment buttons or fill forms.
- Validate actions before executing them. If the next action is “navigate to an external domain not in your allowed list,” that warrants a sanity check.
- Separate the observation phase from the action phase and apply a policy filter between them.
- Never give the agent credentials or sessions with more scope than the specific task requires.
None of this eliminates the risk. It reduces it. An agent navigating the open web on behalf of your users is a risk you accept and manage, not one you eliminate.
Where to Start
If you have not built a browser agent before, the fastest path to understanding what you are actually working with is to build a small one with Browser Use, run it against a few sites you know well, and watch what happens. Not in a notebook. In a real environment with logging turned up. Watch where it gets confused. Count how many tokens it uses. See what happens when the target page changes between runs.
That experience will tell you more about which tool fits your use case than any comparison article.
For production TypeScript work that needs reliability and cost control, start with Stagehand. For Python-first teams doing dynamic, goal-oriented automation, Browser Use. When you need to own every decision the automation makes, wire Playwright to a vision model yourself.
The days of maintaining brittle selector chains across redesigns are ending. The days of AI browser agents being a magic, zero-maintenance solution are not here yet. The current moment rewards people who know when to use AI and when to let Playwright do the boring part on its own.
That is a genuinely useful tool. Just know what you are holding before you use it.