PageAgent

The trait that decides it is who the agent is for. This is a dependency you add to your own application so your users get an assistant that can actually operate the interface, rather than a tool you run against a site from outside. No extension to ask people to install, no headless browser to host, just a package in the build you already ship.

That framing also rules it out for scraping and for anything you do not control. Pick it to put an agent into your product. Pick Browser Use when the site belongs to someone else.

The risk is injection, and the architecture puts it at maximum. The agent reads the page and acts on the page, inside a session already authenticated as your user. Any content a third party can render there, a comment, a product listing, a filename, is read by the same loop that decides what to click next, and the loop cannot tell instructions from data.

Restrict it to routes rendering only trusted content and never to pages carrying user submissions. What it does right: no browser extension is required, so there is no second piece of software your users have to trust.

1. Context is gathered by reading the document object model as text, not by rendering and captioning images, which is the design decision everything else follows from. 2. Consequently no multimodal model is required, and no headless browser is needed to produce a viewport, so the cost per step is a text completion. 3. Actions are applied through the same interface that supplied the observation, keeping the loop symmetric.

No verification stage is documented, so whether an action achieved its intent is not checked. No benchmark accompanies the project, and the listing carries no verification date.

Follow the money and it stops immediately. The publisher is a very large platform company, the library costs nothing, and the only hosted piece is a demonstration endpoint explicitly marked for evaluation rather than production. There is no conversion path, which means this exists for ecosystem and recruiting reasons rather than commercial ones.

Moat: none sought. The strategic value is that anyone building browser agents starts from an interface the publisher shaped. Likely path: maintained while it stays useful internally, then dormant, with no acquisition event because there is nothing to acquire. Position: use it, own the fork.

The unusual part is that the cost does not scale with our headcount, it scales with our customers. Shipping this in a product means every user who invokes the assistant spends against an endpoint we fund, so the forecast belongs in the product's unit economics rather than in my tooling budget, and nobody has modelled that yet.

Being a library, there is no vendor account, no directory integration and no support agreement, so this goes through dependency review like any other package. Onboarding for a front-end engineer is an afternoon. Approved with conditions: a spend cap per session before it reaches production.

MIT and a single npm install, which is the correct amount of ceremony for a library. The model layer takes any OpenAI-compatible endpoint, and the documentation says that includes locally deployed models, so I can point it at the server on my own network and nothing about the page ever leaves it.

The part I like most is the direction it runs: it exposes an MCP server, so my existing agent client can reach in and operate a page rather than the page operating itself. That inverts the usual arrangement and it means the library composes with the tooling I already own instead of replacing it.