How to Choose a Browser Automation Tool for an AI Agent: Playwright, Puppeteer, Browser Use, or Stagehand

Sooner or later an agent has to use a real website: open a page, sign in, fill a form, read a result, and bring the data back. The library or SDK that drives the browser decides how reliable that work is, how much it costs per run, and how hard a failure is to debug. This guide covers one concrete job, giving an AI agent a browser, and compares the four tools this site has published profiles for in its Browser Automation category: Playwright, Puppeteer, Browser Use, and Stagehand. Every factual claim about a tool below comes from that tool's own checked-in AgentsUse profile, which records its capabilities, limits, pricing model, licence, setup, MCP support, and maintenance signals, last verified on 2026-10-15. Where this guide gives advice, it is labelled as a method you can run yourself, not as a claim about a product.

The short version: choose in six steps

• Step 1: Write the job in one sentence, including the pages involved, the action the agent takes, and the exact output you need back.
• Step 2: Decide who chooses the next click: your code, you step by step with AI help, or a model planning the whole task. This single decision removes at least two of the four tools.
• Step 3: Check the hard constraints: browser engines you must cover, the language your team writes, and whether the work must run locally or can use a hosted browser.
• Step 4: Check how the tool would connect to your agent, directly as a library, or through an MCP server, and which of those paths the project itself documents.
• Step 5: Price a real run, not the licence. All four tools are open source; the costs that differ are model calls, hosted browsers, and the machines you run yourself.
• Step 6: Run the same three small tasks on your own pages with the one or two finalists, score the results the same way, and keep the winner. Do not choose from feature lists alone.

The first decision: who chooses the next click?

The four tools split on one line that matters more than any feature table: how much of the browsing the model decides. At one end, Playwright and Puppeteer execute steps your code specifies. The script says which page to open, which element to act on, and what to read back. Runs are repeatable, failures point at a specific step, and no model is involved in the browsing itself. At the other end, Browser Use takes a task described in plain language, connects a language model, and the agent works out the clicks, typing, and form fills as it goes. In the middle, Stagehand keeps you directing each step, but its act, observe, and extract calls let a model carry out an instruction, find elements, and return structured data inside a flow you wrote.

Neither end is better in the abstract. Deterministic code wins when the same steps must run identically every time, when a result has to be auditable, and when the run happens often enough that model calls would dominate the cost. A model-driven agent wins when pages vary, tasks are described faster than they can be scripted, and a person will review the outcome anyway. The middle wins when you want readable, explicit steps but do not want to hand-maintain every selector or write your own extraction parsing. Most poor choices in this category come from ignoring this line: a team buys an autonomous agent for a fixed regression job, or hand-scripts a brittle flow for a task that changes every week.

The four tools, on the same fields

Each profile in the AgentsUse directory is recorded on the same fields, so the comparison below uses those fields and no others: what the tool is for, what it is not ideal for, which browsers it drives, which languages it ships in, how it connects to agents and MCP, how it is deployed, what it asks of you to get started, and where its own recorded limitations sit.

• Playwright (Microsoft): drives Chromium, Firefox, and WebKit with a single API. Ships a test runner, a CLI aimed at coding agents, and an MCP server. Best recorded fit: teams that need one API across the three engines, with a test runner and an MCP server from the same project. Recorded limit: it gives you the browser driver, not a hosted fleet, proxies, or CAPTCHA handling.
• Puppeteer (Google): a JavaScript library that controls Chrome and Firefox over the DevTools Protocol or WebDriver BiDi. The main package downloads a compatible Chrome; puppeteer-core installs the library only. Best recorded fit: JavaScript teams that want direct Chrome control, screenshots, PDFs, and page automation without a test-runner layer. Recorded limit: no WebKit engine, and no built-in test runner.
• Browser Use: an open-source Python library where an agent completes web tasks described in plain language, such as filling a form or extracting data to a file. You choose the model, register custom tools as Python functions, and run against a local browser, a real Chrome profile, or hosted cloud browsers. Recorded limit: results vary with the model and the site, and it is not ideal where the same steps must run identically every time.
• Stagehand (Browserbase): a browser agent SDK for TypeScript, Python, and Go. Its act call carries out an instruction and self-heals when a site changes, observe returns real selectors for an instruction, and extract returns data validated against a schema you define. It can drive a local browser with a persistent profile, or Browserbase cloud browsers. Recorded limit: it expects you to direct the steps, so it is not built for fully autonomous, open-ended task execution.

Playwright: when the steps must be repeatable

Playwright is a framework for web automation and testing maintained by Microsoft. Its profile records three paths from the same project: Playwright Test for end-to-end checks, a CLI aimed at coding agents, and Playwright MCP, a Model Context Protocol server that gives a model structured accessibility snapshots of a page instead of screenshots, so the agent interacts through element references. Inside the library, the recorded capabilities include resilient locators that find elements by role, label, placeholder, text, or test id, auto-waiting before actions, web-first assertions that retry until conditions are met, network interception, screenshots, and PDF generation. It runs headless by default, supports headed execution and device emulation, and works on Windows, macOS, and Linux. The package is published for JavaScript, and the profile also records Python, .NET, and Java packages.

Choose Playwright when the job is a known flow that must behave the same way on every run: regression checks after a change, a scheduled capture from the same pages, or a scripted flow across more than one browser engine. It is also the natural pick when the same team wants both scripted automation and an MCP path for agent-led investigation, because both come from the one project. The Browser QA Stack on this site is built on exactly that pairing. The costs to accept are operational: you run the browsers yourself, so scaling, proxies, and anti-bot handling are your responsibility, and the MCP server is only as good as the page's accessibility markup, since snapshots are what the agent reads. Setup, from the profile's quick start, is a single install command: npm i playwright, or npm init playwright@latest to start a test project. No account is needed for the library, and Playwright can save and reuse authentication state for pages that need a sign-in.

Puppeteer: when direct Chrome control is the job

Puppeteer is a JavaScript library maintained by the Chrome team at Google. It provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi, and it runs headless by default. Its recorded capabilities cover page navigation and input, screenshots and page capture for scraping and quality assurance workflows, and the two install shapes described above. For agent work, the profile is precise about the MCP route: the project README points readers to chrome-devtools-mcp, a Puppeteer-based MCP server for browser automation and debugging, rather than shipping that server as part of Puppeteer itself. The profile also records experimental WebMCP support as documented by the project.

Choose Puppeteer when your work is JavaScript, your target is Chrome first, and you want direct, low-level control without a test-runner layer deciding how your code is organised. Screenshot and PDF style capture, one-off page automation, and scraping flows you control line by line are its home ground. Do not choose it to cover the Safari engine, because there is no WebKit support, and do not choose it expecting a built-in test runner with assertions and tracing, because its profile names that absence as the point where Playwright is the better fit. Setup is npm i puppeteer; if your package manager blocks the install script that downloads Chrome, the README documents the follow-up command, npx puppeteer browsers install. The library-only route is puppeteer-core, pointed at a browser you manage yourself. No account is needed, and sites you automate handle their own sign-in.

Browser Use: when a model should plan the task

Browser Use is an open-source browser agent for Python. You describe a task in plain language, connect a language model, and the agent opens a browser, reads the page, and carries out clicks, typing, and form fills. Its profile records three paths: a Python library you run yourself, a CLI that gives an existing coding agent browser access, and a fully hosted cloud. Recorded capabilities include task-driven browsing, form filling and data extraction, custom tools registered as Python functions, a choice of model including local models through Ollama per the project docs, reuse of a real Chrome profile for signed-in work, and local or cloud browsers. Python 3.11 or newer is required, installation is uv add browser-use or pip install browser-use, and the run needs a model API key in your environment, with a separate Browser Use key only for its cloud and its own models. The hosted cloud adds managed browsers, stealth features, and recordings.

Choose Browser Use when the tasks vary too much to script: research style browsing across unfamiliar sites, forms whose layout you do not control, or work you can describe in a sentence and review at the end. Its own profile states the trade clearly. It is built for builders who want an agent to handle varied web tasks from a task description, with custom tools and a choice of model, and it is not ideal for repeatable, deterministic automation where the same steps must run identically every time, because direct browser code is easier to audit and cheaper to run. Its recorded limitations add the operating discipline: results vary with the model and the site, long tasks can drift, and a person should review important outcomes. Treat it like a capable delegate, not a cron job: short tasks, a clear output format, and a human check on anything that leaves the browser.

Stagehand: when you direct the steps and want structured data back

Stagehand is an SDK for browser agents from the Browserbase team. It pairs Playwright-style page methods with three AI-assisted calls. Act carries out an instruction, such as clicking a sign-in button, and self-heals when the site changes. Observe finds elements for an instruction and returns real selectors, so values and credentials do not need to pass through the model. Extract returns data validated against a schema you define, using Zod in TypeScript, Pydantic in Python, or Go types. The SDK is published for TypeScript, Python, and Go. It can drive a local browser with a persistent profile, so a signed-in session carries over to the next run, or run on Browserbase cloud browsers. A hosted Browserbase MCP server exposes navigate, act, observe, and extract to MCP clients without a local install, and the project also documents search and fetch helpers that skip the browser when full rendering is not needed. Local runs need Chrome installed and a model API key in your environment; Browserbase runs use a separate Browserbase API key.

Choose Stagehand when the shape of the work is known but the pages are not fully under your control: you can name the steps, you want extraction to arrive as validated structured data rather than free text to parse, and you want the resilience of self-healing actions without handing the whole task to an autonomous agent. Its recorded best fit is developers who want explicit, readable agent steps with self-healing actions and structured extraction. Its recorded limit is the mirror image of Browser Use: it expects you to direct the steps, which is a strength for control and a limit for hands-off work. Budget honestly here too, because act and extract depend on the model you connect, so model calls are a per-run cost, and extracted data still needs review before you act on it. Setup, from the profile, is pnpm add @browserbasehq/stagehand zod in TypeScript, or pip install stagehand in Python.

Engines, languages, and deployment: the hard constraints

After the control decision, three constraints settle most remaining ties, and each is a recorded field rather than an opinion. Browser engines: only Playwright covers Chromium, Firefox, and WebKit together. Puppeteer covers Chrome and Firefox. Stagehand drives local Chrome or Browserbase cloud browsers. Browser Use runs against a local browser, a real Chrome profile, or its hosted cloud browsers. If your users include Safari, or your checks must prove a flow works in the WebKit engine, the shortlist is already one tool long. Language: Puppeteer is a JavaScript library. Browser Use is Python. Stagehand ships TypeScript, Python, and Go SDKs. Playwright records npm packages plus Python, .NET, and Java. A team should not adopt a new language stack to drive a browser if an equal tool exists in the stack it already maintains.

Deployment decides who operates the browser fleet. Playwright and Puppeteer are self-hosted libraries: you run the browsers, on your machine or your infrastructure. Browser Use and Stagehand both offer the same fork in the road, a self-hosted library by default, with an optional hosted cloud from the same project. Hosted browsers remove local setup and machine limits, and they turn browser operation into a paid service with its own account and key. Local runs keep the work on your own machine, keep sign-in profiles under your control, and make you responsible for capacity and updates. Neither is the responsible choice by default. Match it to the data involved: a workflow that browses signed-in internal pages argues for local control, while a public-page capture job that must scale argues for evaluating the hosted path on its own terms.

How each tool reaches an agent: the MCP paths

If the browser is for an agent you already run, the connection path matters as much as the library. The four profiles record four different shapes, and the differences are the point. Playwright ships its own MCP server, the @playwright/mcp package, giving MCP clients browser control through accessibility snapshots; its profile marks that support as checked against the project README. Puppeteer's MCP route goes through a separate project, chrome-devtools-mcp, which its README points to. Browser Use documents MCP use in its project docs, and its profile lists that as a documented path, not a locally tested one. Stagehand's MCP route is hosted: Browserbase documents a hosted MCP server with navigate, act, observe, and extract tools, which AgentsUse has not locally tested.

Read those labels the way this site intends them. A shipped, first-party server, a linked separate project, a documented path, and a hosted endpoint are four different levels of integration work and operational dependence. None of them is a reason to reject a tool, but they belong in the trial: connect the browser to your actual agent host, run one small task through that connection, and confirm the tool list and the results look the way the profile describes before the tool becomes part of real work. The companion guide on what MCP is covers the host, client, and server model behind these connections, and the guide on diagnosing tool-call failures covers what to do when a connected browser tool stops working mid-run.

What a run actually costs

All four profiles record an open-source pricing model, so licence cost does not separate them: Playwright and Puppeteer are open source under Apache-2.0, and Browser Use and Stagehand are open source under MIT. The separating costs sit one layer down, and each profile names its own. With Playwright, the library, test runner, CLI, and MCP server are free to use, and browser infrastructure and any model calls are separate costs you arrange yourself. With Puppeteer, you provide the machine, the browser, and any infrastructure around it. With Browser Use, the library is free, and model inference and the optional hosted cloud browsers are paid separately. With Stagehand, the SDK is open source, local runs need Chrome installed, and Browserbase cloud browsers and the hosted MCP server are a separate hosted service.

That produces a simple budgeting rule for this category. If no model is in the browsing loop, as with scripted Playwright or Puppeteer work, your cost is machines and time. If a model is in the loop, as with Browser Use tasks or Stagehand act and extract calls, every run spends model tokens, so cost scales with task length and page count, and a workflow that looks cheap in a demo can become the expensive option at volume. Before you commit, count the cost of one real run end to end, then multiply by the number of runs in a normal week. Both Browser Use and Stagehand state this in their own limitations, in almost the same words: budget per task, or per run, before scaling up.

Maintenance signals, read correctly

Each profile records dated health fields from the project's repository and package pages, checked on 2026-10-15, and each profile carries the same warning: these are maintenance signals only, not a quality rating. Read them that way. On that date, the recorded GitHub figures were 97,789 stars and 6,620 forks for Playwright, 95,699 stars and 9,591 forks for Puppeteer, 118,089 stars and 13,094 forks for Browser Use, and 25,686 stars and 1,756 forks for Stagehand. Playwright's profile also recorded version 1.64.1 and a weekly downloads figure for the npm playwright package. What these numbers can honestly tell you is that all four projects are active, public, and widely watched, and that Stagehand is the smaller project of the four, which its own alternatives notes also reflect. What they cannot tell you is which tool will succeed on your pages. Stars measure attention, not fit, and no profile in this category publishes an independently checked benchmark, a limit every one of the four profiles states about itself.

The three-task trial that settles it

Because no honest benchmark for your pages exists in the directory data, run your own. This is a method, not a product claim, and it takes an afternoon. Pick the one or two finalists left after the control, engine, language, and deployment checks, install each from its profile's quick start, and run the same three tasks on pages you actually care about.

• Task one, read: open a representative public page and return three specific facts from it as structured output. This tests navigation, page reading, and whether the output shape is something your workflow can consume without cleanup.
• Task two, act: complete one short form or multi-click flow on a test page or a harmless live page, and return proof of what was submitted. This tests element finding, waiting, and behaviour when a page loads slowly or changes layout.
• Task three, repeat: run task one or two five times in a row, unchanged. This is the determinism and drift test. Scripted tools should produce the same result every time; model-driven tools should be scored on how often the result is right, not on whether one run impressed you.

Score every run on the same four lines: did it finish, was the output correct against the page, how long did it take, and what did it cost in model calls or hosted usage where those apply. Add a fifth line for failure quality: when a run fails, can you tell which step failed and why, from a trace, a script line, or a run record? A tool that fails clearly is worth more in production than a tool that succeeds opaquely, because the second kind fails eventually too, and gives you nothing to fix. Keep the scoring sheet. It becomes the evidence for the choice, and the baseline you re-check when a site redesign or a model change alters the results.

Matching the tool to the job: four worked decisions

• Regression checks on a web app after every change: Playwright. The job needs identical steps, pass or fail output, and coverage across engines. Its test runner, auto-waiting, and assertions are recorded for exactly this, and the Browser QA Stack shows the pattern, including using the Playwright MCP server to investigate a failure instead of guessing at it.
• Screenshots, PDFs, and page capture inside a JavaScript codebase: Puppeteer. The job needs direct Chrome control and capture, not a test framework or a planning model. Its profile records page capture as a core capability and the bundled Chrome download as the setup path.
• Varied research and form tasks across sites you do not control, described in plain language: Browser Use. The job changes too often to script, the team works in Python, and a person reviews the output. Accept model cost per task and variance between runs as the recorded price of that flexibility.
• A known workflow that pulls structured records out of pages whose markup shifts: Stagehand. The job needs explicit steps you can read, extraction validated against a schema, and actions that self-heal when a site changes, without handing planning for the whole task to a model.

Notice what none of these decisions required: a ranking, a star count, or a claim that one tool is best overall. Each decision followed from the job sentence, the control model, and one or two recorded constraints. That is the honest shape of this category. The four tools overlap enough to look interchangeable in a feature list, and differ enough, in who decides, which engines, which language, and who runs the browsers, that the right choice is usually forced once the job is stated precisely.

Limits every buyer in this category should keep

• No independently checked benchmark is published for any of these four tools on this site. Vendor and project claims about speed or success rates are recorded as claims, not as AgentsUse results, so your three-task trial is the only benchmark that describes your pages.
• A browser driver is not browser infrastructure. Scaling, proxies, and anti-bot handling sit outside Playwright's recorded scope, and the same caution applies whenever a library profile describes a driver or an SDK rather than a hosted fleet.
• Model-driven browsing varies. Browser Use records that results vary with the model and the site and that long tasks can drift; Stagehand records that act and extract depend on the model you connect. Review extracted data and important outcomes before acting on them.
• Accessibility markup is an input, not a detail. Playwright's MCP server returns accessibility snapshots, so pages with poor accessibility markup give the agent less to work with, whichever host drives it.
• Sign-in help is state reuse, not credential handling. Saving authentication state, keeping a persistent local profile, or reusing a real Chrome profile keeps a session alive between runs. It does not make handing an agent your credentials a safe default, and the tool permissions guides on this site cover the discipline for that decision.

Sources and how this guide was built

This guide was built only from the AgentsUse directory's own checked-in data: the published profiles for Playwright, Puppeteer, Browser Use, and Stagehand in src/lib/tools-data.ts, each recorded as source-verified and last verified on 2026-10-15, the Browser Automation category record in the same file, and the published Browser QA Stack in src/lib/stacks-data.ts. Capabilities, limits, licences, setup commands, environment variables, MCP support, and maintenance figures are quoted or paraphrased from those records, including each profile's own statement that no independently checked benchmark is published for it yet. No capability, price, rating, or count appears here that is not in those records. Prices for hosted services and models change, and the profiles deliberately point to the projects' own documentation for current hosted pricing rather than recording figures that would go stale. If a profile is updated after this guide, the profile governs.