The architecture diagram shrank

Cloudflare's most telling launch this week is, of all things, a cache. One configuration block, normal Cache-Control headers, no second product to provision.

{  "cache": {    "enabled": true  }}

The Workers Cache announcement says it plainly: no zone, no rules engine, no separate cache to stand up. The cache belongs to the Worker and follows it across entrypoints. That's the pattern I keep noticing with Cloudflare lately — every few weeks another box disappears from the architecture diagram.

The seams are the strategy#

None of these ingredients is rare on its own; what's interesting is how close they sit to each other. A request comes in through a Worker, a globally named Durable Object owns the state (with its own SQLite database attached), and when an isolate is too small, a Sandbox supplies a shell and a filesystem. Generated code goes to a Dynamic Worker, which runs it behind narrow bindings instead of handing it your secrets.

Cloudflare's Agents Week summary spells out the intended range: everything from lightweight isolates up through full operating systems, with identity, security, models, tools, and production deployment wrapped around them. Sandboxes and Containers are now generally available, and a named Sandbox sleeps when idle, wakes on demand, keeps its workspace, and can receive credentials through an egress proxy without ever showing them to the agent.

The stateful middle is the clever part. A Durable Object gives you one globally addressable identity with strongly consistent storage underneath, which means you stop gluing together a function, a lock service, a database, a sticky router, and a recovery process for every little actor in the system. The primitive already thinks in the unit your application cares about: this room, this document, this tenant.

And the pieces are arranged so the output of one is the natural input of the next. That arrangement, as far as I can tell, is the actual strategy — not any single product.

The awkward workload found its cloud#

Agents fit badly into the old split between short stateless functions and always-on virtual machines. They're stateful but mostly idle. They live for weeks, do everything in bursts, and every so often one needs a real browser, or a terminal, or somewhere safe to run code it wrote five seconds ago.

Cloudflare's long-running agent model treats the agent as something that exists continuously but runs intermittently: the Durable Object hibernates, keeps its SQLite state, and wakes when a message arrives. If the task needs Linux, the agent reaches into a Sandbox. If it generates a small program, a Dynamic Worker can execute it with scoped RPC capabilities and filtered network access. The whole progression feels like one runtime changing gears.

Still, the rest of the cloud spent years selling assembly as flexibility. Cloudflare's bet is that developers would rather program the application than maintain the seams around it, and every launch that turns another infrastructure box into a binding makes that bet look a little less reckless.

The insight underneath all of it is that nobody wants to own the glue. When routing, state, durable work, browsers, containers, and generated code share one control plane, the architecture diagram stops looking like a procurement receipt and starts looking like a program.