AI using a browser is no longer a special demo. Playwright and Puppeteer are established tools for browser control and test automation, and Playwright now presents AI agent workflows as an official use case. Playwright MCP connects agents to browser state and tool calls through accessibility-oriented snapshots. Computer Use operates the screen a person sees, while frameworks such as Browser Use connect the model, browser, and task loop. Coding agents opening a browser to inspect a page and debug it are part of the same shift.
The question is no longer whether AI can use a browser. It is which layer should control the browser, who manages the execution environment and permissions, and how a failed task can be reproduced or handed back to a person.
Browser control is already split across layers
These tools are often grouped under “browser automation,” but they do different jobs.
| Approach | Main responsibility | Strength | Limitation |
|---|---|---|---|
| Playwright · Puppeteer | Browser control and automation | Fast, predictable, and strong for testing | Browser execution and operations must be managed separately |
| Playwright MCP | A browser tool an AI can read and call | Less dependent on screen coordinates because it uses accessibility snapshots | Agent permissions, recovery, and session management still need separate design |
| Computer Use | Operating the screen a person sees | Can handle websites and GUIs without an API | More exposed to screen-state errors and security risks |
| Agent frameworks such as Browser Use | Connecting the model, browser, and task loop | Easier to combine instructions with recovery flows | Production use still needs browser infrastructure and observability |
| Cloudflare Browser Run | Remote browser execution and operations | Brings sessions, recordings, debugging, human intervention, and scaling into one place | Adds service cost and platform dependency |
The important distinction is not which product wins, but where responsibility sits. Playwright and Puppeteer are the control layer for making defined actions fast and repeatable. MCP is the interface that lets a model read and call those capabilities; it does not design permissions or recovery for you. Computer Use reaches screens where structured APIs or accessibility information are missing, but it depends more heavily on coordinates, screen state, and model judgment. Frameworks such as Browser Use connect the task loop without automatically solving the infrastructure needed to run many sessions reliably.
Cloudflare is packaging what happens after the browser starts
Cloudflare’s Browser Run stands out because it packages the operations layer that was missing from the table. Cloudflare says it can start browser sessions on its global network when needed, control them through Puppeteer, Playwright, CDP, MCP, and WebMCP, and provide Live View, session recording and replay, real-time debugging, and human intervention. If Playwright answers “how do we control the browser?”, Browser Run is closer to “where do we run it, and how do we observe and recover it?”
For an agent, acting in a browser matters—but so do seeing a failed session, replaying it, and handing it to a person.
Cloudflare’s Kitesurf points in a different direction. If Browser Run is a remote execution environment, Kitesurf is a product that tries to redesign the browser itself around agents. Taken together, the two products suggest that Cloudflare wants to cover the full path from an agent’s instruction to its action on the web. That is an interpretation of the product direction, not evidence that Cloudflare will own the market.
A hardening trend, not a single winner
There is evidence that this direction is becoming durable. Multiple companies and open-source projects now treat the browser as an agent tool, and they are productizing control, model connection, and execution infrastructure as separate layers. But this is not yet a stage where one winner replaces everything. Playwright and Puppeteer remain a good fit when predictability matters, while Computer Use is still useful for work that exists only on a screen. MCP and Browser Use connect those worlds, and Browser Run is an option for operating the combination remotely.
That means browser competition is no longer only about rendering speed. Can sessions be isolated? Where are permissions checked? Can instructions arriving from a web page change an agent’s behavior? Can a failed run be recorded and replayed? Can a person stop it at any time? Website builders will also need clearer boundaries between the state an agent can read and the actions it is allowed to take.
AI entering the browser is not simply a chatbot button beside the address bar. As agents join people as browser users, the browser is moving from a client that shows pages toward a runtime that executes work. For now, Playwright, Computer Use, Browser Use, and Browser Run are taking different layers rather than pushing one another out. The next contest is less about who can click most convincingly and more about who can operate browser work safely and repeatedly.
