---
slug: cloudflare-os-xl-04-agents-as-infrastructure
title: "Cloudflare OS XL part 4: agents as infrastructure rather than as code"
kind: systems
status: published
hash: 8cf8cb3770184fa53d84d0d59aebb261e38d49814cad4d05776c8fe0b7aaaab2
created: 2026-08-06T03:24:47.475Z
updated: 2026-10-08T11:31:31.826Z
summary: "Cloudflare OS XL part 4: agents as infrastructure rather than as code"
tags: ["cloudflare","agents","durable-objects","mcp","infrastructure"]
above: []
below: []
adjacent: []
nested: []
---
# Cloudflare OS XL part 4: agents as infrastructure rather than as code

*Cloudflare OS XL part 4: agents as infrastructure rather than as code*

*Part 4 of [Cloudflare OS XL](/a/cloudflare-os-xl), an inventory of the Cloudflare platform this build does not have installed.*

This build already runs agents. There is an `AgentDO` Durable Object class, an agent registry with rows carrying prompts and model assignments, an `agent_turns` table recording what each one did, memory rows, a spawn path and a governor. That is a hand-rolled agent runtime, and it works.

The Agents SDK is Cloudflare's version of the same thing, and the interesting question is not "should this build have agents" — it has them — but which parts of the hand-rolled runtime are load-bearing and which are re-implementations of something the platform now provides.

## 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

| Product | What it replaces here | Verdict |
| --- | --- | --- |
| Agents SDK — scheduling | One shared cron firing every minute for all scheduled behaviour | **install** |
| Agents SDK — per-agent SQLite | Agent memory in shared D1 tables keyed by name | **install** |
| Agents SDK — turn loop, registry | The existing governor, prompts and turn ledger | **keep what exists** |
| Remote MCP server + OAuth | A stdio MCP bridge on one laptop | **install** |
| Hibernatable WebSockets | Polling an endpoint to watch agents work | **later** |

Next: [Part 5 — media](/a/cloudflare-os-xl-05-media).

## Facts

```json
{
  "converted_from": "markdown",
  "original_updated": "2026-08-06T03:24:47.513Z",
  "register": null,
  "category": "systems"
}
```

## Sources

1. [Cloudflare Agents SDK documentation](https://developers.cloudflare.com/agents/) — “Create stateful AI agents with persistent memory, real-time WebSocket connections, and scheduled tasks using the Cloudflare Agents SDK.” (sha256 356bc187c1631353)
2. [Workers for Platforms documentation](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) — “Run untrusted code from your customers or AI in secure, isolated sandboxes on Cloudflare's global network.” (sha256 ffda059e8aaee00c)