Why this matters
An agent browser cannot enter an enterprise environment on automation speed alone. Actions must cross policy classification and approval boundaries before execution, and those controls must remain responsive enough for real interaction.
This report isolates where control overhead appears when observation, classification, parking, approval, and execution are connected inside the engine. It is a finished-path architecture measurement—not a blanket performance claim for an entire product.
Key takeaways
- 01
The semantic snapshot path remained around 14–16ms within the tested fixture range.
- 02
The governed cycle from observation through approved dispatch completed in under 25ms of engine time.
- 03
Serializing the DOM across an external boundary can be a larger structural cost than the approval gate itself.
- 04
Debug-build fixture measurements do not substitute for production performance on the open web.
We began with the view that much of browser automation latency comes from the boundary around the engine. Serializing the DOM outward, interpreting it in an agent runtime, and injecting an action back into the browser adds work at every transition.
Our alternative adds an engine-driven API through an additive Chromium patch series. Because the semantic snapshot path lives inside the engine, the tested fixture sizes remained in the same approximate 14–16ms band.
The central result is that control did not dominate the tested path. The observe→classify→park→approve→dispatch cycle remained below 25ms of engine time, with less than 2ms between approval and dispatch.
These figures come from a debug build and controlled fixtures. Production optimization, real-page complexity, network variance, and model latency can change the result. We do not extrapolate the measurements beyond the stated boundary.
Decision implications
Evaluating an agent browser requires more than comparing model token speed. The observation path, policy-decision point, approval boundary, and transition into execution should be measured as one system.
Organizations that require human approval in interactive work should validate actual pre- and post-approval latency and failure states, not merely the presence of an approval feature.
Methodology
Controlled fixtures of different sizes were run repeatedly on the same debug build. Engine timestamps separated snapshot, observe→classify→park→approve→dispatch, and approve→dispatch intervals.
Reported values summarize representative internal ranges and exclude network round trips, model inference, and final rendering. Each metric repeats its exclusion boundary.
Measurement conditions
- Semantic snapshot latency
Internal debug-build measurement on controlled fixtures. Production builds and real pages may differ.
- Governed cycle (observe→classify→park→approve→dispatch)
Engine time only. Excludes network and rendering time. Internal debug-build measurement.
- Approve→dispatch
Engine time only in an internal debug build.
Limitations
The measurement does not cover production builds, the full distribution of real pages, long-running sessions, network latency, or model latency. “Flat” refers only to the tested fixture range.
The report therefore does not establish superiority over a named automation product or claim an end-to-end response time for customer workloads.
References
- LLM-native browser technical note
Design background for engine-native observation, action, and policy boundaries.
- AI security and governance
Patty principles for separating approval, execution, and evidence.