Cloudflare splits Agents state into an opt-in capability

Cloudflare's Agents framework released version 0.24.0 on September 18, breaking the core Agent class apart into separate capabilities instead of one bundled base class, per the release notes. The headline change is a new State capability: it owns the cf_agents_state row, handles validation, persistence, and change ordering, and any host that implements the Lifecycle interface can use it without inheriting Agent at all.

That matters if you've built on plain Durable Objects and wanted Agent-style state without pulling in the whole class hierarchy. Before this release, durable validated state meant buying into Agent. Now it's a capability you attach.

The release also adds a Queue capability. Push an item and it becomes a durable job with its own retry policy, a deadman timer, and a memory-limit rule, all running off the alarm loop rather than the request that enqueued it. That's a real behavior change: a queued callback no longer has access to the connection that queued it. Code written on the assumption that request context carries through to the callback will fail once jobs actually retry.

Two more pieces round out the release. WebSockets now speak the Agent protocol on plain Durable Objects, extending Agent-style connection handling beyond Agent itself. And a Cap'n Web transport turns an RpcTarget result into a live stub with pipelined calls, cutting round trips for chained RPC.

The pattern across all four changes is decomposition. State, queueing, transport, and WebSocket handling are becoming capabilities you opt into individually rather than inherited behavior. If you're running Agents in production, check anything that reads request-scoped data inside a queued handler. That's the part most likely to fail without a stack trace pointing at the real cause.