Vercel Labs' Agent Browser: The Missing Feedback Loop for Coding Agents

Your coding agent can write the feature, run it, and even write a test for it. What it can't do — what none of them could do until now — is the one step you do without thinking: open the browser and actually look at the thing you just shipped.

Vercel Labs just closed that gap. Agent Browser is a headless browser automation CLI, built in Rust, that gives your agent a new tool: visit a page, click things, fill out forms, screenshot the result, and decide for itself whether the feature actually works.

The only prior option here was Playwright MCP — a full browser engine bolted on as an MCP server, built for writing end-to-end test suites. Agent Browser is narrower on purpose. One job: let the agent see what it built.

In the video#

• 00:00 — Why coding agents are missing a feedback loop
• 00:33 — The problem, on the whiteboard
• 02:08 — Install (npm install -g agent-browser) and first manual demo: snapshot, click, screenshot
• 04:33 — Agent mode: defining tests in natural language via AGENTS.md
• 06:41 — Running the automated test end-to-end with Codex
• 07:53 — Wrap-up

Resources:

• Docs: agent-browser.dev
• Sample AGENTS.md: gist.github.com/XamHans

How it actually works#

Install it globally:

npm install -g agent-browser

Point it at a page and take a snapshot:

agent-browser snapshot -e

That gets you an accessibility tree of the DOM — every link, every button, each with a reference number (e26, e5, whatever). That reference is the entire trick. The agent isn't guessing at a CSS selector that breaks the moment your markup shifts — it's clicking a stable, numbered reference straight from the current page state.

agent-browser click e26

Wait for the page to settle, snapshot again — fewer items, different refs, proof you moved. Then:

agent-browser screenshot block.png

Now the agent can look at its own screenshot and catch what a DOM tree never will: a broken layout, a modal that didn't close, a design regression nobody wrote a selector for.

Turning it into a real test suite#

The commands above are just building blocks. The actual payoff is wiring this into AGENTS.md so the agent runs it without you typing a single command. In the video, the setup defines three things:

• A browser testing engine — "I'm equipped with agent-browser. When asked to run a test case, I follow the standard operating procedure."
• Test cases in plain language — a name, a starting URL, the steps ("find the last article, click the read article button, wait until the page loads"), and the expected result.
• The standard operating procedure — locate the test, extract the URL and session name, run agent-browser through the steps, snapshot after every action, verify the result, report back.

Say "run test blog," and the agent reads the definition, opens the session, clicks through it, screenshots the result, and checks it against what you expected. Nobody re-reads a diff. Nobody reloads the page by hand.

Why this is the actual missing piece#

Agentic coding tools were never short on the ability to generate and run code. What they were missing is the step every developer does on autopilot: look at the result. Agent Browser closes that loop — and it's built narrow on purpose, a fast CLI for exactly this job, not a browser-automation framework you have to bend into shape first.

If you're already running agents against a real codebase, two or three of these plain-language tests in AGENTS.md cost you almost nothing to write. What you get back is an agent that can tell you "it works" — and actually mean it.