A browser can connect an AI agent to websites that have no API, MCP server, or other first-party integration.
2
Browser tools fit known workflows with explicit actions, while web agents handle open-ended tasks across several pages.
3
Production browser agents need private evaluations, observability, human intervention, and behavior that respects website limits.
Summary
Paul Klein IV argues that the web browser is the default MCP server for the parts of the internet that have no API or MCP integration. A DMV, local barber, or enterprise CRM can still be controlled through its website. He distinguishes web agents, which take a prompt and choose many actions, from browser tools, which perform more constrained actions inside a workflow. He covers vision-based and DOM-based navigation, accessibility trees, and models trained on web trajectories. For production use, he recommends testing on the websites and tasks that matter, recording browser activity, and giving people a way to inspect or take over a session. A live demo uses Cursor and Browserbase to find a dog for adoption. He also discusses CAPTCHA solving, agent authentication, and the need for agents to act within site rules.
The browser connects agents to the ordinary internet
Klein separates AI agents from the legacy internet, where many useful services have no MCP server or API. He gives the DMV and his barber shop as examples, then points to a Delaware franchise tax filing as the kind of boring task that needs automation. Websites are available even when a first-party integration is not, so the browser becomes an integration of last resort. He says this applies to billions of websites and lets an agent work with services that have not been built for AI.
Web agents can use either screenshots or page structure
Klein describes two main approaches to browser control. Vision-driven agents use screenshots, sometimes with boxes drawn over clickable elements, and ask the model to select a marked box. Text-based agents use HTML, XPath expressions, and Playwright code. He says text approaches may be more repeatable, while vision models can work better on complex pages. The accessibility tree offers a smaller representation of a page by keeping its structure without all the extra div tags and CSS classes.
Models trained on web trajectories can reason across pages
Klein describes computer models as a further stage in browser automation. Instead of using a general image model, these models can be trained on web trajectories. He recommends a paper about generating trajectories to teach models how to move from a URL through several pages and choose a route, rather than only selecting the correct button on one page. He says browser navigation is already usable when developers make appropriate choices about the model and automation method.
Browser tools and web agents fit different kinds of work
A web agent turns one prompt into many actions and decides its own path. Klein uses Operator filing a Delaware franchise tax as an example. Repeating the same prompt may produce different paths because the agent controls the reasoning. A browser tool performs a specific action, such as clicking a sign-in button. Klein recommends a browser tool when the workflow has known high-level steps, and a web agent when the task is open-ended or the prompt is unknown.
A horizontal browser server can cover missing integrations
Klein contrasts vertical MCP servers with horizontal ones. A Linear MCP server exposes operations such as creating and assigning a ticket. A browser MCP server exposes general actions such as clicking a button on a page, so one server can work across many sites. He does not suggest replacing specific integrations. Salesforce should use a Salesforce MCP server when one exists, while a browser can reach a bespoke enterprise CRM without reverse engineering its APIs.
Production agents need evaluation and browser observability
Klein says companies should be cautious with public benchmarks, especially when the benchmark maker also ranks its own system. Teams should run evaluations on their own tasks and websites to find the right model for each job. They also need to see what the browser did. Screenshots, action logs, and session recordings can reveal why an agent bought AirPods instead of the requested Xbox, including the prompts and page path that led to the mistake.
In response to a question about financial workflows, Klein describes recordings that can be enabled or disabled based on data sensitivity. The recordings can be embedded in a user-facing application. Browserbase also provides a live view through an iframe, showing the current browser session. A person can click and type through that view, so the system can support human review and intervention instead of forcing every step to remain fully automated.
Browser automation must respect website behavior limits
Klein says CAPTCHA systems were built when most automated traffic was considered harmful, although there are now legitimate agents. Browserbase offers CAPTCHA solving and proxies, but he expects agent authentication to become the longer-term answer, especially after login identifies the agent and the person it represents. He warns that stealth features cannot compensate for abusive behavior. Agents should obey robots.txt, limit their actions, and avoid conduct that is illegal or unethical.
"I really do believe that the browser is that bridge between AI and the rest of the internet."01:38
Who should watch
You are building an agent that must use websites without reliable APIs or MCP servers.
Your workflow has a mixture of predictable steps and open-ended browsing, and you need help choosing between a browser tool and a web agent.
You need browser sessions that people can inspect, record, or take over when data sensitivity or business rules require human review.
