Giving an AI agent a real browser used to mean one thing: point Playwright at a page and script every click. In 2026 there are three serious, open-source ways to do it — and they disagree, fundamentally, about who holds the wheel.

The one-line pick: Browser Use if you want a Python agent that plans and clicks on its own; Stagehand if you want deterministic TypeScript with AI escape hatches where selectors break; Playwright MCP if you already run an MCP client and just want it to reach the web.

That's the whole decision in a sentence. The rest of this piece is why those three sentences point in different directions, and how to tell which one is describing you.

The axis that actually separates them#

It isn't language, license, or star count — though those matter and we'll get to them. The real split is how much of the driving the model does.

Browser Use hands the wheel to the LLM. Stagehand keeps the wheel in your code and lets the model take over on the corners. Playwright MCP doesn't have a wheel of its own at all — it's a steering column you bolt onto whatever MCP host model you already run. Get that axis right and the rest is detail.

Browser Use: the Python autopilot#

Browser Use is an open-source Python package (MIT-licensed) from Magnus Müller and Gregor Žunič, and it has become one of the fastest-growing AI projects anywhere — north of 100k GitHub stars. You give it a goal in natural language and a model, and it runs an agent loop: capture the page state, send it to the LLM, get back an action, execute it, repeat.

Mechanically, it builds a hybrid representation of the page. It parses the DOM, filters it down to interactive elements, assigns each one a numeric index, and pairs that with a screenshot. The model sees both what a screen reader would announce and what a human would see, then replies with things like "click 5" — and the execution layer maps that index back to the underlying node. It's Playwright underneath, but you never write a Playwright call; you write the goal.

That autonomy is the whole point and the whole risk. Browser Use is the option that will genuinely figure out a multi-step flow you didn't fully spell out. It's also the one most likely to freelance a step you didn't want. It self-hosts for free, and there's a paid Browser Use Cloud if you'd rather not run browsers yourself. Reach for it when the task is "book this, fill that, find me X" and you're comfortable letting the model plan.

Stagehand: code first, AI where it hurts#

Stagehand is Browserbase's open-source framework (MIT), primarily TypeScript with a Python port, built directly on Playwright. Its pitch is the inverse of Browser Use's: you keep writing code, and you sprinkle in AI exactly where hard-coded selectors are brittle.

It gives you four primitives — act() to perform an action, extract() to pull structured data (validated against a Zod schema), observe() to ask what's actionable before you commit, and agent() to hand off a whole multi-step task when you do want autonomy. Because it sits on Playwright's CDP engine, you can drop down to raw Playwright Page objects any time and mix deterministic code with natural-language steps line by line.

That's the sweet spot for production automation where you want repeatability but a selector keeps snapping every time the site ships a redesign. You write the 90% that's stable as normal code and let act("click the checkout button") absorb the 10% that isn't. It runs locally against any Chromium and connects to Browserbase's managed cloud browsers with no code change when you go to production. Choose Stagehand when "flaky selector" is your actual pain and you'd rather not surrender the whole flow to a model.

Playwright MCP: the plug, not the program#

Playwright MCP is different in kind. It's a Microsoft project (Apache-2.0), an MCP server that exposes Playwright to any Model Context Protocol client — Claude, Cursor, VS Code, Goose, and the rest. It ships no agent of its own. The intelligence is whatever host model is already on the other end of the MCP connection; Playwright MCP just gives that model hands.

Its defining choice is representation: it feeds the model the page's accessibility tree as a structured snapshot rather than a screenshot, so the model reasons over real DOM semantics instead of guessing at pixels. That keeps context deterministic and avoids needing a vision-tuned model, though a coordinate-based --caps=vision mode exists when you need it. It self-hosts via npx or Docker; there's no managed cloud offering — this is infrastructure, not a product.

The upside is near-zero new code: if your agent already speaks MCP, you add a server entry and it can browse. The downside is that Playwright MCP is only as good as the host model's tool-calling, and you own the orchestration. Reach for it when the agent already exists and the browser is the missing limb — not when you want a browser agent handed to you whole. For the deeper accessibility-tree-versus-DOM tradeoff, the earlier piece Playwright MCP token cost is the one to read.

How to actually choose#

Start with the wheel question, then let language break the tie.

Two honest caveats before you commit. First, all three re-send page state to the model on every step, and that per-step context — not the browser — is usually the dominant bill; budget for it. Second, none of these is the right tool if the target isn't really a web page: a desktop app, a canvas game, a PDF viewer. That's the boundary where you switch approaches entirely, and it's worth understanding before you build — see computer-use vs browser automation. If your bottleneck is the browser infrastructure itself rather than the agent logic, Lightpanda vs Playwright vs Browserless covers the layer underneath all three.

Pick the control model that matches how much you trust the LLM to freelance. The feature lists will keep converging; the question of who holds the wheel won't.