Updated May 14, 2026.
Browser agents are useful when the browser task needs judgement: pages change, flows branch, the agent has to inspect state, and a human can verify the result. If the task is stable enough for selectors, a Playwright script is usually cheaper, faster, and less weird.
For the concept layer, start with Browser Agents . For adjacent tooling, see Browser Automation: Playwright vs Puppeteer vs browser-use , Playwright MCP , and sandboxing security .
Quick decision
| Use this | When it fits | Do not use it when | Receipt you need |
|---|---|---|---|
| Manual browser work | One-off, ambiguous, high-risk account action | You will repeat it tomorrow | Human note or screenshot |
| Playwright script | Stable UI, known selectors, repeatable test or extraction | The page changes every run | Test trace, screenshot, parsed output |
| Browser agent | Messy UI, branching flow, exploratory task | The action is irreversible or unverified | Step log with URL, observation, final extracted data |
| Playwright MCP | Claude Code needs browser control during a coding/debug loop | A plain script or CLI command is enough | claude mcp get playwright plus a localhost smoke test |
| Hosted browser | Local browser/session/proxy infrastructure is the bottleneck | You only need one simple local run | Session ID, screenshot, provider logs |
The rule: agent for discovery, script for repeatability. Use an AI browser agent to find the path through a messy site; convert the winning path into Playwright when the task becomes routine.
What counts as a browser agent
A browser agent is an LLM loop wrapped around a real browser:
- observe the page,
- decide the next action,
- click/type/scroll/navigate,
- check the result,
- repeat until the task is done or unsafe.
Libraries such as browser-use package that loop for Python workflows. Playwright itself is lower-level automation; the Playwright docs give you deterministic browser control, but not agent judgement. Playwright MCP exposes browser automation to MCP clients, including Claude Code-style workflows.
Use a browser agent when the path is unknown
A browser agent earns its keep when the task is not just “click selector X”.
Good fits:
- exploratory research across several sites,
- admin dashboards with inconsistent labels,
- forms whose next screen depends on previous answers,
- one-off migrations where writing selectors would take longer than the task,
- QA passes where the agent needs to notice visible state, not just a DOM node.
Bad fits:
- nightly scraping from a stable table,
- deterministic E2E tests,
- payment, deletion, posting, invitation, or permission changes without human approval,
- tasks where you cannot define a receipt before running,
- anything involving your primary personal account and broad session cookies.
Use Playwright when the flow is stable
Playwright is the right default when the browser path is known. It is explicit, testable, and easy to run in CI. A browser agent can discover the flow; Playwright should own the flow once you know it.
Use Playwright for:
- repeatable login-and-click tests,
- scraping pages with predictable selectors,
- screenshots after deploys,
- deterministic form filling,
- regression checks where failure should be loud.
The useful hybrid is simple: run an agent once to learn the page, then save the selectors, waits, screenshots, and assertions in a script.
Use Playwright MCP when Claude Code needs a browser
If your coding agent needs to open localhost, test a signup flow, inspect a broken modal, or capture a screenshot while it edits code, use Playwright MCP rather than a separate browser-agent framework.
The current Microsoft README shows the Claude Code install shape as:
claude mcp add playwright npx @playwright/mcp@latest
Then validate it from a trusted project directory:
claude mcp list
claude mcp get playwright
That second step matters. MCP servers are not vibes; they are permissioned tools. If you cannot explain what access the server has, do not let an agent use it. For a broader server shortlist, use best MCP servers by job .
Use a hosted browser when browser infrastructure is the actual problem
Hosted browsers make sense when the hard part is sessions, parallel runs, environment parity, or remote browser infrastructure. Browserbase sits in that bucket.
Do not reach for hosted browsers because the demo looks cooler. Reach for them when local browser management is the thing slowing you down.
Minimal browser-use setup
Use the current browser-use quickstart
as the source of truth. As of this update, the project README shows a uv-based setup for Python 3.11+:
uv init browser-agent-check
cd browser-agent-check
uv add browser-use
uv sync
uvx browser-use install
Keep the first task read-only. For example: “open this public page, summarize the visible pricing tiers, and return URLs plus screenshots.” If that works, then decide whether the next task deserves account access.
Browser task checklist
Before you run an agent, write this down:
- Goal: one sentence, with a stop condition.
- Allowed accounts: test account, read-only account, or no login.
- Forbidden actions: purchase, delete, invite, publish, change permissions, send messages.
- Evidence: URL, screenshot, extracted text, downloaded file, or app state.
- Fallback: what the human or script does if the agent gets stuck.
- Budget: max steps, max retries, max time.
If you cannot fill those bullets, you are not ready to automate the browser. You are just delegating confusion to a very confident raccoon.
Auth and session rules
Browser agents fail dangerously when they inherit too much session state.
Use this policy:
- Start unauthenticated if possible.
- Prefer a disposable test account.
- If a real account is required, scope it to the smallest workspace/project.
- Use read-only access before write access.
- Require human approval for irreversible actions.
- Log out or clear profile state after the run.
For agent safety patterns beyond browsers, see Sandboxing & Security for AI Agents and the agent verification loop .
Receipt log template
Use this table in your run notes:
| Step | URL / app state | Agent action | Evidence captured | Human approval? | Retry/fallback |
|---|---|---|---|---|---|
| 1 | Login page | Opened public page | screenshot + title | not needed | stop if blocked |
| 2 | Dashboard | Read visible status | extracted status text | not needed | manual inspect |
| 3 | Settings | Proposed change only | screenshot before change | required | do not click |
The receipt is the difference between “the agent says it worked” and “we can prove what happened.” Guess which one you want in production. Yeah.
Common failure modes
| Failure | What it looks like | Better move |
|---|---|---|
| Login wall | Agent loops around auth | use test account or stop |
| Captcha / bot check | Browser cannot proceed | human handoff; do not brute-force |
| Layout drift | Clicks wrong label or stale button | switch to Playwright assertions |
| Hidden state | Page looks right but data did not save | verify with a second read or API check |
| Slow JavaScript | Agent acts before state settles | add waits in script or MCP runbook |
| Destructive action | Agent reaches delete/send/pay | require human approval |
| Extraction mismatch | Summary differs from page | capture raw text and URL |
| Token runaway | Agent narrates instead of finishing | cap steps and stop early |
Do not use a browser agent if…
- you already know the selectors,
- a 20-line Playwright script would solve it,
- the task changes money, permissions, production data, or customer-visible content,
- you cannot define the receipt,
- the site actively blocks automation,
- the failure mode is worse than doing it manually.
Browser agents are not magic browsers. They are expensive interns with hands. Give them receipts, sandboxes, and small jobs.
Practical default
For most teams:
- Use manual browser work for the first unknown run.
- Use a browser agent for exploration when the path is messy.
- Save receipts.
- Convert the stable path to Playwright.
- Use Playwright MCP when the coding agent needs to test the app it is editing.
- Add hosted browser infrastructure only when local browsers become the bottleneck.
That sequence keeps the flexibility without letting the tool circus eat the actual work.