Stories
Rendering is not understanding
11 August 2026 by Matt Gibbs
An agent browser can render every tested page successfully and still miss what the website is trying to tell the agent.
That was the most useful finding from a small comparison I ran between Cloudflare's new Kitesurf browser and Chromium.
Cloudflare introduced Kitesurf as an early browser engine designed for agents rather than people. It runs on Cloudflare's serverless platform and aims to handle common agent jobs with less computing power than Chromium. That is an interesting direction. If agents are going to inspect millions of pages, the cost of running a full human browser for every task matters.
But Open for Agents needs a browser to do more than turn a page into text. It also needs the browser to recognise the explicit capabilities a website has chosen to provide: typed tools, declarative forms, and the lifecycle that keeps those capabilities attached to the correct document.
So I tested both engines on the same nine public pages.
The result was not a simple win or loss. Kitesurf successfully rendered and extracted every page. Chromium did too. The important difference appeared one layer deeper.
What I compared
The test used public pages from Open for Agents, the Open for Agents demo and GTABoom. It included ordinary content pages, a storefront, and two interactive creative demos.
Both engines ran through Cloudflare Browser Run. The comparison covered:
- final page status, URL, title and main heading;
- critical server-rendered and JavaScript-enhanced content;
- screenshots and Markdown extraction;
- redirects, iframes, console and network failures;
- browser-native WebMCP registration;
- server-side discovery documents as a separate check;
- tool duplication and cleanup after navigation; and
- load times and the browser time reported by Browser Run.
Nothing was submitted or changed. No forms or tools were executed. There were no model calls, accounts, customer data or authenticated journeys.
This was also a small test, not a universal browser benchmark. The figures describe these nine pages on 10 August 2026. Each page was measured once, followed by an immediate repeat Markdown request to check cached consistency. They should not be stretched into claims about every workload or interpreted as a statistically repeated performance benchmark.
Both browsers passed the visible web test
Kitesurf and Chromium each returned a successful final response for all nine pages. Both preserved the expected URL, page title, main heading and critical public content. Both produced nine screenshots and nine Markdown documents.
Immediate repeat Markdown requests returned the same content in each engine. The server-rendered Open for Agents pages had identical main text lengths. The small differences on GTABoom came from dynamic page furniture rather than missing article content.
Kitesurf therefore did the basic job well. It read the web pages it was given.
That matters because the conclusion is not that Kitesurf cannot browse. It can. The question is whether it currently gives Open for Agents an advantage over the browser we already use for testing.
Chromium was faster in this workload
Kitesurf started slightly faster, but Chromium reached usable content sooner and Browser Run reported less browser time for Chromium across the nine pages.
| Measurement | Kitesurf | Chromium |
|---|---|---|
| Successful pages | 9/9 | 9/9 |
| Screenshots | 9/9 | 9/9 |
| Markdown documents | 9/9 | 9/9 |
| Mean page load | 995 ms | 586 ms |
| Mean settled inspection | 4,133 ms | 2,419 ms |
| Mean first Markdown response | 2,569 ms | 1,162 ms |
| Reported Markdown browser time | 19,989 ms | 7,323 ms |
| Complete nine-page comparison | 42.7 s | 27.8 s |
Cached repeat extraction was effectively equal at about 47 milliseconds for Kitesurf and 45 milliseconds for Chromium.
On these pages, Chromium was about 1.7 times faster to settled content. Browser Run reported roughly 2.7 times as much Markdown browser time for Kitesurf.
I did not have engine-level CPU or memory measurements. Cloudflare's argument for Kitesurf includes lower resource use, and this experiment does not disprove it. It found something narrower: on these public pages, the measurements available to me did not provide a reason to switch.
The decisive difference was WebMCP
The interactive demo pages expose capabilities in two ways.
Sixteen tools are registered imperatively through a browser API. The pages also contain declarative tools: five on the Buddy page and six on the Kitchen page. Those declarative tools are ordinary forms that carry structured information telling a compatible agent what they do and which inputs they accept.
Chromium's experimental native WebMCP surface found both kinds.
On Buddy it reported 21 unique tools: the 16 imperative tools plus five declarative tools. On Kitchen it reported 22: the same 16 imperative tools plus six declarative tools. No names were duplicated. After navigating away, none of the previous document's tools remained.
The Kitesurf view available during this test did not provide the same native WebMCP interface.
Code supplied by the site made the 16 imperative tools visible, but the declarative tools were absent from the list available to the agent. The forms were present in the HTML and rendered successfully, but they did not appear as tools.
That is the central result:
A browser can read the page and still miss its capabilities.
Site code and browser support are not the same
The distinction between native support and compatibility code matters.
The site's compatibility code allowed the imperative tools to appear, which is useful as progressive enhancement. It also exposed older shapes such as navigator.modelContext and unregisterTool(). The Chromium lab build used in this test instead exposed the newer document-scoped interface.
This is not evidence of a security failure. Nor is it a reason to criticise an early beta for not implementing an emerging browser API.
It shows why site code cannot prove what the browser supports on its own. A useful comparison has to identify which capabilities came from the browser and which came from the website. Otherwise partial support can look complete when it is not.
Server-side discovery is a different question
The same demo also publishes three public discovery documents. All three returned successfully with stable content during the test.
That proves the server-side discovery surface was healthy. It does not fill in the missing browser-native registrations.
Server-side discovery and WebMCP solve related but different problems. A remote agent may use published discovery documents to find server interfaces. A browser agent can understand capabilities attached to the document it is currently viewing through WebMCP. One does not automatically prove the other.
That separation is part of the Open for Agents architecture. The website owner's reviewed catalogue is the source of truth. MCP, WebMCP and the optional Assistant are different projections of that catalogue. Each projection still needs to preserve the capability accurately.
What “built for agents” should mean
It is tempting to define an agent browser as a cheaper way to get HTML, screenshots or Markdown.
Those are useful primitives, but they are not the whole interface.
A website may have already done the work to describe its useful actions explicitly. It may have named a tool, typed its inputs, bounded its output, marked it read-only or transactional, and attached it to the lifetime of a particular document. Ignoring that interface forces the agent back towards inference: inspect the page, guess which element matters, and hope the page has not changed.
An agent-ready browser should preserve the web's explicit capability layer as well as its visible content.
That does not make extraction unimportant. It means extraction and understanding are different jobs.
What this means for Open for Agents
For now, Open for Agents will continue using Chromium for browser testing, WebMCP inspection and agent journeys.
Kitesurf reliably completed the rendering and extraction workload, but it gave us no practical advantage on these pages. It was slower in the measurements we could make and it did not expose the declarative WebMCP capabilities that Chromium found natively.
We are not adding Kitesurf yet, but the idea remains interesting.
There are two clear reasons to revisit it:
- Kitesurf gains native WebMCP support for imperative and declarative tools with correct document-lifecycle behaviour.
- A genuinely high-volume extraction workload shows that lower CPU or memory use outweighs the latency and browser-time results we observed.
Both can be tested when the technology develops further. There is no need to speculate in the meantime.
The larger lesson
Kitesurf is a useful sign of where the web is going. Agent workloads are becoming important enough to justify browsers designed around their needs.
But the needs of an agent are not limited to cheaper rendering.
The web is beginning to gain explicit interfaces for agents. The browser should not flatten those interfaces back into pixels and prose.
Rendering the page is not the same as understanding what the page has chosen to offer.