Cloudflare OS: agents as infrastructure

The Agents SDK

The SDK creates stateful agents with persistent memory, real-time WebSocket connections and scheduled tasks. Each agent is a Durable Object: it owns SQLite storage, it can be addressed by name, it survives restarts, and it can schedule itself.

Four things it provides that the current arrangement does not:

Per-agent scheduling. An agent can call this.schedule(delay, 'methodName', payload) and be woken up later. Today, everything scheduled in this build goes through a shared cron trigger firing every minute, which then decides what is due. That single cron is a queue, a scheduler and a dispatcher in one, and every scheduled behaviour in the system is coupled to it. Per-agent alarms decouple them.

State as a first-class field. The SDK gives an agent a synchronised state object and a SQL interface over its own storage. The current build stores agent memory in shared D1 tables keyed by agent name — which works, and which also means an agent's memory is only as isolated as the query that reads it.

WebSockets with hibernation. An agent can hold a live connection to a client and hibernate while idle, paying nothing for the wait. Long-running conversations currently reconnect through HTTP on every turn.

A defined turn loop. The SDK's onMessage, onRequest and callable-RPC surface is the shape this build wrote by hand in AgentDO.

The honest verdict is not "replace the agent runtime". It is narrower: adopt the scheduling and the SQLite-per-agent storage; keep the registry, the prompts, the governor and the turn ledger. Those last four are where this build's actual thinking lives — a law-bound prompt, an adjudication panel, a hash-chained record of what each model did — and none of them are things the SDK provides or should.

Verdict: adopt in part. Scheduling and per-agent state: yes. The registry and governance layer: keep what exists.

Remote MCP servers with OAuth

This build's tool surface is already an MCP server. It runs locally, over stdio, through a bridge on the owner's machine, and it is reachable by exactly the clients configured on that machine.

Cloudflare hosts remote MCP servers as Workers, with workers-oauth-provider handling the authorization flow. The server becomes a URL. Any MCP client — Claude, an inspector, another agent, a partner's tooling — can attach to it by signing in, and the OAuth layer decides what each caller can see.

Three consequences for this build specifically.

The bridge stops being a single point of failure. Same argument as Part 3: capability that lives on a laptop is offline when the laptop is.

Scope becomes structural rather than conventional. This build has one act-scoped token that can edit articles and call every tool, plus a separate admin key. That is a deliberate design and it is documented. But it is enforced by the token check inside each handler, not by the protocol. An OAuth-fronted MCP server can present a different tool list to a different principal, which is a stronger form of the same idea.

The build becomes attachable. Its whole premise is that work is an object other agents can lease and act on. A public, authenticated MCP endpoint is the most direct expression of that premise available.

Verdict: install. This is the most on-thesis item in the entire series.

Hibernatable WebSockets

Worth separating from the SDK, because it applies to Durable Objects generally and this build already has three classes.

A Durable Object holding a WebSocket normally stays in memory for the life of the connection. With the hibernation API, the DO can be evicted while the socket stays open, and is revived when a message actually arrives. The cost of an idle connection goes to approximately nothing.

The build has an obvious use: a live view of what agents are doing. Right now, watching the build work means polling an endpoint or reading a ledger tail. A hibernatable socket makes a push feed cheap enough to leave open indefinitely.

Verdict: later. Real, cheap, and not urgent until there is a surface that wants to watch.

What this part does not recommend

Do not rewrite AgentDO onto the SDK wholesale. The temptation with a well-designed framework is to adopt all of it, and the parts of this build's agent layer that look like re-implementation are mostly not. The governor, the adjudication panel, the law-bound prompts and the turn ledger encode decisions that took months of corrections to arrive at. A framework migration that quietly drops them would be a regression wearing the clothes of an upgrade.

The rule to apply: adopt the platform where the platform provides mechanism — scheduling, storage isolation, connection handling. Keep what encodes judgment.

Verdicts

Next: Part 5 — media.