Cloudflare's Matt Carey Gives Every AI Agent a Workspace and a Browser

Agents Now Have Their Own "Computer"

At a recent WorkOS init() event, Cloudflare's Matt Carey demonstrated a thought-provoking AI agent setup: he ran a Pi-based agent persistently inside a Durable Object, then equipped it with a stateful workspace and a browser called Kitesurf to actually operate web pages.

The core message of this demo is simple but significant: Agents are no longer just "answering questions" — they're starting to have their own execution environment — a workspace to store things in, and a pair of "hands" to click around pages.

Breaking Down the Three Key Components of This Demo

Durable Object: The Agent's Persistent Identity

Cloudflare's Durable Object is a stateful compute unit, naturally suited to host agents that need to "remember themselves." Traditional serverless functions are stateless on every invocation — if an agent wants to remember context, it has to shuttle data back and forth via external storage. A Durable Object, by contrast, makes the agent itself a long-lived entity whose state travels with it.

Carey's choice to put a Pi agent inside one means this agent can maintain its own memory and execution history across multiple interactions, instead of starting from scratch every time.

The stateless nature of serverless is the background for understanding the value of Durable Objects. Traditional FaaS (like AWS Lambda, or normal request handling on Cloudflare Workers) runs each invocation in a fresh isolated environment; memory is reclaimed once the function finishes, and any data that needs to survive across calls must be explicitly written to external storage (databases, KV, object storage) and read back next time. This is efficient for stateless APIs, but becomes a burden for agents that need continuous memory: every turn of conversation, every step of a task has to serialize and deserialize the entire context, and concurrent write conflicts must be handled.

Durable Objects take a different path: it's a single-threaded, stateful instance with a unique ID, whose state can reside in memory and is automatically persisted to a storage backend, and requests with the same ID are routed to the same instance and processed serially. This naturally solves the agent's problems of "identity continuity" and "concurrency consistency" — the agent is no longer a function that starts from zero each time, but an entity that can persist and process messages in order. Understanding this makes it clear why it's seen as an ideal foundation for hosting agents.

Stateful Workspace: The Agent's "Hard Drive"

Giving an agent a workspace essentially means giving it readable, writable persistent storage. This isn't just a simple memory buffer — it's a file-system-like structure where the agent can write files, organize data, and read back previous results on its next run.

This matters enormously for real tasks. If an agent can remember "I already cleaned the data up to this step last time," it can continue from there instead of repeating everything.

An agent's context window and persistent storage are two different things — a common point of confusion for people new to agent development. The context window is the range of tokens the model can see in a single inference; it is inherently volatile, capped, and must be refilled on every call. A workspace is external persistent storage whose capacity far exceeds the context window and which doesn't disappear when a call ends.

The relationship is similar to CPU cache versus disk: during inference, the model loads only the most relevant fragments of the workspace into context, leaving the rest on the "hard drive." This is the core of the "memory" mechanism — the agent organizes long-term state by reading and writing the file system, and uses retrieval or summarization to temporarily pull needed information into context. Without a persistent workspace, an agent can only stuff everything into a limited context; once it overflows, it can only truncate or forget — making it hard to take on long-horizon, multi-step tasks.

Kitesurf Browser: The Agent's "Eyes and Hands"

The most visually compelling part of the demo is the agent driving web pages via the Kitesurf browser. This means the agent can actually operate external systems — open pages, read content, perform clicks and typing — rather than just generating text for a human to follow.

Browser operation turns the agent from an "advisor" into an "executor."

Browser automation is the universal interface connecting agents to the real world. Compared to writing separate API integrations for each service, browser operations offer generality: as long as there's a web page, the agent can open it, parse the DOM, click buttons, and fill out forms — no official API required from the target system. This is in the same lineage as the recent wave of "computer use" capabilities, just focused on the web as the most universal human-computer interface.

But browser automation also brings new engineering challenges: page structures change, operations may trigger asynchronous loading, login state and anti-bot mechanisms must be handled, and every click has real side effects, so the cost of mistakes is high. In production environments, therefore, browser capabilities are usually combined with sandbox isolation, operation replay, and human fallback mechanisms. Kitesurf's role in this setup is to push the agent from "generating text for people to execute" to "doing the work itself."

Why the Trio Only Works Together

Individually, none of these components is novel, but together they point to a clear pattern: persistent identity + persistent storage + real execution capability = an agent that can work independently.

Without a Durable Object, the agent wakes up with amnesia every time. Without a workspace, what it does can't be kept. Without a browser, it can only talk theory. Only when all three stack up does it become possible for an agent to take on tasks that are multi-step, cross-session, and involve interaction with real systems.

From an engineering perspective, this direction also explains why edge computing platforms like Cloudflare are investing in agent infrastructure — running agents closer to users and data, while using stateful compute to solve their "memory" problem, is a very natural combination.

What This Means for Developers

If you're building agent applications, the signal from this demo is direct: rather than repeatedly stitching together state management and tool calls at the application layer, deploy the agent itself as a stateful service.

Durable Objects provide that deployment form, while the workspace and browser provide the capability interfaces. This layering approach may be more maintainable than stuffing all logic into a single prompt loop, and closer to the demands of real production environments.

Carey's demo was small in scale, but it brings several key pieces of agent infrastructure together. It's worth watching how Cloudflare productizes this direction going forward.

One-line Summary

Cloudflare demonstrates how Durable Objects, workspaces, and browsers give agents persistent identity and real execution power.

Paragraph Summary

The article covers a demo by Cloudflare's Matt Carey at a WorkOS init() event: he runs a Pi-based agent persistently inside a Durable Object and equips it with a stateful workspace and a browser called Kitesurf. The article breaks down these three components — the Durable Object provides persistent identity across interactions, the workspace serves as the agent's persistent "hard drive," and the browser lets it actually operate web pages, turning it from an advisor into an executor. The article emphasizes that none of these components is novel on its own, but together they point to a clear pattern: persistent identity plus persistent storage plus real execution capability is what makes an agent capable of independently handling multi-step, cross-session tasks. It concludes that the takeaway for developers is to deploy agents as stateful services rather than repeatedly stitching together state management and tool calls at the application layer.