Why is everyone shipping a separate browser for agents instead of driving a normal one?

The second reason, and I think it is the bigger one commercially: credentials and isolation.

A script runs somewhere you control with credentials you provisioned. An agent browsing the web on your behalf raises immediate questions:

• Which sessions is it logged into, and can it reach your bank because your profile was reused?
• What stops a page it visits from containing text that redirects it — prompt injection through page content is a genuine, demonstrated problem and the browser is the delivery vehicle.
• Where does it run, if you do not want it on your laptop with your cookies?

That explains the edge-worker one on your list. Running the browser somewhere disposable, with a scoped profile, is a real architectural answer rather than a packaging choice.

So a good chunk of these products are less about the browser and more about the sandbox around it. That is the part I would evaluate them on.

There is a real difference and it comes down to what the automation is given to look at.

A script knows the page. Somebody wrote a selector, and if the selector still matches, the script works. The page representation the tool provides — a DOM tree, full markup — is enormous and that is fine, because code does not have a context limit.

An agent does not know the page and has to be told what is on it, in a form small enough to fit in context and stable enough to act on. That is the actual engineering problem, and existing automation tools were never built for it:

• Serialising a page into something a model can read without shipping half a megabyte of markup.
• Giving elements stable handles the model can refer to, since it cannot write a CSS selector for something it has not seen.
• Deciding when the page has settled, which a script solves by waiting for a specific element and an agent cannot.

So the wave is not imaginary. Everyone is rebuilding the same missing layer.

Worth adding what has genuinely changed in the last while, because it is why this is happening now rather than three years ago.

The browser automation projects have grown accessibility-tree snapshots and element-handle abstractions specifically aimed at this use case, and there are now standard ways to expose a browser to an agent as a set of tools rather than as an API you write code against.

So the honest read is: the base tooling is converging on the same answer, and the products are competing on the layer above — sandboxing, session handling, recovery when a step fails, and how well they cope with a site that changes.

My practical advice if you are choosing: test them on a site that fights you. Every one of these demos beautifully on a clean page. The differences appear on a page with a cookie banner, a modal, an infinite scroll and a login.

One thing to decide before adopting any of them: what the agent is allowed to do, as opposed to see.

Reading pages is a fairly contained risk. Filling forms, clicking through checkouts, sending messages and changing settings is a different category, and the failure is not "wrong answer" but "wrong action, already taken".

The products that impress me draw that line explicitly and make the write actions require confirmation. The ones that treat browsing and acting as the same capability are the ones I would keep away from anything logged in.