Cloudflare Just Open-Sourced What I Built at Home

I work at Cloudflare. Last week our team open-sourced our internal AI agent platform. The architecture is almost identical to the personal agent I built at home over the past year. Here is what I learned from that comparison.

I work at Cloudflare. Last week the team published a blog post announcing Cloudflare OS — our internal AI agent platform, now open source. I opened it expecting to learn something new about how Cloudflare builds things internally.

Instead I got that particular uncomfortable feeling of recognizing your own work in someone else’s diagram.

What Cloudflare OS is

The short version: it’s a platform for running AI agents on Cloudflare infrastructure. Agents that can browse the web, interact with external services, remember things, run on a schedule, and operate inside a security boundary where every access is logged and nothing is assumed to be trusted.

It runs on Durable Objects. State lives in SQLite. External service access is handled by separate Workers called Gatekeepers, one per service. There’s a browser interface built over WebSocket RPC. Context documents feed the agent knowledge at query time. Scheduled tasks run as cron triggers.

The code is at github.com/cloudflare/cloudflare-os. It’s real production code. It ships with gatekeepers for GitHub, Slack, Google, Linear, Confluence, Notion, MCP, and a dozen others. The deployment repo is cloudflare-os-starter — you can have a running instance in under an hour.

What I built at home

Over the past year I’ve been building an agent called Agu. He runs on a macOS virtual machine on my laptop, talks to me over Telegram, browses the web, fills out forms, remembers things across sessions, and runs a set of scheduled tasks every morning and night.

The infrastructure underneath him:

  • A persistent session manager (OpenClaw) that maintains conversation state
  • A vector database (gbrain) that stores everything Agu has learned about me, searchable before each response
  • A Chrome browser controlled via CDP for interacting with real websites
  • A set of cron jobs for scheduled tasks: morning briefing, a nightly processing cycle, a watchdog that auto-restarts failed services
  • A webhook for tool integrations — currently used to register visitor parking, which was the first real job Agu ever did

I wrote about the cost and the early failures in a previous post. The short version: browser automation is hard, memory is harder, and Docker is not the right substrate for this.

Where they match

When I read through the Cloudflare OS codebase, the architectural parallels were specific enough to be uncomfortable.

Gatekeepers = OpenClaw’s tool permission layer. In CF OS, every external service access goes through a separate Worker that controls what the agent can do, logs everything it touches, and enforces policies on what operations are allowed. OpenClaw has the same concept — a tools layer that gates which capabilities are available to an agent session and blocks things like the cron tool that was running up costs when it shouldn’t have been called. The implementation is different. The idea is identical.

gatekeeper-context = gbrain. CF OS has a gatekeeper specifically for context documents — a library of information the agent reads as observations before responding. That’s exactly what gbrain is. Before Agu answers anything, he searches a vector database of everything we’ve discussed, every project I’ve described, every preference I’ve mentioned. CF built the same thing, called it a Context Library, and made it a first-class gatekeeper.

gatekeeper-scheduler = my cron jobs. CF OS has a scheduler gatekeeper that lets agents register persistent callbacks and run on a schedule. I built this as a set of shell scripts triggered by cron on the VM — morning briefing at 8am, dream cycle at 2am, watchdog every 30 minutes. Same function, different substrate.

The security model. CF OS says “agents start with no access.” Every capability is explicitly granted. Nothing is ambient by default. I arrived at the same constraint through a different path — the 2026-06-01 incident where Agu drained $400 in API credits overnight because a heartbeat check had no constraints on what it could call. The per-day spend limit is the only real circuit breaker, and it shouldn’t be. Capability-based security is the right answer. I just got there the expensive way.

Where they diverge

CF OS solves several problems I haven’t solved yet, and it’s worth being honest about them.

Browser interface. My setup is Telegram only. CF OS has a full browser-based workspace — a React SPA that talks to the backend over WebSocket using Cap’n Web RPC, an object-capability protocol that works the same whether you’re calling from a browser or from another Worker. I don’t have this. Telegram works well for me, but it limits who else could use the same system.

Multi-user and admin. CF OS is built for teams. There’s an admin panel, per-user access controls, and deployment configuration that separates what admins can change from what users can change. My setup is single-user. That’s fine for a personal agent but it doesn’t scale.

Dynamic Workers. CF OS can generate and run isolated Workers at runtime — actual code execution in a sandboxed environment. This is what makes the “vibe coded apps” feature possible: the agent writes a full-stack application and the platform deploys it. I don’t have code execution at all. Agu can fill out forms and run searches. He can’t write and deploy software.

OAuth infrastructure. Each gatekeeper handles its own OAuth flow centrally. Connecting GitHub or Slack to CF OS is a configuration step. Connecting any external service to Agu requires me to manually configure credentials and wire them up. The gatekeeper pattern is cleaner.

What this means if you’re building agents

A year ago, building your own agent infrastructure was the only option if you wanted something that actually did things. The hosted tools were chat interfaces with memory. Nothing ran code, nothing controlled browsers reliably, nothing had a durable state layer that survived restarts.

That gap is closing. CF OS is a real production system that solves these problems on infrastructure most developers already know how to use.

The Durable Objects pattern — agent brain in a DO, external integrations as separate Workers, cron via Triggers — is the right architecture for agents on Cloudflare. It’s not the obvious starting point if you come from Docker and VMs, but once you see why it works, you can’t unsee it. State lives where the compute lives. There’s no database to manage separately. Scaling is handled by the platform.

If you’re starting fresh, I’d read through cloudflare-os and cloudflare-os-starter before writing any agent code. It’s a working reference implementation for patterns most people spend months figuring out.

What I’m doing with it

I’m not rebuilding Agu from scratch. What’s running works, and I’m not going to break something that registers my visitor parking reliably just to move it to a cleaner substrate.

But the gatekeeper pattern is going to replace how I handle Agu’s tool integrations. Each external service Agu touches — the parking portal, the email system, whatever comes next — should be a separate Worker with a clear capability boundary. That’s the lesson from the cost incident and from reading this codebase.

The blog post I should write next is about the parking gatekeeper. Building one thing properly is more useful than describing a platform abstractly.

Built with: OpenClaw · CF Workers · gbrain · Telegram · macOS VM

Cloudflare OS: github.com/cloudflare/cloudflare-os