TypeScript at the edge

01 Isolate

A traditional serverless function runs inside a virtual machine or a container, and both carry a boot cost: real time spent before your code executes for the first time. Workers skip that step. A V8 isolate isn't a small VM — it's the sandbox Chrome uses to keep one tab from touching another, and Cloudflare runs one per request instead of one per tab. There's no machine to boot and no container to schedule, so execution starts in under a millisecond, on whichever edge location the request actually reached.

TypeScript's job here isn't stylistic. A Worker's binding surface — the other services, storage, and models it's wired to — is a contract that has to hold at every edge location it runs at, with no shell to attach a debugger to after the fact. Compile-time types catch a broken binding or a malformed API contract before it ships everywhere at once, which matters more on a runtime built to be distributed and stateless by default than it does on a single server you can just log into.

02 State

Isolates are disposable by design, which is fine until a request needs to remember something — a WebSocket connection, a session, the current state of a coordination problem shared across users on different continents. Durable Objects are the answer: stateful V8 isolates with strongly consistent, in-memory storage, each one addressable by an ID that always routes back to the same instance. That's what makes real-time apps, WebSockets, and coordinating distributed state possible on a runtime whose default unit of compute has no memory of the last request.

03 Agents

The same properties that make Workers cheap for stateless HTTP handlers make them plausible as an agent runtime. An isolate is lightweight and cheap enough that running thousands of distinct agent profiles — each one waking up only when a webhook or API call arrives — is a reasonable default instead of a scaling problem. That's the premise behind the Cloudflare Agents SDK: type-safe agents that run on Workers and get distributed database integrations, stateful coordination through Durable Objects, and native bindings to AI models, without a separate server sitting idle to keep warm.

Trace one request through that stack and the hops are always the same three: it lands on an isolate at the edge, the isolate reaches into a Durable Object for whatever state it needs to remember, it calls out to a model through a native binding, and the response leaves from the same edge location it arrived at. Nothing routes back to a home region in the middle.