When discussing AI Agent infrastructure, people often assume that future software will expose a set of clean, elegant AI-native interfaces. But reality is often quite the opposite: tens of thousands of web applications, SaaS systems, and enterprise intranet software on the market will unlikely rewrite their APIs specifically for models for a long time to come. Facing this realistic gap, the industry has chosen a path that seems clumsy yet proves remarkably effective: directly letting Agents control browsers to take over existing applications. Cloudflare’s recently released Kitesurf is a headless browser infrastructure built specifically for this scenario: it allows Agents to control cloud web page rendering and interaction via a Chrome DevTools Protocol (CDP) endpoint compatible with existing tools, while reducing the massive overhead typically associated with traditional browsers to a lower level.
Graphical user interfaces have served as the underlying universal protocol for human-software interaction for decades. Modern web pages and desktop UIs constitute the most complete data flow network in the real world. The vast majority of online services provide a web page where ordinary people can click and read on a screen, offering this entry point even without open developer APIs.
When an Agent needs to span multiple software applications to complete complex tasks, expecting all service providers to proactively integrate REST APIs or Model Context Protocol (MCP) interfaces is unrealistic. Exposing APIs to the outside is far more than just writing a few endpoint lines; it involves heavy code refactoring, commercial compliance negotiations, security audits, rate-limiting and anti-scraping measures, as well as each company’s strict guarding of their core data moats. Rather than endlessly waiting for the ecosystem to adapt on its own, directly letting Agents manipulate web pages is often the lower-cost adaptation path when APIs are unavailable.
Browsers have thus naturally become the compatibility layer with the widest coverage for Agents operating existing software. As long as a feature is visible and clickable on a web page, an Agent has the opportunity to take over operations. This compatibility layer does not require waiting for application vendors’ cooperation and directly reuses existing internet infrastructure.
This compatibility layer will stay with us for a long time. For the vast majority of SaaS and Web vendors, human subscriptions and ad clicks are direct sources of revenue, while building dedicated API Key distribution, billing, and authentication systems for AI requires additional investment. Lacking direct commercial incentives, vendors prefer to maintain their existing Web interfaces. As long as web pages remain the main channel for software delivery, the status of browsers as universal adapters will be hard to shake. Faced with this reality, transforming the browser into a compute channel suitable for Agent invocation becomes a natural path forward in engineering.
However, once this model is pushed from laboratory exploration to large-scale production environments, the burdens and bottlenecks in the underlying architecture quickly explode.
This architectural burden stems from the design premise of traditional browsers: engines like Chromium were all built around human physiological characteristics and behavioral patterns. When the accessing entity changes from a human to an Agent, two fundamental mismatches explode at the requirement level.
The first mismatch is between scalability and concurrency demands. A human user has only one focus of attention at a time, only one mouse in hand, and only one pair of eyes. Even power users can only type or browse in one active tab at a time, with the remaining dozens of background tabs essentially remaining idle or suspended. But for Agents—as execution entities that can scale elastically—their advantage lies precisely in concurrent throughput. An Agent not only needs to open dozens or even hundreds of web pages simultaneously, but also needs to continuously extract structured data, trigger interactions, and monitor status changes across these pages. In front of web pages, an Agent is a multi-tasking entity constantly in a high-frequency interaction state, unlike background-suspended human tabs.
The second mismatch is between functional requirements and the allocation of redundant optimizations. A significant portion of modern Chromium’s extra resource overhead consists of advanced optimizations developed over decades specifically for human visual experience and rich media: memory-heavy GPU layer texture compositing and WebGL/WebGPU rendering pipelines for smooth 60fps scrolling and 3D animations in human eyes; V8 JIT optimization compiler stacks with multi-tiered compilation pipelines and Inline Caches for JS execution speed; multi-process sandbox skeletons that allocate rendering processes per site via Site Isolation for crash protection and cross-site security; and built-in WebRTC and audio/video decoding protocol stacks for multimedia integration.
These optimizations make great sense for humans, but for many Agent workloads, they are not strictly necessary and instead bring an extra resource burden. Kitesurf targets short-lifecycle, bursty tasks such as screenshots and HTML extraction, which do not require 60fps scrolling, GPU 3D texturing, or audio/video streams. Of course, Agent requirements are not always this simple; some require long-term authentication, complex rendering, or anti-scraping defenses, for which Cloudflare explicitly recommends falling back to Chromium.
When the high-frequency, concurrent throughput demands of Agents collide with Chromium’s heavy architecture customized for human vision and rich media, resource overhead quickly stacks up. Chromium’s multi-process model typically incurs hundreds of MiB in task memory: Cloudflare’s own comparative benchmark measured a warm Chromium pool occupying 271.0 MiB and 273.7 MiB for screenshot and HTML extraction tasks, respectively. In actual deployment, specific memory usage depends on page complexity, process reuse, and site isolation policies, but RAM often becomes the bottleneck before CPU. Once business request volume spikes, hundreds or thousands of OS processes quickly blow past cgroups limits, triggering the kernel’s OOM Killer due to memory exhaustion to directly kill running browser processes—manifesting in upper-level business logic as mysterious request timeouts or task disruptions.
Individual developers struggle to handle high-concurrency Agents on a single server, and cloud infrastructure providers face heavy compute burdens as well.
To address the scalability bottlenecks mentioned above, Cloudflare’s Kitesurf offers a very intuitive problem-solving path: since Agents do not need human eyes, strip away all advanced optimizations meant for human viewing; since running Chrome locally on a single machine is too resource-intensive, offload the heavy work of rendering directly to a distributed edge network.
In terms of implementation, Kitesurf chose not to port Chromium’s source code of tens of millions of lines; instead, it directly compiled a lightweight rendering engine developed in Rust into WebAssembly (WASM) and ran it inside the V8 Isolate environment of Cloudflare Workers. In this way, the system completely sheds the heavy skeleton of the operating system multi-process model, turning page rendering and data extraction into lightweight invocable components. Cloudflare claimed in 2018 that typical Workers isolates can start in about 5 ms, though this is a platform-level startup metric rather than a benchmark for Kitesurf’s full page context lifecycle.
Even better is the shifting of compute and memory pressure. Previously, using Playwright or Puppeteer required running heavy Headless Chrome on our own computers or servers. Kitesurf, however, shifts the most resource-intensive operations—DOM parsing, CSS layout, and rasterization computations—to Cloudflare’s global network, which claims coverage across 330+ cities. Requests are routed to the nearest PoP, where relevant Workers and isolates collaborate to complete the rendering. Locally, one only needs to maintain extremely lightweight signal orchestration and CDP protocol handshakes, directly offloading true memory and compute consumption to the cloud.
This architectural refactoring reflects a very clear trade-off in engineering metrics. The following numbers all come from Cloudflare’s own benchmark: 14 URLs, 5 runs each taking the median, compared against Cloudflare’s own warm Chromium pool, with no independent third-party replication to date. In this benchmark, single-page memory consumption when extracting HTML data is only 39.4 MiB, compared to 273.7 MiB for warm Chromium—roughly 7 times lower—with CPU savings of 3.8 times; when rendering screenshots, memory is 57.8 MiB, a 4.7-fold reduction. Of course, there is no free lunch. Because Kitesurf uses a cold-started software renderer while the baseline Chromium enjoys a warm JIT advantage, Kitesurf’s end-to-end latency for screenshot capture is 1,148 ms, about 1.8 times slower than Chromium’s 637 ms, with the gap primarily coming from rasterization and JPEG/PNG encoding.
At the same time, regarding functional boundaries, Kitesurf currently explicitly does not support video playback, WebGL 3D rendering, or bot challenge handshakes that require real TLS fingerprints, nor is it suitable for authenticated sessions requiring long-term persistent state. Some of these are currently unimplemented capabilities, while others are trade-offs stemming from a short-lifecycle, largely stateless design, rather than being strictly prohibited by the Workers security model. But for high-concurrency, short-lifecycle data extraction tasks, trading slower response latency for significantly lower CPU and memory is often a worthwhile trade-off in systems engineering. Actual concurrency density and cost-efficiency still need to be verified against specific workloads. Kitesurf effectively creates a stripped-down Web channel for Agents without visual overhead.
Kitesurf’s exploration actually outlines a pattern: to transform existing legacy software into infrastructure suitable for Agents, the most effective approach is often to redesign the underlying compatibility layer. Looking back at the evolution of isolation technologies from this perspective, there are two parallel lineages. One is endpoint-side hardware isolation: in 2010, Bromium used Intel VT-x hardware virtualization to spin up a microVM for every browser tab and download. The other is Remote Browser Isolation (RBI): moving the entire browser to the cloud, initially streaming rendering results back via pixel streams, and later evolving into DOM tree reconstruction and Network Vector Rendering (NVR).
Today, Kitesurf introduces a new execution granularity at the language runtime boundary of the V8 isolate. However, it does not replace OS processes and system sandboxes—the Workers security model still stacks process grouping, Linux namespace/seccomp, and outbound proxies outside the isolate, forming a layered security boundary in production. A similar idea is reflected in desktop GUI automation. Many Agents prioritize structured semantics from DOM or Accessibility trees, using screenshots and VLMs only when structure is unavailable or visual information is critical. After all, the Accessibility tree natively carries control hierarchies and semantic tags, making an Agent’s overhead for reading and writing software state far lower than analyzing pixel images.
However, this solution of refactoring the compatibility layer to boost machine efficiency quickly collides with a deep-seated real-world contradiction: the long-term game between adaptation efficiency and ecosystem security.
Take Accessibility interfaces and headless automation channels for example: from the perspective of Agent developers, they are undoubtedly shortcuts with lower interaction costs. But in the eyes of application vendors, these automated interfaces that bypass visual UI share many technical signals monitored by anti-automation systems: headless, high-speed, repetitive, non-human interaction patterns. Therefore, determining intent based solely on protocol and headless signatures is often difficult. To protect user privacy, safeguard ecosystem security, and maintain data assets, some applications limit or detect automation channels with non-human gestures.
This contradiction manifests particularly starkly with Cloudflare. Cloudflare claims its overall network sits in front of about 20% of the web, with Bot Management utilizing this network visibility to detect and block automated crawlers; on the other hand, Cloudflare is the driver behind Agent browser infrastructure like Kitesurf. When an Agent accesses web pages at high frequencies via Kitesurf, traffic is sent out through the SandboxOutbound worker; while its exact externally visible TLS fingerprint awaits empirical verification, official sources have explicitly stated that Kitesurf currently cannot handle bot challenges requiring real TLS fingerprints. This creates an unresolved question: how Kitesurf traffic will be classified by Cloudflare and other anti-automation systems currently lacks published benchmarks or policy answers. At the protocol handshake stage, security systems can hardly discern whether the initiator is a benevolent AI assistant or a malicious scraping script.
As long as the existing software ecosystem has not fully shifted toward an AI-native form, this attack-and-defense confrontation between boosting Agent efficiency and vendor anti-automation defenses will persist. Kitesurf attempts to alleviate conflicts via edge mediation and component decoupling, but finding a balance between machine interaction efficiency and security boundaries remains an unavoidable deep-water topic in the evolution of Agent infrastructure.