cloudflare-os: Cloudflare OS Lets Agents Act Without Asking First

The Agent That Won't Take No For An Answer

Every system that lets an AI agent touch the outside world forces the same bad choice. Either you interrupt the human before every write (may I update this DNS record? May I now? May I now?), or you hand the agent broad ambient credentials and hope.

The first option kills throughput. An agent that stops for permission on every step is not an agent, it is a wizard with extra clicks. The second option is how you get a headline about an assistant that dropped a production table.

Cloudflare OS refuses the premise. Its authors describe it as an operating system in two senses: an OS for a company to work with AI safely, and an OS for AI workloads. The security layer that makes this possible is called a Gatekeeper, and the trick it plays is genuinely new.

Simulate First, Approve Later

A Gatekeeper sits between the agent and every external service. The README calls them "supercharged MCP servers": one per service, each with a clean API wrapping the service, its own authorization flow, a narrow resource scope, and a log of every action taken.

The surprising part is what happens when the agent tries to act. Instead of blocking, the Gatekeeper simulates the outcome locally. The agent proposes a write, the Gatekeeper fabricates a plausible result, and the agent keeps working. The real action lands in a queue. The human reviews that queue later, in bulk or one by one.

This is the whole idea. An agent assembling a document, configuring a worker, or wiring up a DNS record never loses its train of thought waiting on a person. It gets a believable answer, advances, and stacks up more actions. The human opens the queue once and approves a batch, rather than answering a modal every nine seconds.

The tradeoff is real and the authors do not hide it. Until a human approves, the agent is acting on a fiction. If the simulated result diverges from what the service would actually have done, the agent's next steps are built on a guess. For most workflows that guess is close enough, and the alternative (a stalled agent) is worse. But it is a bet, not a guarantee.

Built for Cloudflare Before It Was Built for You

Cloudflare OS was not designed in a vacuum. An earlier internal version was already in daily use across the company. The launch post reports that thousands of people across every function, many of them outside engineering, use it to create documents and slides, automate repeatable tasks, and build small apps to visualize data.

The release ships as two repositories: the core and an example deployment that consumes the core without patching it. That separation matters. Cloudflare is not asking you to run its instance. It is handing you a foundation to fork, and Kenton Varda, the architect of Cloudflare Workers, is listed as the leading contributor.

The framing makes more sense once you have seen the Gatekeeper. An OS is a set of rules about what programs may do and to whom. Cloudflare OS is that, for agents: an environment where the default is that an agent can act, and the boundary is where a person decides whether the action was real.

Three Pillars, One Product

Now that the surprising part is on the table, here is the map. Cloudflare OS has three parts, and they only make sense together.

• Chat: an agent chat UI preloaded with company context, so the assistant knows how the organization works.
• Gadgets: sandboxed mini-apps, built on request by the agent, that live in isolated runtimes.
• Gatekeepers: the security layer that mediates every call from an agent or a gadget to an external service.

Authorization as a Compile Error

Most systems enforce permissions with a runtime check scattered through handlers. Cloudflare OS does something stricter. Sharing a gadget has two roles, build and use, totally ordered so that build outranks use. When a session opens a gadget, the server computes the caller's effective role and hands back a different object.

// open() returns a different object depending on the caller's role
const session = await overseer.open(gadgetId);

if (session.role === "build") {
  return session as OverseerClientInterface;   // full access
} else {
  return new UseOverseerInterface(session);     // restricted
}

// UseOverseerInterface implements the FULL interface,
// but throws Unauthorized outside an allowlist.
class UseOverseerInterface implements OverseerClientInterface {
  readFile(path: string) {
    return this.inner.readFile(path);
  }

  writeFile(path: string, content: string) {
    if (!this.allowed(path)) throw new Unauthorized();
    return this.inner.writeFile(path, content);
  }

  deploy() {
    throw new Unauthorized();   // use callers may not deploy
  }
}

Here is the detail that earns the section title. Because UseOverseerInterface implements the full interface, any newly added method fails to compile until a developer consciously decides whether use callers may invoke it. Default-deny is not a policy document. It is a build error. Authorization became a property of the type system, and the compiler is the enforcer.

A Gadget Is a Worker With Its Own Database

Each workspace is a Durable Object. Each Gadget is a Dynamic Worker Facet, an isolated runtime with its own SQLite database. That isolation is the point: a gadget that misbehaves cannot reach into another gadget's state, because there is no shared state to reach. The blast radius of a bad app is the app.

The bundled gadgets show what this looks like in practice. workspace-docs, workspace-sheets, and workspace-slides each ship a server.ts and a client.ts, plus shared libraries for sync, UI, zip, and pptx. Agents compose new apps from tested primitives, so they are not reinventing save logic or presence on every request. The runtime can also run on self-hosted workerd, so it is not strictly tied to Cloudflare's hosted service.

Blueprints Are Git Repos in Disguise

A blueprint is a shareable snapshot of a gadget's code. It is not the chat history, the SQLite storage, or the credentials. It is just the files, and the files are stored as a git commit.

The clever part is how bundled blueprints install. On a deployment's first API request, they are installed parentless, with a fixed author, date, and message, so the commit depends on the files alone. Every deployment therefore derives the identical commit from the same source. The installer never asks what was there before, which makes the operation idempotent and content-addressed.

Lineage rules handle updates. A gadget follows its blueprint and can take a new release, merged with whatever changed locally in the meantime. Nothing is applied automatically. Updates arrive as proposals, which is the same posture the Gatekeeper takes toward actions: the machine suggests, the human decides.

Where Cloudflare OS Sits

The differentiator is not chat with your data. Plenty of projects do that. It is app isolation plus capability-based service access, delivered as a self-hostable core. The table below places it against the nearest alternatives, grouped by what they actually are.

The honest read is that Cloudflare OS is not competing on model choice or on the chat UI. It is competing on the governance layer underneath. The open question, and the one the InfoQ coverage raises, is whether a dedicated agent workspace can hold its ground against AI features folded into the suites companies already run. The Gatekeeper pattern is the strongest answer Cloudflare has to that question, and it is worth studying whether or not you ever deploy the rest.