What Is a Browser Agent? How It Works and When to Use One
By Steven Van ·
Browser Use's guide covers the model, harness and browser behind an agent, when to choose scripts or APIs instead, and a usage breakdown.
Browser Use has published an explainer on browser agents: what they are, how they work, when to pick one over a script or an API, and where they fail. The post is educational rather than a product release.
How a browser agent works
The post describes an agent as a loop. It opens a page, observes it, picks an action, executes it, and checks the result, repeating until the goal is reached. The harness should stop a run that hits a time, step, or cost limit. Some tasks need a human, for example to sign in, supply missing information, or approve an action.
Three components make up an agent:
- Model: decides what to do next from the task and the current page.
- Harness: supplies context and tools, runs the tools the model requests, and feeds results back. Browser Use's Browser Harness gives an existing coding agent browser access and lets it write missing helpers during a run, while the coding agent's runtime still manages the loop.
- Browser: loads sites and tracks tabs, cookies, and login state, typically controlled through the Chrome DevTools Protocol or WebDriver BiDi, or through an MCP server such as Playwright MCP.
Agents read pages as structured data (the DOM or an accessibility tree) or as screenshots interpreted by a vision-capable model, and can use both. Screenshots help with canvas-based interfaces, though small controls make precise clicks harder. The agent needs a fresh observation after every page change.
Agent, script or API
The post recommends an API when the service offers one that covers the task, and a script (Playwright, Selenium or Puppeteer) when there is no suitable API and the workflow is predictable, such as downloading the same report every Monday. An agent fits workflows that are unpredictable or cannot be specified step by step. Scripts and APIs are deterministic, while agent decisions are probabilistic, so the same task can take different paths. Results and model costs can also vary.
What people run
Browser Use shared a snapshot of Browser Use Cloud usage across V2, V3 and V4 agents, checked on October 18, 2026. Shares of runs, rounded:
- Getting past a login: 18%
- Extracting structured data: 14%
- Researching open questions: 6%
- Applying for jobs: 6%
- Finding filings and reports: 5%
- Booking and buying: 3%
Another 15% of runs are unclassified. The figures show what people run, not how often the tasks succeed.
Limitations
The post lists inconsistent results, task failures, website blocks, prompt injection, and unpredictable costs as the main downsides. Bot-management systems and rate limits can block agents, and a better model will not fix every access restriction. Sessions expire and multi-factor authentication can require a human. An agent can pick the wrong product, miss a required field, or report completion before saving a form. A run that ends without errors does not prove success, and retrying can create duplicate orders or applications, so the saved record or confirmation should be checked first. For extraction, returned values should be compared with the source page, since valid JSON does not prove the data is correct.
The post links to Browser Use's stealth benchmark for a comparison of how cloud browsers avoid being blocked.