What Would a Browser Built for AI Agents Look Like?

Sia — Mon, 28 Sep 2026 11:43:03 +0000

For the past two decades, browsers have evolved around people. To keep pages smooth and ready to display at any moment, they continuously maintain layout, painting, compositing, and frame caches. But agents rarely need to keep “looking” at a page. They care more about whether the task gets done, how much time, tokens, and memory it takes, and how many concurrent sessions one machine can handle.

That was the starting point for building Moli from scratch: making task success and efficiency the top priorities of an agent-native browser engine.

1. The Browser User Has Changed

Traditional browsers are built around how people view and interact with the web. Agents have different priorities. They care more about whether a page is easy to understand, whether actions are reliable, how much CPU and memory each task uses, how fast instances can start and shut down, and whether the system can handle concurrency and recovery at scale.

So the way we evaluate browsers also changes: from visual experience for humans to structure, reliability, and efficiency for agents.

Agents don’t need to keep watching a page. They need to understand it and complete the task reliably.

2.Why Not Just Use Chrome?

Chrome has great compatibility, a mature ecosystem, and strong standards support. For complex interactions, media-heavy pages, extensions, or sites that depend on Chromium behavior, Chrome is still a solid choice.

The issue is that Chrome was built for a different kind of user. To keep pages ready for humans at all times, it continuously maintains layout, painting, compositing, and rendering state. Even if an agent only wants to read an article or submit a form, the browser still pays the cost of being ready to render the next frame.
At cloud scale, higher memory use per instance, frequent cold starts, and the overhead of managing browsers, drivers, and processes all add up and eventually limit concurrency.

Moli is not trying to build a better general-purpose browser. It asks a different question: if a browser were built for agents from day one, would it still need the same cost structure?

3.Moli’s Technical Approach
Moli doesn’t strip down Chromium. It rebuilds the browser engine around how agents actually work, with two key ideas: load resources only when needed, and render only when needed.

Traditional browsers load images, fonts, audio, and video early so the page is always ready to display. But for tasks like web extraction, WebFetch, or form filling, many of those resources aren’t necessary and still use bandwidth.

Moli lets the agent decide what to load. By default, it keeps HTML, JavaScript, CSS, and page semantics working properly, and only fetches images or media when they’re actually needed.

Most of the time, agents need the DOM, text, links, form state, and network responses—not a constantly updated screen. So Moli can directly return Markdown, JSON, DOM, or a semantic tree. It only continues into layout and painting for tasks like screenshots, coordinate clicks, or spatial reasoning.

Unlike Chrome, which keeps layout and rendering state around, Moli renders on demand, uses the result, and releases it. If no pixels are needed, there’s no reason to keep paying the rendering cost.

Moli keeps the core capabilities needed to run real websites, including DOM, V8, CSS, iframe, Worker, Wasm, Cookie, and common Web APIs, with native support for CDP, WebDriver Classic, and WebDriver BiDi in a single binary. Playwright, BrowserUse, and Selenium can connect directly without extra driver installation or version matching.

Moli is written in Rust not only for performance, memory safety, and concurrency, but also because the Rust ecosystem already offers mature browser building blocks: Servo / Stylo for CSS parsing and style computation, html5ever for HTML parsing and DOM construction, rusty_v8 for running JavaScript with V8, Taffy / Parley for page and text layout, and AnyRender / Vello CPU / usvg for software rendering, SVG, and image processing.

Together, these components form a complete browser pipeline from networking and DOM to JavaScript, layout, and rendering. The goal is not to reinvent every low-level browser primitive, but to bring these capabilities together into a real browser engine and redesign resource loading, on-demand rendering, automation, and instance isolation around agents.

4.What Do These Tradeoffs Deliver?

To validate this approach, we tested Moli across web compatibility, task success, and resource usage.
In Web Platform Tests (WPT), Moli has passed 1.612 million test cases. For capabilities agents use frequently, including Fetch, XHR, Worker, Web Storage, WebCrypto, and Wasm, its coverage is already comparable to Chromium.

We also built more than 1,000 Vue, React, and Angular sites and compared their DOM changes during page load with Chromium. The results stayed consistent, showing that Moli does more than just read HTML. It can run modern dynamic websites.

We then selected 192 public Chinese and English URLs and compared Moli with Chrome Headless on extraction success rate, task time, and memory use.

Moli and Chrome Headless had similar success rates and median task times, but Moli’s median RSS was about one-tenth of Chrome’s. The goal is not simply to cut features, but to find a better balance between task completion and resource efficiency for agents.

For our Agent Episode startup benchmark, we measured how long it took from launching the browser process to having a CDP endpoint ready to connect.

Moli reaches CDP Ready about 4.9× faster than Chromium. Combined with its lower memory use, this makes it a better fit for short-lived tasks that frequently create, run, and recycle browser sessions, with more room for concurrency on the same infrastructure.

Moli has also been tested with 13 common automation frameworks through LexBench. Playwright, BrowserUse, and Selenium can keep using familiar protocols without rewriting the agent harness.

Moli was built from scratch not to make a smaller Chrome, but to give agents a better way to execute web tasks.

It keeps the core capabilities needed to run real websites while putting structured information, task efficiency, and resource use first. A web page no longer has to be treated as a screen that is always being rendered, but as an environment agents can understand, interact with, and operate at lower cost.

This is Lexmount AI. We’ll keep sharing our work on agent browsers, automation infrastructure, and real-world engineering, along with Moli’s design decisions and benchmark results.

If you found this useful, feel free to like, share, or leave a comment. What matters most to you in an agent browser: compatibility, resource efficiency, or task success?

DEV Community: Sia

What Would a Browser Built for AI Agents Look Like?