Skip to content
Growth Method
Go back

Browser Agents, Explained: The Tools That Click Buttons for You

Stuart Brameld

Stuart Brameld

Founder
Table of contents

This information is correct as of August 2026. Growth Method has made every attempt to ensure the accuracy and reliability of the information provided.

Every marketing team hits the same wall eventually. There is a task that takes four minutes, happens every week, and cannot be automated, because the tool has no API.

Google Search Console’s “Request indexing” button is the classic example. There is no API for it. Brave’s URL submission form is another. So is half of every ad platform’s reporting UI, most legacy CRMs, and every supplier portal your finance team logs into.

Browser agents exist to solve this. They are worth understanding, because most now have a free tier that covers a weekly task outright, and they connect to your existing AI tools through MCP.

What is a browser agent? It is software that drives a real web browser on your behalf, using an AI model to decide what to click, type and read. Unlike a scraper, which fetches raw HTML, a browser agent operates the page the way a person would: logging in, filling forms, navigating multi-step flows and adapting when the layout changes.

What a browser agent actually is

The clearest way to understand the category is by what it replaces.

A scraper fetches a page and parses it. Fast, cheap, and useless the moment the content is behind a login or rendered by JavaScript after three clicks.

Traditional RPA records a fixed sequence of clicks and replays it. Reliable until the site changes a CSS class, at which point it breaks silently and stays broken.

An agentic browser is the consumer version: Perplexity’s Comet, Claude in Chrome, the late ChatGPT Atlas. You watch it work in your own browser window, on your own logins. Useful, but you cannot schedule it, wire it into a pipeline or run it while you sleep.

A scraping API with browser actions sits between the two. You get a scrape endpoint that will click, type and wait before it captures the page. Enough to get past a cookie banner or open a tab, not enough to run a workflow.

A browser agent runs a real browser, usually on someone else’s infrastructure, and puts a model in the loop. It reads the page, decides what to do next, and can recover when the page is not quite what it expected. That flexibility is the whole point, and it is also what makes browser agents slower and more expensive than a scraper.

The category has moved quickly because the constraint was never model quality. As Browserbase founder Paul Klein IV put it in an interview at the AI Engineer World’s Fair:

“We mostly solved accuracy, but speed is still the biggest concern, and I think that will be the next big unlock.”

Paul Klein IV, founder and CEO of Browserbase, interviewed by WorkOS, 5 August 2026

How browser agents work

Under the marketing copy, every one of these products is the same four layers. Knowing them makes the differences between vendors much easier to read.

The browser

A real Chrome or Chromium instance, usually headless, running on someone else’s infrastructure. This is the part vendors call a “cloud browser” or “browser infrastructure”. What varies is cold-start time, how many you can run at once, and where in the world the traffic appears to come from.

The driver

Something has to send commands to that browser. In practice this is always the Chrome DevTools Protocol, usually wrapped in Playwright or Puppeteer. This layer is commoditised, which is why almost every vendor supports the same libraries and why moving between them is less painful than it looks.

The perception layer

This is the first real fork in the road, and it drives both cost and reliability.

Some agents read the accessibility tree: the structured representation browsers already build for screen readers. It is cheap, fast, and needs no vision model. Playwright’s MCP server works this way.

Others read screenshots and reason visually. Slower and pricier, but it copes with canvas elements, unusual widgets and sites that are hostile to structured parsing. Skyvern built its reputation on this approach.

Neither is universally better. Accessibility-tree agents are the sensible default for ordinary business software. Vision agents earn their cost on the weird stuff.

The harness

Everything else: authentication, retries, session persistence, proxy routing, CAPTCHA handling and error recovery. This is unglamorous and it is where nearly all the real differences between vendors live. It is also the layer people underestimate when they try to build this themselves, discover it works in testing, and then watch it fail quietly in week six when a session expires.

The two families

Vendors in this space started from one of two places, and it still shows in what they are good at.

Infrastructure first. Browserbase, Browserless, Steel, Kernel and Cloudflare Browser Run sell you a browser and get out of the way. You bring the logic. They compete on concurrency, cold starts, stealth and price. If you already know exactly what you want to automate, this is the cheaper and more controllable path.

Agent first. Browser Use, Skyvern and Anchor Browser sell you the decision-making too. You describe the task, the model works out the steps. Slower per run and more expensive per task, but you write far less code and it survives site changes better.

The line is blurring in both directions. Browserbase added Stagehand and then Director, which turns a plain-English description into a repeatable automation. Browser Use and Anchor both sell the underlying browser separately. Pick based on which side you want to be responsible for, not on where the vendor started.

Where scraping APIs stop and agents start

You will see scraping APIs advertising browser actions, and it is worth knowing where the line sits. Context.dev, for instance, recently added actions that click, type and wait. Read the reference closely and they run after the page loads and before content is captured, capped at five per request, with no cookie store, session reuse or persistent profile. Logins appear in the documentation only as an error condition, in the field that warns you when you got a login shell instead of the page. That is a scrape with a preamble. Useful for getting past a cookie banner, not something that can log in and do a job.

The line is state. Firecrawl crossed it with its /interact endpoint: actions chain freely inside a session lasting up to ten minutes, and named profiles persist cookies, localStorage and session state between calls. Once a product can hold a login across runs it is competing with the browser agents whether it markets itself that way or not. So the useful test when you evaluate anything here is not “can it click”, it is “can it still be logged in tomorrow”.

How to choose: the six things that matter

Most comparison articles rank these tools on concurrency and price. For a marketing team, those are rarely the deciding factors. These six are.

1. Hosted MCP, or something you have to run

If you want your agent driving the browser from Claude, ChatGPT or your own stack, you want a hosted MCP endpoint: a URL and an API key, no local process to babysit and no server to keep alive.

Browser Use, Browserbase, Anchor Browser and Hyperbrowser all offer one. Check how it authenticates, too: an API key in a URL query string is worse than one in a header, and OAuth is better than both. Watch for two traps. First, some “hosted MCP” options are a third-party wrapper service rather than the vendor’s own endpoint. Second, check what the tools actually do. Cloudflare’s hosted browser MCP sounds ideal until you read the tool list: it fetches HTML, converts to markdown and takes screenshots. It cannot click anything.

2. How authentication is handled

This is the single most important criterion and the one buyers skip. If the task needs a login, the question is not “can it log in”, it is “what happens in week six when the session dies”.

Look for three things: persistent profiles so a human can log in once and agents reuse that state; credential isolation so passwords resolve at typing time and never reach the model, your logs or the API response; and session recovery so an expired login gets repaired rather than silently failing.

Anchor Browser is strongest here and sells authentication as the product. Browser Use is close behind and lets you sync your existing Chrome profile with one command. Browserbase’s Contexts save cookies and session state for reuse. Cloudflare Browser Run has nothing built in at all.

3. How you pay

The split is between prepaid credits with no commitment and monthly subscriptions with included usage. For a task running a few minutes a week, that difference dwarfs any per-hour rate. A 50 dollar monthly minimum on a job that consumes twenty minutes a month is a bad trade no matter how good the product is.

4. Where the traffic comes from

Every browser agent request arrives at the target site from somewhere, and the target site has an opinion about it.

Cloudflare Browser Run is explicit that requests originate from Cloudflare’s network, that you cannot configure IP rotation, that requests carry identifying headers, and that they are always identified as bot traffic. That is fine for your own properties and a problem for anything with serious bot detection. Hyperbrowser and Anchor sell the opposite: residential-style egress, fingerprint randomisation and CAPTCHA handling.

Be honest with yourself about which you need. Most internal marketing automation targets sites you have an account with, where the polite path is fine and evasion is the wrong instinct.

5. Whether it learns or you script it

Some products let you demonstrate a task and replay it. Browser Use’s open-source workflow-use project records your browser interactions once, converts them into a deterministic workflow, extracts variables from forms automatically, and falls back to the LLM agent when a step breaks. Skyvern approaches the same problem from the other end: the agent figures the task out once, generates reusable code from the successful actions, then replays that code with no model in the loop until the page changes.

Both matter more than they sound. A repeated task that runs deterministically is faster, cheaper and predictable. A task that re-reasons from scratch every week costs model tokens every week and can surprise you.

6. Security

A browser agent with access to your accounts is exactly the configuration security researchers warn about. Simon Willison, who coined the term prompt injection, frames it plainly:

“If you are a user of LLM systems that use tools (you can call them “AI agents” if you like) it is critically important that you understand the risk of combining tools with the following three characteristics. Failing to understand this can let an attacker steal your data.”

Simon Willison, “The lethal trifecta for AI agents”, 16 June 2025

The three characteristics are access to private data, exposure to untrusted content, and the ability to communicate externally. A browser agent logged into your accounts and reading arbitrary web pages has all three by design.

Practical mitigations: give each agent its own dedicated account rather than your personal login, scope permissions to the minimum, choose a vendor where credentials never reach the model, and keep a human approval step on anything that spends money or publishes publicly.

The main tools, compared

Pricing and capabilities as of August 2026. Verify before committing, because this category is moving fast.

ToolHosted MCPHow you payAuthentication
Browser UseYes, header authFree tier of 10 tasks a month, then prepaid credits from 5 dollars. No monthly minimum, credits never expire. Roughly 0.02 dollars per browser-hour plus model tokensChrome profile sync, credentials injected programmatically, TOTP from a supplied secret
BrowserbaseYes, key in query stringFree tier of 1 browser hour a month, then 20 dollars a month (Developer) or 99 dollars (Startup)Contexts: a reusable profile directory, log in once and attach to future sessions
Anchor BrowserYes, header auth50 dollars a month minimum plus usage, around 0.10 dollars per browser-hour and 3 dollars per proxy GBStrongest of the group. Persistent identities, automatic re-login and MFA, secrets never reach the model or logs
HyperbrowserYesFree tier, then credits purchasable directly or 30 dollars a month. Directly purchased credits expire after 12 monthsManaged sessions, CAPTCHA solving, fingerprint randomisation
SkyvernLocal onlyFree tier of 5,000 credits a month, then 29 dollars (Hobby) or 149 dollars (Pro). Moved off per-step pricing in January 2026Bundled into plan tiers. Open source under AGPL-3.0 if you self-host
Cloudflare Browser RunYes, but read-onlyFree tier of 10 minutes a day, then 10 hours a month included and 0.09 dollars per hourNone built in

A rough decision rule. Low volume and occasional use: Browser Use, because prepaid credits with no minimum means an idle month costs nothing. Difficult logins and MFA at the centre of the job: Anchor Browser, and the subscription is worth it. Already writing your own Playwright and you just need somewhere to run it: Browserbase or Cloudflare Browser Run. Genuinely strange interfaces that structured parsing cannot read: Skyvern.

What we are building with one

We are wiring a browser agent into our own publishing workflow, and the reasoning is a useful worked example of the criteria above.

The goal is to get new articles into the indexes that feed AI answers. That breaks into three tasks, and only one of them turned out to need a browser agent at all.

Bing, which feeds ChatGPT. Solved with IndexNow, an open protocol that pushes new URLs to Bing, Yandex, Naver and Seznam in a single HTTP request. No browser, no form, no fragility. Google has never adopted it.

Brave, which feeds Claude. Anthropic lists Brave Search as a subprocessor for Claude’s web search, so Brave’s index is roughly what Claude cites, and almost nobody submits to it. Brave offers a public submission form with no API and no bulk option. That is a browser job, unless the form accepts a plain POST, which is worth ten minutes of testing before building anything.

Google Search Console. This is the one that genuinely needs an agent. The Indexing API is restricted to job postings and broadcast events, and that restriction is enforced at the approval stage rather than merely documented. The URL Inspection API is read-only. So the “Request indexing” button has no programmatic equivalent, sits behind a Google login, and is capped at roughly 10 to 12 URLs a day.

Three lessons that generalise. Check for an API first, because two of our three tasks did not need an agent. Let authentication drive the vendor choice, because the Google login is the hard part and the clicking is trivial. And pair the agent with an API-based check, because we use the URL Inspection API to verify articles actually got indexed, which is how you catch a silently broken session.

When not to use a browser agent

The honest version of this category, which vendor comparison pages tend to skip.

If there is an API, use the API. A browser agent is slower, costlier and far more fragile than an HTTP request. The temptation to reach for the agent because it is more interesting is real and should be resisted.

If the task runs thousands of times a day, the per-run cost compounds fast and you want deterministic code with an agent only as a fallback, which is exactly what the record-and-replay features exist for.

If the site forbids it, read the terms. Better authentication handling makes a session survive, it does not make the site’s operator happy about it. Automating your own accounts on tools you pay for is not the same as automating someone else’s platform at volume.

If you only need a couple of clicks before reading a page, a scraping API with browser actions will do it for a fraction of the cost and complexity. Reach for an agent when the task has branching, state or a login.

If the failure mode is expensive, keep a human in the loop. Several vendors support pausing a run for approval and resuming with the session intact. Use it on anything that spends budget or publishes.

For a broader view of where this fits alongside other agent tooling, see our guides to MCP servers for marketers, MCP versus APIs and the best marketing AI agent builders. If your interest here is AI search visibility specifically, start with Answer Engine Optimisation and how AI visibility tools actually work.

About Growth Method

Browser agents solve the plumbing problem: getting an AI agent to operate the tools that were only ever designed for humans. Growth Method solves the layer above it. It is the agentic marketing platform for B2B teams, helping you plan your strategy, run more campaigns, and learn what works, all in one place, for people and agents. Connect your existing stack and let agents work through the same plan, launch, analyse workflow your team does, so the automation you build feeds prioritised campaigns rather than sitting in a script nobody owns.

Get started to see it working with your stack.

Frequently asked questions

What is a browser agent?

A browser agent is software that drives a real web browser on your behalf, using an AI model to decide what to click, type and read. Unlike a scraper, which fetches raw HTML, a browser agent operates the page the way a person would: logging in, filling forms, navigating multi-step flows and reacting when the layout changes. It exists because most of the web has no API.

What is the difference between a browser agent and a cloud browser?

A cloud browser is infrastructure: a hosted Chrome instance you drive with your own code via Playwright, Puppeteer or the Chrome DevTools Protocol. A browser agent adds the decision-making layer on top, so you describe the task in natural language and a model works out the steps. Browserbase and Cloudflare Browser Run sell infrastructure. Browser Use and Skyvern sell agents. Several vendors now sell both.

Do browser agents work with MCP?

Yes. Most major vendors ship a Model Context Protocol server, and several are hosted remotely so you connect with a URL and an API key rather than running a local process. Browser Use, Browserbase, Anchor Browser and Hyperbrowser all offer hosted MCP endpoints. Cloudflare’s hosted browser MCP is read-only, so it can fetch and screenshot a page but cannot click or fill forms.

How much do browser agents cost?

Billing splits into two models. Prepaid credits with no monthly commitment suit low-volume and occasional use: Browser Use sells credits from 5 dollars with no minimum and no expiry, and Hyperbrowser sells credits directly, though purchased credits expire after 12 months. Monthly subscriptions with included usage suit steady volume: Browserbase starts at 20 dollars a month, Skyvern at 29 dollars, and Anchor Browser at 50 dollars. Most vendors have a free tier that covers genuinely small workloads.

Is a scraping API with browser actions the same as a browser agent?

No, though the gap is closing. Scraping APIs such as Context.dev now let you click, type and wait before capturing a page, which handles cookie banners and content behind a tab. The difference is state: Context.dev caps actions at five per request and has no cookie store, session reuse or persistent profile, so it cannot hold a login between runs. Firecrawl’s interact endpoint does persist sessions through named profiles, which puts it much closer to a true browser agent. If your task needs a login, check for persistent authentication before assuming a scraping API will cover it.

Are browser agents safe to give access to my logged-in accounts?

Treat it as a real risk, not a formality. A browser agent with access to your accounts sits squarely in what Simon Willison calls the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Choose a vendor that stores credentials as secrets the model never sees, scope each agent to a single dedicated account rather than your personal login, and keep a human approval step on anything that spends money or publishes.


Back to top ↑