It takes a Cloudflare Durable Object and hands it batteries — memory, a clock, RPC, streaming, and the ability to survive a restart. Your code stops being a stateless function and becomes a long-lived entity.
A plain Worker is statelessEach request gets a fresh, memoryless instance. Nothing from the last request survives unless you push it to an external store.: every request spins up a clean instance that remembers nothing. That's perfect for a stateless API — and useless for an agent.
An agent needs three things a bare Worker can't give it:
→ Memory — a running conversation, a task list, a counter that persists between calls.
→ A sense of time — "ping me in 30 minutes", "run this every Monday 9am".
→ Resilience — to keep a multi-step job alive across a deploy or an eviction without re-doing finished work.
It builds on Durable ObjectsA single addressable instance with its own private, strongly-consistent storage — one per name. Cloudflare's primitive for stateful coordination at the edge.: one named, single-threaded instance per agent, each with its own private SQLite. The SDK wraps that primitive in an ergonomic Agent class so you write methods, not storage plumbing.
Every agent is one instance of a class extending Agent. Inside, this is alive between requests: this.state is your synced memory, this.sql is a private database, and a fleet of built-in methods give it a clock, a queue, and a line to every connected client. Hover the parts:
↑ hover a box to see what it does
A Worker is a vending machine — drop in a request, get a response, it forgets you instantly. An agent is a concierge with a desk: it knows your name, keeps your notes, will call you back tomorrow, and is the same concierge every time you return to that desk.
This is the heartbeat of the SDK. One agent owns the truth (this.state). Call setState() — from the server or any client — and the SDK persists it to SQLite and broadcasts the new state to every connected client's onStateUpdate. Operate it:
Try server −1 until the count hits 0, then again — validateStateChange throws and the write is rejected before anyone sees it. Each client also has its own +1 button; watch the value race back to the agent and re-broadcast to all clients.
State is the core, but the SDK ships a whole standard library for agents. Tap any capability to see what it's for and the API:
You never instantiate an agent yourself. A request comes in, routeAgentRequest reads the URL, and Cloudflare wakes (or creates) exactly the one instance named in it. Step through a request to counter/lobby:
The instance name is the identity. /agents/counter/lobby and /agents/counter/room-2 are two completely separate agents with separate state. Same name → same agent, every time, globally. Pick names deliberately (a user id, a room, a tenant).
The SDK moves fast. Here's the recent arc, newest first — the headline is v0.14.0, which leans hard into higher-level agent building blocks via @cloudflare/think:
The other through-line across these releases is durable chat recovery — making a streaming turn survive a deploy or eviction mid-flight. Toggle to see the difference:
You deploy a new version while an agent is streaming a long chat reply. With v0.14.0's hardened recovery, what happens?
The Agents SDK turns a Durable Object into a stateful, addressable AI agent: this.state is memory the SDK auto-syncs to every client, schedule() gives it a clock, workflows and fibers let it survive restarts, and one URL maps to one named instance. You write methods on a long-lived object — Cloudflare handles persistence, routing, and resurrection.