Skip to content

Cloudflare OS: an open platform for agents, apps, and work

Summary

Cloudflare OS is Cloudflare's open-source, organization-owned agent-workspace platform. It joins curated organizational context and skills, isolated agent execution, governed access to systems of record, and agent-authored full-stack applications. Its central design claim is that authorizing an MCP tool invocation is insufficient: the platform must retain the resources an agent actually observed and re-evaluate those resources when work is shared, exported, or sent to another system. The published implementation combines default-deny Dynamic Workers, service-specific Gatekeepers, Durable Object Facets, Cap'n Web RPC, Cloudflare Access, and AI Gateway. (Source: the original article linked below.)

Key takeaways

  1. An agent workspace is more than chat history. A workspace combines sessions, persistent state, outputs/files, resource access, curated context and skills, plus an isolated runtime in which an agent can write and execute code.

  2. Code narrows the context-window problem. Rather than placing an entire dataset in a model prompt, an agent can write code to search, filter, join, and analyze a resource in the isolated runtime. The article presents this as the research path for company data.

  3. MCP tool authorization does not establish data authorization. An MCP server describes which tools an agent may call, but a tool-level allow decision does not identify the specific resources the agent subsequently observed, nor control where information derived from them can flow.

  4. Cloudflare OS begins at zero privilege. Agents and generated apps have access to nothing until a user grants a specific resource. Generated code receives a typed env.PROJECT-style capability rather than a reusable credential; the credential remains outside agent and generated-app code.

  5. Gatekeepers make the resource boundary service-aware. A Gatekeeper understands one external service's API, resources, and operations. It can scope an agent to one GitHub repository, permit issue reads but not source-code reads, mask fields, rate-limit activity, and require approval before a merge.

  6. The platform turns observed resources into a sharing constraint. It records every resource an agent observes. A collaborator opening the workspace, interacting with its agent, or viewing derived output is checked against those recorded resources. The same record can limit external writes, invitations, agent hand-offs, and outbound requests after sensitive reads.

  7. Each generated app is a full-stack isolated workload. Client code runs in a sandboxed browser frame. Server code is loaded on demand as a Dynamic Worker and instantiated as a Durable Object Facet with an app-specific SQLite database, rather than requiring a permanently allocated container.

  8. App and agent share the same callable interface. The browser calls application server methods through Cap'n Web as ordinary JavaScript functions, and the agent can call that same method surface. An app can therefore become a reusable tool for unattended work rather than remaining an export-only artifact.

  9. Blueprint sharing deliberately excludes sensitive state. A shared blueprint carries the application's code, but each recipient starts with independent SQLite data, conversation history, credentials, and resource grants.

  10. AI Gateway centralizes model choice and spend governance. Every inference call passes through AI Gateway, where administrators can decide model availability, attribute requests to a person/team/workspace, apply budgets and rate limits, and choose behavior at a limit. The article does not publish default limits or enforcement semantics.

Architecture

User ── Cloudflare Access ──▶ Cloudflare OS workspace
                                      │
                    curated context + skills + agent session/state
                                      │
                                      ▼
                         isolated Dynamic Worker runtime
                         (no ambient outbound networking)
                                      │ typed capability grant
                                      ▼
                         service-specific Gatekeeper
                         policy + OAuth + audit + approval
                                      │
                                      ▼
                            system-of-record resource

Browser app frame ── Cap'n Web RPC ──▶ Dynamic Worker + Durable Object Facet
                                            │
                                            └── isolated app SQLite state

All model inference ─────────────────────▶ AI Gateway

Operational facts and disclosed constraints

  • Cloudflare gave the first internal version to every employee in May 2026; the article says thousands of people across all functions use it daily. It does not disclose user count, request volume, latency, availability, or cost.
  • The first version used private workspaces, static apps, and repeated skills even for deterministic work. The redesign is explicitly driven by collaboration, live connected apps, deterministic workflows, and governance.
  • Dynamic Workers provide the app server's isolated compute; Durable Object Facets provide a separate SQLite database per app. The article does not quantify cold start, request concurrency, storage size, or durability behavior for Cloudflare OS.
  • The deployment model separates open-source core from a configuration/deployment repository. Organizations can add their own Gatekeepers, interfaces, integrations, analytics, policies, and deployment pipelines without patching the core.

Caveats

  • This is primarily a product-and-architecture disclosure, not a production performance report: it contains no SLOs, throughput figures, p99 latency, isolation escape analysis, retention periods, or policy-evaluation semantics.
  • “Records every resource agents observe” describes an intended platform mechanism; the article does not specify the observation schema, derived-data taint granularity, storage lifetime, false-positive behavior, or revocation propagation.
  • The relationship between Gatekeeper policy and externally supplied MCP servers is described at the architectural level only. No protocol mapping, bypass analysis, or audit-log data model is published.
  • Blueprint state separation is explicitly claimed for SQLite data, conversation history, credentials, and connected resources, but cross-app code supply-chain controls are not discussed.
  • Cost governance is centralized through AI Gateway, but default budgets, over-limit behavior, attribution integrity, and model-routing rules are undisclosed.

Extracted entities

Systems

Concepts and patterns

Source

Last updated · 622 distilled / 1,953 read