Every time your AI agent checks whether a button exists, it sends a JSON message over a socket, crosses three process boundaries, and waits for a response. On your own machine. For a DOM node that's already in memory.
That's Playwright. We decided to fix it.
The problem with existing browser automation
Most browser automation tools were designed for a specific job: a human writes a JavaScript test suite, a CI runner executes it, the human reads the report.
AI agents have a fundamentally different shape. They don't write scripts upfront. They decide, act, verify, decide again. Tight loops, dozens of iterations per session, each requiring fresh DOM state. Every millisecond of per-step latency compounds.
When we ran our first benchmarks, the number that stopped us was this: 580ms average latency per step with a CDP-based bridge. On a 10-step verification flow, that's six seconds of an agent just waiting.
We started digging into where the time was going.
What's actually happening under the hood
Most tools talk to browsers via the Chrome DevTools Protocol (CDP). CDP is a message-passing interface: your test process sends a JSON command over a socket, the browser processes it, sends a JSON response back.
Every action crosses at least three process boundaries:
test process → driver → browser process → DOM
For a human-written test suite running overnight in CI, this is fine. For an agent in a tight decide-act-verify loop, it's a structural tax that never goes away.
The async model compounds it. Between await page.click('#submit') and the next line, the DOM might have changed. The usual answer is retry logic, timeouts, and waitFor helpers — all of which add latency. None of it is anyone's fault. It's inherent to the architecture.
The insight: what if the driver lived in the same process as the DOM?
We weren't targeting CI runs against chromium.example.com. We were targeting AI agents verifying localhost:3000 apps running on the same machine as the agent, usually generated by that same agent five minutes earlier.
For that use case, the cross-process architecture is pure overhead.
We built Alethia around a zero-IPC model: the driver and the DOM live in the same V8 isolate. Reading document.querySelector('button').textContent is a function call, not a network round-trip. No CDP socket. No marshaling. No async race between action and DOM state.
Two process boundaries remain between your agent and the runtime (agent ↔ MCP bridge, bridge ↔ runtime). Then zero between the runtime and the DOM.
These are reproducible, we publish the full benchmark harness at alethia-anvil. Clone it, run it yourself.
The safety problem nobody was solving
While we were benchmarking, we noticed something else: no existing browser automation tool had any concept of intent-based safety guardrails.
An AI agent can misinterpret an instruction. It can be manipulated by injected content on the page. And if your testing tool happily executes a DELETE /api/users/all or confirms a $500 purchase, the agent won't know it did something wrong until it's too late.
We built a policy gate called EA1 directly into the runtime. Every step is classified by intent before it executes:
- read (navigation, assertions) — always allowed
- write-low (form input, drafts) — allowed by default
- write-high (delete, purchase, transfer) — blocked by default
The gate lives in the same process as the executor. Agents cannot bypass it. When a destructive action is attempted, it fails closed and logs the attempt to the audit trail.
This matters especially for AI agents because you're not always watching. The safety guarantee needs to be architectural, not advisory.
The token cost problem
One thing we didn't anticipate: round-trip snapshot tools are expensive on tokens, not just time.
Most MCP-based automation returns a full accessibility snapshot after every single action. On a simple app that's ~800 tokens per step. On a production app with a complex accessibility tree, several thousand. Across a 10-step flow, you're burning context that the agent mostly ignores.
Alethia returns one compact response per flow — a ~200-token semantic snapshot of what's on screen, not a raw DOM dump.
Not flooding the context window with accessibility trees is what keeps multi-step agent sessions coherent.
How to try it
Alethia ships as an MCP server. Two commands:
npm install -g @vitronai/alethia
Add to your MCP config (Claude Code, Cursor, Cline, etc.):
{
"mcpServers": {
"alethia": {
"command": "alethia-mcp"
}
}
}
Then ask your agent to test something:
Navigate to http://localhost:3000, sign in with test@example.com, assert the dashboard is visible.
No test script. No await page.waitForSelector. No driver setup. The agent speaks plain English; Alethia compiles it to actions, runs the EA1 gate, executes against the live DOM, and returns per-step results with a SHA-256 chained audit trail.
See it live in 60 seconds
Alethia ships with a built-in demo app. Paste this into Claude Code:
Use alethia_serve_demo to start the demo server. Navigate to the app. Assert TaskFlow is visible. Type dev@company.com into the email field. Click Sign In. Assert "Signed in as" is visible. Click Delete and report what EA1 decides.
The agent starts a localhost server, drives the app with plain English, and EA1 blocks the delete. You'll see each step highlighted on screen in real time — green for pass, red for blocked. That last step is the point: your agent just tried to do something destructive, and the runtime stopped it without you lifting a finger.
Who this is for
Browser automation was designed for a world where humans write test scripts. AI agents that generate and verify code in real time are a different paradigm entirely: tighter loops, no upfront scripts, and consequences if the agent acts without guardrails.
AI agents need a tool built for that loop, not one adapted from something that wasn't.
That's what we built. vitron.ai
The runtime is patent pending (U.S. 19/571,437). The MCP bridge is MIT-licensed and auditable on GitHub. Questions or licensing: team@vitron.ai
Top comments (1)
This is a good distinction between browser automation for CI and browser runtime for agents. CI wants repeatable scripts and reports; agents want a tight perception-action loop. Once the browser state is part of the reasoning loop, latency becomes more than performance: it changes what the agent is willing to inspect before deciding.