A cleaner way to let AI use my browser

A first test of Safari’s new agent interface suggests that browser automation can become cleaner and less dependent on any single AI provider.

A cleaner way to let AI use my browser

I have been experimenting with browser control in both ChatGPT and Claude. It is one of those capabilities that can look like a demonstration until you encounter the right work for it.

I regularly have to fill in forms, for example, and I do quite a lot of user acceptance testing on our own platform. That means moving through the same screens, checking the same interactions and recording what happens. It is useful work, but not always a useful way to spend my own attention. An agent can already do a surprising amount of it, provided it has access to a browser.

Until now, that has meant Chrome extensions. There is one for Claude and another integration for ChatGPT. They work, sometimes impressively, but the arrangement has always felt messy to me. The extension has to live in the right browser profile, alongside the rest of my work. Each AI provider needs its own route into the browser. The extension, browser permissions and provider all have to continue cooperating. When the connection becomes unstable, it is not always obvious which layer is responsible.

Chrome is not even my normal browser. I work on a Mac and use Safari. Moving work into Chrome simply because an AI provider has built its integration there already feels like the wrong dependency.

Then I came across WebKit’s announcement of a new way for agents to interact with Safari. I gave it a test run, and the difference was immediate. The connection felt markedly more stable and the interaction more direct. My first tests also suggest advantages in latency and token use, although I have not done enough controlled testing to call that a benchmark.

What interested me most was not the speed. It was the architecture.

One interface, different agents

The technology is called MCP, but the abbreviation is not particularly helpful. It has become a general label for many different connections between AI systems and other software. In this case, the underlying idea is straightforward: Safari provides a standard interface through which an agent can ask what is on a page and perform actions in the browser.

The browser itself provides the connection. I do not need a separate Safari extension from OpenAI, another from Anthropic and perhaps a third one for the next provider. Any compatible agent can use the same interface.

That reverses the relationship I had in Chrome. With an extension, the AI provider integrates itself into my browser. With this approach, my browser exposes a capability to whichever agent I choose.

This also explains why the experience felt cleaner. The agent does not have to behave as if it were a person looking at a screen and trying to operate a mouse. Safari can make the page, its controls and its current state available in a structured form. Screenshots are still possible and sometimes necessary, but they are no longer the entire basis of the interaction.

For a developer, this creates obvious possibilities for debugging and testing. I am interested in something slightly different. I am not a software developer, but the browser is where a large part of my professional work happens. If an agent can interact with that environment reliably, it becomes useful for many ordinary workflows that never justify a custom software integration.

One less dependency

There is a wider business point here. We are starting to build workflows around AI systems while the providers, products and models continue to change quickly. Every workflow tied tightly to one provider becomes another continuity problem.

That does not mean dependencies can be avoided altogether. It means they should sit in the right place. A general ability to operate a browser is better provided by the browser than recreated as a proprietary extension by every AI company.

When the connection is standard, the agent becomes more replaceable. I can use Claude today and another compatible agent tomorrow without rebuilding the browser side of the workflow. If one provider changes its product or loses its lead, my working environment does not have to change with it.

This kind of optionality is easy to underestimate. It is less spectacular than a new model release, but probably more important once AI becomes part of daily operations. Continuity depends not only on what a system can do, but also on how easily its components can be exchanged when circumstances change.

My experiment with Safari was small. I connected an agent, let it work in the browser and compared the experience with what I had been doing through Chrome. Yet it changed how I think about browser agents.

Until now, I saw them mainly as AI products gaining access to a browser. This felt more like the browser becoming a stable working environment that different agents can enter. For someone who depends on the browser but does not want to depend unnecessarily on any single AI provider, that is a much more useful direction.

⚙️
Want to try it? Install Safari 27 beta, enable Show features for web developers and Allow remote automation and external agents, then connect it through Codex with codex mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp. It should then become available in ChatGPT Work conversations; start with WebKit’s instructions if you need the details.
Share this article
Rob Hoeijmakers

Thanks for reading.

I’m Rob Hoeijmakers, a digital and AI strategist based in the Netherlands. I write about AI, organisations and technological change, with a European perspective and a focus on what these developments mean in practice. I’m also the founder of Schmuki, a digital and AI agency.

Every Thursday, I gather the latest essay — or a few of them — into a short note. If that’s useful, you’re welcome to receive it.