Agentic Browser: When Your Agent Actually Needs One
Agentic browser names two products: one you sit in front of and one your agent drives. Most jobs need neither. The test is whether the task carries state.
Copy this line to your agent to get a remote browser session it can drive.
set up https://monid.ai/SKILL.md and use x402.browserbase.com /browser/session/create to open a browser session
Two different things are called an agentic browser and they have almost nothing in common. One is an application a person installs and sits in front of, where an assistant reads the tab and clicks on their behalf. The other is a headless browser somewhere in a data centre that your code opens, drives and closes. The search results for the term answer whichever half the author was selling. This guide separates them, then argues that most jobs people reach for either one to do need no browser at all, and shows the version that runs through Monid, the OpenRouter for agent tools.
What is an agentic browser?
An agentic browser is a browser where a model takes actions instead of only rendering pages. That definition covers both products in the category, which is exactly the problem, because the two are bought by different people for opposite reasons.
The consumer agentic browser
This one is an application. Perplexity's Comet is the best known, OpenAI's Atlas is the other name people mean, and Brave, Opera and others ship assistant modes in the same shape. You install it, browse normally, and ask it to do things with the page in front of you: summarise this, fill this in, find the cheapest of these and add it to the cart. The agent shares your session, which is the whole point and also the whole risk. It is already logged into your email, your bank and your work tools because you are.
The buyer here is a person, and the product is convenience.
The programmable agentic browser
This one is infrastructure. It is a headless Chrome running remotely that your program connects to over the Chrome DevTools Protocol, drives with Playwright or Puppeteer, and shuts down when the job finishes. There is no user, no personal session and no interface. Browserbase is the reference example and there are several others.
The buyer here is a developer, and the product is a browser they do not have to operate.
Why keeping them apart matters
Because every question about the category resolves differently depending on which one you meant. "Is an agentic browser safe" is a serious question about the first and a mostly irrelevant one about the second, since a throwaway session with no credentials cannot leak your inbox. "How much does an agentic browser cost" is a subscription question for one and a per-minute infrastructure question for the other. Read any comparison in this category and the first thing to establish is which product it is about.
| Aspect | Consumer agentic browser | Programmable agentic browser |
|---|---|---|
| Who drives it | A person, in a window | Your code, over CDP |
| Whose session | Yours, already logged in | A fresh, empty one |
| Bought for | Convenience | Not operating a browser fleet |
| Priced as | A subscription | Per session or per minute |
| Main risk | Your credentials, exposed to page content | Cost, if sessions leak |
| Examples | Comet, Atlas, assistant modes | Browserbase and similar |
The pattern is that the consumer version borrows your identity and the programmable one deliberately has none.
How does an agentic browser work?
Both kinds work by giving a model a loop: look at the page, decide on an action, perform it, look again. What differs is where the page comes from and what the model is allowed to touch.
The loop, concretely
The model receives some representation of the current page, usually the accessibility tree, a simplified DOM, a screenshot, or a mix. It emits an action: click this element, type this text, scroll, navigate, extract. A runtime performs the action against the real browser and returns the new state. Repeat until the goal is met or a step budget runs out.
The interesting engineering is in the representation. A full DOM is far too large for a context window and a screenshot alone loses element identity, so every product in this space has an opinion about how to compress a page into something a model can reason over. That opinion is most of what differentiates them.
The failure mode the category has not solved
The loop treats page content as information, and a model reading a page cannot reliably tell the page's content apart from its own instructions. That is indirect prompt injection, and in an agentic browser it is not theoretical. Brave's security team published a working attack against Comet in which instructions hidden in a page were executed when the user simply asked for a summary, and a follow-up showing the same thing achieved with text hidden inside a screenshot, invisible to a person and legible to the model.
This is a systemic property of the design rather than one vendor's bug, and it is the strongest argument for the programmable kind wherever you have a choice: a session with no credentials in it has very little for an injected instruction to steal.
What the browser is actually for
Strip the loop back and a browser buys you exactly two things a fetch cannot: it executes JavaScript, and it holds state across requests. Everything else about it is overhead. Once you see it that way, the design question becomes narrow and answerable, which is the next section.
How do you use an agentic browser from your own code?
Open a remote session, attach your automation library to it, and treat it as a resource with a lifetime. The point of doing it this way rather than launching a local Chrome is that you stop owning the browser: no driver to keep in step, no memory per tab on your machine, no pool to build when you need five at once.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Open a session
What it does. Creates a remote browser and returns the address your automation library connects to.
The endpoints. x402.browserbase.com/browser/session/create.
The call.
monid inspect -p x402.browserbase.com -e /browser/session/create
monid run -p x402.browserbase.com -e /browser/session/create -w
What comes back. sessionId, connectUrl, liveUrl, authToken, paidMinutes, expiresAt and a pricing object. Verified against a live run on 21 August 2026, which returned five paid minutes and an explicit expiresAt. The liveUrl opens a DevTools inspector on the running session, which is the single most useful thing here when a script misbehaves.
What it costs. Per call to open, with the session carrying a fixed block of minutes. Current figures on monid.ai/tools.
Step 2. Drive it with Playwright
What it does. Connects your existing automation code to the remote browser instead of a local one.
The endpoints. None. This is your code talking to the connectUrl from step one.
The call.
import json
import subprocess
from playwright.sync_api import sync_playwright
session = json.loads(subprocess.run(
["monid", "run", "-p", "x402.browserbase.com",
"-e", "/browser/session/create", "-w", "-j"],
capture_output=True, text=True, check=True,
env={"NO_COLOR": "1"},
).stdout)
with sync_playwright() as p:
browser = p.chromium.connect_over_cdp(session["connectUrl"])
page = browser.contexts[0].pages[0]
page.goto("https://example.com")
print(page.title())
browser.close()
What comes back. A normal Playwright page object. Every selector, wait and assertion you already wrote works unchanged, which is the reason to use CDP rather than a bespoke API.
What it costs. The session, not the actions. Ten clicks inside one session cost the same as one.
Step 3. Close it, and mean it
What it does. Ends the session so the meter stops.
The endpoints. None, though sessions carry an expiresAt as a backstop.
The call. browser.close() in a finally block, or a context manager. This is the entire cost control story for browser work: sessions that leak are the only way this gets expensive, and they leak when an exception skips the cleanup.
What comes back. Nothing, which is the point.
📖 See also How I Gave My Agent Eyes on the Live Web
How do you build an agentic browser?
Assemble three parts: a browser you can drive remotely, a way to turn a page into something a model can read, and a loop that turns model output into actions. None of the three is research any more, and open source implementations of the loop exist to start from.
The part that decides whether it works is the page representation. Feeding raw HTML is the naive version and it burns the context window on markup. The approaches that hold up are the accessibility tree, which is compact and carries element roles, or a numbered overlay where interactive elements get short ids the model can refer to. Pick one before you write the loop, because everything else depends on it.
The part that decides whether it is safe is what the session is allowed to reach. Build it with no credentials by default, add them per task, and treat every instruction that arrives via page content as data rather than a command. That is the direct lesson of the Comet research above, and it is much easier to design in at the start than to retrofit.
The part people underestimate is the browser fleet. One session on a laptop is a demo. Concurrent sessions with clean state, sensible timeouts and no leaks is an operations project, and it is the reason remote session endpoints exist as products at all.
Which endpoint should I use for which job?
| Job | Endpoint | Input | Output | Billing |
|---|---|---|---|---|
| A task with a session | x402.browserbase.com/browser/session/create | none | sessionId, connectUrl, liveUrl, paidMinutes, expiresAt | per call |
| Page text, no browser | context.dev/web/scrape/markdown | url, useMainContentOnly, waitForMs | markdown plus page metadata | per call |
| Rendered HTML for a parser | context.dev/web/scrape/html | url, render options | fully rendered HTML | per call |
| Ten URLs, free | tinyfish/fetch | urls, purpose, format | text, title, language, latency | free |
| Find pages first | context.dev/web/search | query, numResults, freshness | ranked results, optional markdown | per result |
Every row verified with monid inspect on 21 August 2026. The table gives the billing shape rather than a figure, because the shape is what changes your design and a number goes stale silently.
When does your agent not need a browser?
Most of the time, and this is the section that will save you the most money. The test is one question: does the task carry state across requests? Logins, carts, multi-step forms and wizards do. Reading a page does not, and reading a page is what the majority of agent web tasks turn out to be.
If the answer is no, a fetch endpoint does the same job for a small fraction of the cost and none of the operational surface. context.dev/web/scrape/markdown renders JavaScript on its side, so the usual reason people cite for needing a browser is already handled, and it returns markdown rather than a DOM you then have to reduce. That endpoint is the fourth of the four kinds of scraping tool, and the taxonomy guide covers where the other three fit.
If the site has an API, use the API and skip both. Driving a browser against a service that publishes structured data is the most expensive way to get information that was available for free, and agent frameworks make it easy to do by accident because clicking feels more general than integrating.
And if you are doing consumer browsing rather than building, a consumer agentic browser is genuinely the right tool and nothing here argues otherwise. Just read the security research first, and be deliberate about which tabs it can see.
Conclusion
Agentic browser names two products, and once you know which one a given article means, most of the confusion in the category disappears. One shares your identity to save you time; the other has no identity at all and saves you from operating a browser fleet.
The decision rule that matters more than the vendor choice is state. A browser exists to run JavaScript and to remember things between requests. If your task needs the second, open a session. If it only needs the first, an endpoint already renders the page and you are paying for a browser to reach a result you could have fetched.
Free next step: run monid discover -q "headless browser automation session" and monid inspect the top row alongside the markdown scrape endpoint. Both are free, and comparing the two schemas is the fastest way to see which side of the state question your job falls on. Start at monid.ai.
FAQ
What is Comet, and is it an agentic browser?
Comet is Perplexity's browser with a built-in assistant that can act on the page you are viewing, so yes, it is an agentic browser of the consumer kind. Atlas from OpenAI is the other name that comes up most often and sits in the same category. Neither is something you call from code; if you are looking for an agentic browser your program can drive, you want a remote session endpoint instead.
Do you still need playwright-stealth or undetected-chromedriver?
Only if you are running the browser yourself. Both projects exist to make a locally launched automated Chrome look less automated, and both are in a permanent race against detection they cannot win outright. A hosted session removes the reason to run that race, because keeping the browser presentable is the provider's job rather than a dependency in your requirements file. If the underlying task is just reading a page, neither library nor a browser is the answer.
Are agentic browsers safe?
Consumer ones carry a real and currently unsolved risk, which is indirect prompt injection: instructions hidden in page content that the model executes as if you had typed them. Brave's researchers demonstrated this against Comet using both hidden page text and text concealed inside a screenshot, in cases as ordinary as asking for a page summary. Programmable sessions dodge most of the impact by holding no credentials, which is a good reason to prefer them for anything automated.
Can you run an agentic browser with a local LLM?
Yes, and the loop is model agnostic, so a local model works as long as it can follow a structured action format reliably. The practical limits are context and consistency: page representations are long, and a small local model tends to drift over a multi-step task in a way that shows up as clicking the wrong element rather than as an error. Start by keeping the browser remote and the model local, since those two choices are independent.
Last updated August 2026.
