agent-browser: give your coding agent a browser for the tools that don't have an API

Every RevOps stack has a layer that no API reaches. The vendor portal where you download the monthly invoice CSV. The ad platform setting that only exists in the UI. The partner directory you update by hand. The landing page form you "just quickly test" after every workflow change. That layer is where the clicking lives, and it's the layer coding agents have been worst at.

agent-browser (agent-browser.dev, open source from Vercel Labs) is the first browser tool I've used that fixes this properly for Claude Code, Codex and Cursor.

What it actually is

A command-line browser controller. Your coding agent runs shell commands like agent-browser open example.com, and a background process drives a real headless Chrome. Nothing new to learn for the agent. It already knows how to run commands.

The important part is agent-browser snapshot -i. Instead of dumping the page's HTML (3,000 to 5,000 tokens, most of it noise), it returns the accessibility tree: a short text list of what's on the page, with each interactive element tagged @e1, @e2, and so on. A typical snapshot is 200 to 400 tokens. The agent then says agent-browser click @e2 or agent-browser fill @e3 "[email protected]". No CSS selectors, no guessing at element IDs that change on the next deploy.

Three other pieces matter for ops work:

agent-browser state save / state load keeps cookies and logged-in sessions between runs, so the agent doesn't re-authenticate every time.
--session NAME runs isolated browsers side by side, e.g. one logged into your HubSpot sandbox, one into production.
agent-browser mcp exposes it as an MCP server if you'd rather use it that way than via the shell.

Install: npm install -g agent-browser then agent-browser install to pull Chrome.

Why this matters for GTM and RevOps

Most of the orchestration work we build connects tools through their APIs. That covers maybe 80% of the stack. agent-browser covers a good chunk of the remaining 20% without a new integration project per tool. Concrete uses I'd put in front of a RevOps or CS lead this week:

End-to-end form QA after workflow changes. You change a HubSpot lead-routing workflow. Instead of asking a rep to submit a test form, the agent opens the landing page, fills the form with Acme Corp placeholder data, submits, then checks via the CRM API that the contact landed, got the right owner and the right lifecycle stage. One command, runs on every change, catches the broken routing before Monday's leads do.
Pulling data from vendor portals that have no API. Billing portals, ad platforms, partner dashboards, review sites. The agent logs in with a saved session, navigates to the export, downloads the CSV, and hands it to the next step of your pipeline. That's the monthly "someone downloads eight reports" chore gone.
Verifying tracking and attribution. Open the site, accept cookies, click through a campaign URL, and check that the UTM parameters, the HubSpot tracking cookie and the conversion event all fire. Marketing ops usually does this by hand in an incognito window when something looks off in the numbers. Now it's a scheduled check.
UI-only admin settings. Plenty of SaaS tools expose 90% of their config via API and leave the last 10% in a settings page. Recurring audits of those pages (SSO settings, notification routing, user seats) become something the agent can read and report on rather than something a human clicks through quarterly.
Chatbot and self-service flow testing. Run through your own support bot or pricing calculator as a customer would, and diff the output against the expected path. Useful before and after every prompt change to the bot.

Where I'd be careful

Logged-in sessions mean stored credentials. Treat saved state files like passwords: keep them out of repos, scope them to a service account with the minimum permissions, and don't let the agent hold a session for a tool it only needs occasionally.

Check the terms of the sites you point it at. Automating your own vendor portal is fine. Automating LinkedIn or a competitor's site at volume is a different conversation and usually a bad one.

And keep the human gate on writes. Reading a portal, filling a test form and downloading a report are low-risk. Changing a live setting in a production admin panel through a browser the agent controls is not, and the same "propose, then a human approves" pattern we use for CRM writes applies here.

The business case in one line

Every "just click through and check" task in your ops backlog is a candidate. Add up how many hours a month your team spends inside portals and settings pages that have no API, and that's roughly the ceiling on what this saves.

Anyone already running agent-browser or Playwright MCP against ops tools? Curious which portals you've pointed it at and where it broke.