In the minds of most developers, Cloudflare is still classified as a
traditional provider of CDNs, DDoS protection, and domain services,
seemingly having little overlap with the latest AI Agent architectures.
However, paying attention to its recent moves in the AI field reveals a
series of major infrastructure releases. These include Think
(@cloudflare/think, whose original Workspace was provided
by @cloudflare/shell), which focuses on agent sandbox
interaction, and the recently launched Cloudflare
Computer. These releases provide an excellent opportunity to observe
how Cloudflare is realizing a core truth: Context is the
decisive factor in determining whether an AI is truly useful or just
spouting nonsense. Looking back at Cloudflare’s product
exploration over the past nine years, it has been continuously moving in
this direction.
When Cloudflare released its edge computing service Workers in September 2017, the industry widely adopted Docker containers or lightweight virtual machines as Serverless vehicles. However, Cloudflare chose isolates based on Google’s open-source V8 JavaScript engine—the V8 Isolate—as its server-side computing runtime. A V8 Isolate is an independent heap memory and execution context inside the engine. Compared to containers that take hundreds of milliseconds to boot and consume dozens of megabytes of memory, an Isolate has a startup latency of under 5 milliseconds and a memory footprint of just a few megabytes. This allows tens of thousands of tenant code instances to run safely within a single server process. While this architectural choice was originally intended to allow developers to modify HTTP requests at edge nodes for free, it inadvertently established the first physical law for Agent runtimes: compute units should be extremely lightweight and disposable at any moment.
However, purely stateless Isolates could not support multi-turn conversations and complex, long-running tasks. In September 2020, Cloudflare introduced Durable Objects. Each Durable Object is a globally unique, single-threaded JavaScript object instance with its own dedicated, strongly consistent persistent storage. This single-threaded coordination mechanism—originally built to handle WebSocket real-time chat and multi-user collaborative editing—unexpectedly provided future Agents with a globally unique physical identity and strongly consistent private state. Starting in September 2024, Durable Objects built in embedded SQLite, giving each object a relational database of up to 10GB. From then on, an Agent’s persistent state found its native home. The houses built nine years ago for edge web acceleration had unwittingly assembled the two foundational cornerstones of the physical Agent platform: extremely low-cost disposable compute, and persistent state attached to objects.
Following the boom of Large Language Models, Cloudflare officially launched its official Agents SDK in February 2025. At this stage, the team’s conceptualization of Agents was very straightforward: since Durable Objects had physical identities and dedicated SQLite databases, developers only needed to write an ordinary code class (such as a Class inheriting from Agent) to easily create an agent.
The intuitive experience of this approach was excellent. Much like a
frontend developer writing a web component, you could use APIs like
setState and sql inside this Class to write
down the user’s conversation history. The platform would route each user
or task to an independent Durable Object instance based on a stable
identifier, preserving state across restarts. However, when coping with
real-world complex engineering, this mechanism of abstracting an Agent
as a code class exposed an obvious flaw: the original Agents SDK
did not natively build in closed loops for experience distillation,
skill promotion, or rule write-backs, leaving them to be implemented by
upper-layer applications or harnesses.
On one hand, although data could be persisted in any structure within the object’s private SQLite database, developers still had to manually query, select, compress, and project it into the model’s context. As explored in Agent Filesystem: From “Feeding Memory to Models” to “Letting Models Browse Files Themselves”, Large Language Models are naturally most proficient with Shell command lines and file systems during training. Faced with tables in a database, the application layer must write substantial boilerplate code to query and assemble the results into the Prompt—which is not only cumbersome but also prevents the model from inspecting data on demand. On the other hand, this code class runs in a constrained edge environment. When an Agent needs to compile code, run Python scripts, or execute heavy tests, the edge environment cannot support it. Conversely, if the task is offloaded to an external Linux container, the conversational memory remains stuck inside the code class, preventing smooth synchronization between the two.
Facing the limitations of code classes and database tables, we need to clarify what a Context Infrastructure that enables AI to continuously self-evolve actually looks like. As pointed out in What Would a ChatGPT That Doesn’t Wait for You to Ask Look Like?, for AI to transform from a passive Q&A tool into an assistant that proactively solves problems, the core lies in how context is organized.
First, files are the most natural medium for AI memory. How do human programmers accumulate experience? Not by memorizing all rules by heart, nor by storing them in complex database tables, but by organizing documentation, source code, and operational rules into folders. For LLMs, the file system is likewise the most natural memory interface.
Second, AI needs to modify files to achieve self-evolution. Context that can truly self-evolve typically consists of three clear layers: 1. Raw Observations and Logs (Contexts): Record the Agent’s specific actions, tool outputs, and error messages during task execution; 2. Modular Skill Guides (Skills): On-demand operational manuals that guide the Agent on how to use specific tools; 3. Distilled Principles and Rules (Rules): When the Agent encounters errors or receives human corrections, it distills the lessons into persistent rule files and writes them back.
When the next task starts, the Agent only needs to read the rule files first to directly avoid repeating the same mistakes. This points to a clear direction for Agent runtimes: the core is not to provide developers with a code framework for writing Agents, but to provide a file-centric context environment and allow this environment to seamlessly flow across different machines and containers.
Based on this insight, Cloudflare underwent a second shift in 2026: introducing a composable shared Workspace and multi-backend execution abstraction on top of the Agents SDK and Think, assigning Agents a shared working folder that can be synchronized on demand across different machines.
Launched in April 2026, Think took the lead in making this change by
building a virtual file system on top of persistent objects. This
allowed models to directly use tools like read,
write, edit, and ls to browse
files like a programmer. Cloudflare
Computer, released in August of the same year, further decoupled
this folder, enabling bidirectional incremental synchronization across
execution backends.
Specifically, when you write a bug report file inside a lightweight
edge Worker node, a background daemon process splits file changes into
512 KiB content-addressed chunks before/after command execution or upon
explicit invocation, incrementally syncing them to the working directory
inside a heavy Linux container. When the container executes code and
generates dozens of megabytes of test logs, these log files are synced
back chunk-by-chunk after execution ends. The Agent doesn’t need to
stuff dozens of megabytes of logs into the LLM’s context window;
instead, it uses grep directly in the shared folder to
extract the specific two lines containing the error. Context is no
longer long text inside a Prompt, but a real folder synced on demand
across different execution backends.
After understanding Cloudflare’s evolution journey, we need to dispel a key myth: using Cloudflare Computer does not mean your AI will miraculously self-evolve.
Cloudflare Computer is an open-source library built on top of Durable Objects, Dynamic Workers, and optional Containers. It provides a virtual file system and multi-backend execution orchestration, accomplishing file synchronization and mounting across backends. It solves storage and flow at the physical layer, but it does not solve evolution at the cognitive layer.
To enable Agents to truly achieve self-evolution, the key lies in how developers build Context Infrastructure on top of this shared folder: - Establish file hierarchies: Organize operational rules, tool skills, and historical logs into layers within the shared folder, allowing the model to read them on demand via paths; - Establish reflection write-back loops: As warned in Why Agents Need Context Governance, if files are merely synchronized across machines without designing mechanisms for the AI to automatically scan logs, distill lessons, and modify rule files, a long-running folder will still degenerate into a cluttered garbage directory.
For Agent architects, the future division of labor is crystal clear: avoid reinventing the wheel of physical synchronization at the low level, leave file transfer and machine synchronization to physical infrastructure like Cloudflare, and focus core effort on designing context governance and rule feedback loops that enable AI to self-evolve.