Lightpanda: A Browser Built for Agents, Not Humans

Ask an agent to test the signup flow it just built, and watch what actually happens under the hood. It spins up Chrome. Chrome loads a rendering engine, a GPU compositor, a full extension system, and about a dozen other things designed for a human who wants to see pixels on a screen. None of that is for the agent. The agent doesn't have eyes. It's going to read the DOM, click a button, and check the response. Everything else Chrome just booted is dead weight it's paying for in memory and startup time.

That mismatch is why a browser built specifically for agents, not for humans, is starting to look inevitable. Lightpanda is the clearest example I've seen, and Playwright, the browser automation framework Microsoft built for QA testing, is quietly turning into the same kind of tool from a different direction.

A new layer in the stack

O'Reilly's AI Agents Stack, 2026 edition lays out six layers production agents actually need: models, protocols and tools, memory, frameworks, eval, and guardrails. Browser automation sits in that protocols and tools layer, and the piece makes a point of how fast it got there. Browser Use, one of the frameworks in that space, hit 78,000 GitHub stars in under a year. As the article puts it, nobody was shipping browser agents in production in 2024. Now it's a category with its own name.

Playwright's response to that shift is visible right on its homepage. It still does what it always did, drive Chromium, Firefox, and WebKit for cross-browser test automation, but it now ships an MCP server for tools like Claude Desktop and Cursor, plus a CLI built for coding agents specifically. Agents interact with the page through accessibility trees instead of screenshots, reading element roles and structure the way a screen reader would, which turns out to be a much better fit for a model than a picture of pixels ever was.

That's the smart move for a framework built on real browser engines. But it's still Chrome, Firefox, and WebKit underneath, with all the weight that comes with rendering an actual page for an actual human. Lightpanda skips that question entirely by not starting from a browser at all.

Built from scratch for agents

Lightpanda is written in Zig, not forked from Chromium or any existing engine. No GPU compositor, no graphical rendering, no persistent cookies or session state sitting around between runs. The team's own numbers: 9x faster execution than Chrome (5 seconds versus 46) and 16x less memory (123MB versus 2GB). It still speaks the Chrome DevTools Protocol, so anything that already knows how to talk CDP, including Puppeteer, can point at it and just work.

The state part matters more than it sounds. An agent running dozens of isolated test sessions doesn't want yesterday's cookies leaking into today's run. Chrome carries that baggage by default. Lightpanda starts clean every time, which is exactly the property you want when the thing driving the browser is a model, not a person with a login it plans to reuse.

Getting started

Install it and fetch a page straight from the command line:

curl -fsSL https://pkg.lightpanda.io/install.sh | bash
 
./lightpanda fetch --dump html https://demo-browser.lightpanda.io/campfire-commerce/

Swap --dump html for --dump markdown and you get the page back in a shape an LLM can read directly, no separate HTML-to-text step in your pipeline.

For anything more than a one-shot fetch, run it as a CDP server and drive it with Puppeteer:

./lightpanda serve --host 127.0.0.1 --port 9222

import puppeteer from 'puppeteer-core';
 
const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://127.0.0.1:9222",
});
 
const context = await browser.createBrowserContext();
const page = await context.newPage();
await page.goto('https://demo-browser.lightpanda.io/amiibo/', {
  waitUntil: 'networkidle0',
});
 
const links = await page.evaluate(() =>
  Array.from(document.querySelectorAll('a')).map((a) => a.getAttribute('href'))
);

Same Puppeteer code you'd write against Chrome. The only thing that changed is what's listening on the other end of that WebSocket.

Letting the agent drive itself

The part that makes Lightpanda feel purpose-built rather than just a fast Chrome replacement is agent mode. Point it at a task in plain language and it drives the browser itself:

./lightpanda agent --task "find the top story on news.ycombinator.com"

What comes out the other side isn't a black box. Lightpanda logs the actual steps as PandaScript, plain deterministic JavaScript, so you can replay the exact same run later without paying for another LLM call:

./lightpanda run session.js

That's a real answer to a problem every agent-testing setup eventually hits: an LLM deciding what to click is useful once, but you don't want to re-decide it on every CI run. Record it once with the model, replay it forever without one.

For agents that would rather talk MCP than shell out to a CLI, Lightpanda ships that too:

lightpanda mcp --port 9223

Point any MCP client at http://host:9223/mcp and it gets its own isolated browsing session, tools for navigation, DOM queries, and JavaScript execution included. That's an agent testing and building against a live web page through the same protocol it already uses to reach every other tool, no separate browser SDK to learn.

Where a real browser still wins

None of this makes Playwright irrelevant. If you're testing that a checkout button renders correctly in Safari, you need WebKit's actual rendering engine, not an approximation of one. Lightpanda doesn't try to paint a pixel-perfect page, which is exactly why it's fast, and exactly why it's the wrong tool if pixel-perfect is the point.

The split is starting to look like this: Playwright for verifying how a page looks and behaves for a person, Lightpanda for an agent that needs to read a page, click through a flow, or scrape structured data as cheaply and quickly as possible, at a scale where booting full Chrome a thousand times a day gets expensive fast. I've been thinking about this same split while building AXRank, which grades how well agents can actually use a company's developer surface. The tools an agent uses to test the web are going to look less and less like the tools we built for humans to test it, and that's a good thing, not a compromise.

Subscribe to quintonwall.com for more of this as the agent tooling stack keeps shifting, and follow along on YouTube at @seeqcode for the build-along version.