Cloudflare OS

This is the part that is genuinely new. Not the agent, not the sandbox — the distribution model. When you make a slide deck in Cloudflare OS, you are not using a slide-deck service. The system instantiates a private copy of slide-deck software that belongs only to you.

The core move

A Gadget is a small application — client UI, server logic, and persistent state — that exists as your instance. Not your document inside someone's app. Your instance of the app. It runs in a sandbox separate from everyone else's.

The README calls out two consequences, and both are worth sitting with:

The office-suite mental model

The most useful analogy in the README: imagine Google Docs or Office, but instead of a fixed set of file types (doc, sheet, deck), each file is potentially its own custom application, written by AI to serve exactly your needs.

Blueprints: share the code, not the instance

If you build something others would want, you have two options. Share the Gadget (they collaborate in your live instance, real-time, shared state), or share a Blueprint (they stamp out their own independent copy, with their own bindings and storage).

From docs/blueprints.md, precisely what a Blueprint captures:

Mechanics worth knowing: Blueprints get 128-bit random hex IDs and are shared at https://<host>/blueprint/<id>. Anyone with the link can view metadata unauthenticated; creating a Gadget from it requires auth. A single Gadget can have multiple Blueprints at different code versions (a “stable” and a “latest”). Blueprints export to a .gadget file and import into a different Workshop instance — which is your escape hatch for moving work between environments. Bundled Blueprints that ship with a deployment get stable readable IDs like format.document.

Three binding types a Blueprint can require: gatekeeper (an external resource), aiModel (a model binding), and agentSpawner (an agent-spawner config). When someone instantiates it, they pick their own connected account and their own model.

Real-time multiplayer, for free

Every Gadget is backed by a Durable Object — Cloudflare's stateful serverless primitive, which makes real-time collaboration close to trivial. The README's claim is telling: it is so easy that the coding agent implements multiplayer by default, without being asked. Presence, live cursors, and shared state come from the substrate, not from the prompt.

The agent can use the app it built

This is subtle and it is the reason the architecture choices in Module 4 exist. Every Gadget's client and server must communicate via Cap'n Web RPC. That requirement buys two things simultaneously:

1. Cap'n Web is extremely low-boilerplate — define a method on the server, call it from the client as if local. Easy for an agent to write.
2. Because the server necessarily exposes a clean typed API, an agent can call that same API directly. No MCP server to build, no custom agent loop to integrate.

So after you ask AI to build the app, you can ask AI to work inside the app. “Fill in the Q3 numbers on slide 4” hits the same RPC surface your UI does.

SaaS vs. the Gadget model

Check yourself

🃏 Flashcards

The README describes Gatekeepers as “supercharged MCP servers.” That undersells them. An MCP server is a tool surface. A Gatekeeper is a policy enforcement point with an approval queue, an audit log, a cache, and — the genuinely novel part — a simulator that lets the agent keep working while a human approval is still pending.

What a Gatekeeper does

When you introduce an agent or a Gadget to an external resource, a Gatekeeper is created to manage that access. It is service-specific software that mediates the connection. Per the README, it:

• Provides a clean Cap'n Web API to the service, wrapping whatever the native API looks like
• Handles authorization (typically OAuth), including token storage, refresh, and revocation
• Enforces narrow access to only the specific resource the user intended
• Logs every action the Gadget or agent performs, for your review
• For any action with side effects, gives the human a chance to approve or deny

The launch materials give the concrete flavor: a Gatekeeper can give an agent access to a single repository, allow it to read issues but not source code, mask particular fields, and apply rate limits. That granularity is the point.

The async human-in-the-loop breakthrough

Gatekeepers do something different. When an agent performs an action requiring approval, the Gatekeeper simulates the outcome locally. It tells the agent the action completed. If the agent reads the result back, it gets simulated results consistent with the action having happened. The agent proceeds and queues up more work.

Later — when it is convenient — the human approves or rejects, in bulk or one by one. The agent never blocked. The human never rubber-stamped under time pressure.

How it is built: the three-tier hierarchy

From the repo's write-gatekeeper agent skill, each Gatekeeper implements three levels:

Each Gatekeeper is a separate Worker. Cloudflare envisions Gatekeeper services eventually being deployed and maintained independently from OS instances — but for now they ship in-repo and deploy alongside your instance. The backend auto-discovers vendors from service bindings whose names start with GATEKEEPER_.

The seven responsibilities

The skill file enumerates what a correct Gatekeeper must do. This is effectively the security specification:

Two ways to implement simulation

Shipped Gatekeepers

Sixteen Gatekeeper packages are in the repo today. The README lists setup instructions for eleven; five more exist as packages:

Building a custom Gatekeeper

The repo ships an agent skill at .agents/skills/write-gatekeeper/SKILL.md that walks an AI through building one. It is a two-phase process with two mandatory stop-and-review gates — a notable design choice, since it means Cloudflare does not trust an agent to one-shot a security boundary.

Phase 1 — core implementation

1. Understand the service. Auth model, which resources to expose, which operations are observations (reads) vs. actions (side effects).
2. Design the Session types in src/types.d.ts. One interface per logical resource, not a god-object. Methods return structured data, not raw API responses. Design so that limiting authority means limiting access to specific objects.
3. STOP Present the API for review. The skill is emphatic: do not proceed without operator approval. “Getting the API right is the most important and delicate part” — getting it wrong means rebuilding.
4. Implement from the provided SKELETON.md template.
5. Register a service binding in packages/workshop-backend/wrangler.jsonc.
6. Add resource-selection UI — an iframe configurator so users can pick which repo/doc/project to grant.
7. STOP Ask whether to proceed to Phase 2 (which may happen in a separate session).

Phase 2 — the security pass

Logging and approvals, caching, simulation, and observer verification. This is where a Gatekeeper stops being an API wrapper and becomes a control point.

Registration looks like this:

// packages/workshop-backend/wrangler.jsonc
{
  "binding": "GATEKEEPER_COURSE_CATALOG",
  "service": "gatekeeper-course-catalog",
  "entrypoint": "GatekeeperVendor"
}

And the package layout:

packages/gatekeeper-<name>/
  src/
    configurator/         # resource-picker UI modules
    <name>.ts             # Vendor, UserAccount, UserImpl, GatekeeperImpl, SessionImpl
    types.d.ts            # Session/Hook types — the agent's only API documentation
    types.txt -> types.d.ts   # symlink, read at runtime by getTypeScriptTypes()
    <name>-api.ts         # optional HTTP helper
  wrangler.jsonc
  package.json
  tsconfig.json

// ❌ Coarse: authority cannot be narrowed. Holding this object
//    means holding the whole catalog. Every method needs an ID,
//    and any ID is as good as any other.
interface CatalogSession {
  getCourse(courseId: string): Promise<Course>;
  updateCourse(courseId: string, patch: Patch): Promise<void>;
  listLearners(courseId: string): Promise<Learner[]>;
}

// ✅ Capability-shaped: the object IS the authority.
//    Handing out a CourseRef grants exactly one course.
//    Withholding .learners() grants read access without roster access.
interface CatalogSession {
  /** Resolve a single course by slug. Throws NotFound if it does
   *  not exist or this connection was not granted access to it. */
  course(slug: string): Promise<CourseRef>;
}

interface CourseRef {
  /** Title, description, and publication state for this course. */
  metadata(): Promise<CourseMetadata>;
  /** Update editable metadata fields on this course. */
  update(patch: CoursePatch): Promise<void>;
  /** Enrolled learners. Omitted from the ref entirely when the
   *  connection was granted metadata-only access. */
  learners?(): Promise<LearnerSummary[]>;
}

The difference is not stylistic. In the first version, an agent introduced to “one course” still holds a handle that can reach every course — enforcement has to happen inside every method, by checking IDs. In the second, the reference is the permission, and there is no ID to tamper with. That is what capability-based means in practice.

Check yourself

🃏 Flashcards

Cloudflare OS is built by the team that built Workers, using runtime features that were added specifically to support it. That is the single most useful fact about its architecture — it explains both why it is elegant and why porting it elsewhere is hard.

The primitive stack

How it fits together

The OS analogy, as Cloudflare states it

This mapping is verbatim from the README, and it is more literal than marketing usually is:

Package map

The 25 packages in the monorepo, grouped by role:

Also at the root: AGENTS.md, an .agents/ directory of skills (including write-gatekeeper), a plans/ directory, and a docs/ directory covering blueprints, sharing, observers, OAuth sign-in, AI Gateway billing, integration testing, and public server config. The repo is written to be operated on by agents as much as by people — which is itself a useful thing to study.

Cap'n Web and Code Mode

Two choices that reinforce each other:

Cap'n Web is an object-capability RPC system. “Object-capability” is the operative half: you do not pass identifiers and let the receiver check permissions; you pass references, and holding the reference is the permission. This is why the Gatekeeper API design rules in Module 3 look the way they do — the RPC layer makes capability-shaped APIs the natural thing to write.

Code Mode is how the agent calls tools: rather than emitting structured tool-call JSON per step, it writes a snippet of code and executes it. For multi-step work this is dramatically more efficient — a loop over 200 issues is one snippet, not 200 round trips. The README claims that because of the tight integration, the Cloudflare OS agent often performs better and faster with fewer tokens than a general-purpose coding agent on the same underlying model.

Blueprint storage: a one-way propagation chain

Worth understanding because it explains a UI behavior you will hit:

1. Gadget DO (blueprints collection) — authoritative source. Holds full metadata, the exported code version, and a dirty flag.
2. User DO (blueprints collection) — denormalized copy for fast listing, so you can audit and manage your Blueprints even if the source Gadget was deleted.
3. Workers KV (BLUEPRINTS) — the public lookup store, keyed by hex ID; this is what the public API reads.

Code content lives separately in R2 (BLUEPRINT_CONTENT), as a Yjs V2-encoded full-state document. Old versions are retained on update to avoid races during concurrent instantiation. The dirty flag is set before propagation and cleared only after all three writes succeed — if it stays set, the UI shows a warning with a Retry button. That is the failure you will occasionally see; it is by design, not corruption.

Model providers and billing

• Bring your own model. Works with many major providers and self-hosted models. The heavy lifting is done by Pi (pi-agent-core), which gives one API across providers.
• AI Gateway routes inference, enabling model selection, cost tracking, and budget enforcement per user, team, or workspace. For an org rollout this is the cost-control lever — and the reason a pilot's spend is measurable rather than a surprise.
• Collaborator billing: when a collaborator uses AI chat in someone else's Gadget, the model resolves from their own account. Spend follows whoever prompted, not the Gadget owner.
• The deployment starter ships with AI disabled by default — you opt into Workers AI and AI Gateway explicitly.

Other notable dependencies

• Yjs — CRDT sync for code changes between clients and agents, and for replaying histories. This is why an agent editing your Gadget's code while you are also editing it does not corrupt anything.
• Monaco — the embedded editor, for the people who still look at the code.
• Vite — the dev loop.

Check yourself

🃏 Flashcards

This module is the one to send to your security team. The interesting content is not the sandbox — sandboxes are well understood. It is the observation-tracking system, which enforces that sharing a Gadget cannot leak data the recipient was never entitled to see. I have not seen another agent platform attempt this.

Capability-based, not ACL-based

Every agent and every Gadget starts with access to nothing. Even if the workshop is configured with credentials for GitHub, Google, and Slack, agents and Gadgets do not automatically get to use them.

Instead you must introduce each agent or Gadget to the specific resource you want it to reach — paste a link to a GitHub repo, or click “add resource” and pick it. An agent can also request an introduction to a resource it believes it needs, which you grant or deny.

The sandbox, both halves

Note the shape of this: the sandbox is deny-by-default on egress, not deny-by-default on API surface. That is the stronger property. A Gadget cannot exfiltrate to an attacker-controlled endpoint because it cannot open a socket at all, regardless of what its code says.

Observations and observer verification

Here is the problem this solves. Alice builds a Gadget that reads a sensitive HR spreadsheet through the Google Gatekeeper. Alice shares the Gadget with Bob. Bob cannot see the spreadsheet — but the Gadget can, and now Bob is looking at the Gadget. Every agent platform on the market has this hole.

Cloudflare OS closes it. The invariant, from docs/observers.md:

The mechanism:

Two scope caveats from the docs, stated honestly:

• No per-thread enforcement in v1. It is all-or-nothing per observer; individual chat threads and observations are not hidden from individual collaborators.
• Role-dependent breadth. build collaborators — who get full access to chat, code, and all bindings — must be verified against every Gatekeeper the Gadget has.

The lockdown flag

Before observer verification existed, the only enforcement mechanism was prohibitAllSharing — a blunt flag a Gatekeeper sets on a maximally sensitive observation. When set, the Gadget can no longer be shared with anyone and drops into “lockdown”: no further actions, no web fetches. It still exists as a backstop for data that should never be shared regardless of the recipient's entitlements. Worth knowing about, because a Gadget that mysteriously stops working after touching sensitive data has probably hit it.

Sharing: roles, links, and revocation

Two roles, totally ordered (build > use):

Three implementation details worth flagging to a reviewer, because they are the kind of thing usually gotten wrong:

• Default-deny by construction. The restricted use session is a class that implements Overseer and throws Unauthorized for everything outside an allowlist. Because it implements the full interface, any newly added method fails to compile until a developer consciously decides whether use callers may invoke it. The compiler enforces the security review.
• Share keys are never stored. The server generates a random 128-bit key and stores only its HMAC-SHA-256 hash with a domain-separation constant. A database leak does not expose valid share links, and the server cannot reconstruct them. “Copying” a link mints a new key rather than revealing the old one.
• Revocation is graph-based. The system tracks how each collaborator gained access as directed permission edges (user edge or share-link edge). A collaborator keeps access while at least one valid edge remains, which is what makes transitive revocation coherent when Alice added Bob and Bob added Carol.

What this model stops — and what it does not

Check yourself

What would you actually ask Cloudflare before putting learner data behind this?

A starting list for your security team — these are the questions the public docs do not fully answer:

1. Observation history retention. How long is the per-Gadget observation log kept, where does it live, and is it itself covered by deletion requests?
2. Verifier unwrapping. docs/observers.md notes the Gatekeeper unwraps the verifier “today, by calling semi-private methods it defined on its own verifier object.” That is an acknowledged soft boundary. What is the hardening plan?
3. Simulated-state divergence. If an agent acts on simulated results and the human then rejects, what guarantees exist that downstream derived artifacts are invalidated rather than left carrying phantom data?
4. Dynamic Worker escape surface. What is the isolation guarantee between facets in the same workspace DO, and has it been independently reviewed?
5. Model provider data flow. With BYOK and per-collaborator model resolution, what stops a collaborator's personal provider key from routing Coursera data to an unvetted endpoint?
6. Deletion. When a learner deletion request arrives, what enumerates every Gadget SQLite database that may hold a copy?

Question 6 is the one I would lead with. Per-user instances are excellent for confidentiality and awkward for erasure — you have traded one shared datastore you can query for thousands of small ones you cannot. Get an answer before a pilot touches production learner data, and design the pilot to avoid it until you have one.

Three paths, in ascending order of commitment: run it on your laptop in one command, click a hosted deploy into a Cloudflare account, or use the starter repo for a real deployment you control. A fourth — self-hosting on workerd — is documented as coming soon, which matters more than it sounds.

Path 1 — run it locally (15 minutes)

Install pnpm, then:

git clone https://github.com/cloudflare/cloudflare-os
cd cloudflare-os
pnpm run-local
# → http://localhost:8787

This runs the whole stack locally on wrangler and workerd. Not for production. Your data lands in a .wrangler subdirectory. This is the right first move — do it before any meeting about it.

For actual development work, run the halves separately in two terminals:

pnpm dev-server     # terminal 1
pnpm dev-client     # terminal 2
# → http://localhost:3000

What to try first

The README's own suggested prompts, which are well chosen because each one exercises a different part of the system:

Path 2 — hosted deploy (branding only)

A guided flow at os.cloudflare.app/deploy deploys the upstream release into your own Cloudflare account. It builds nothing locally, configures sign-in and admin emails for you, and leaves the whole /admin surface intact: site name, logo, accent color, announcements, agent instructions, featured Blueprints, and which connectors your users can reach. Built-in Gatekeepers are yours to connect with your own OAuth credentials.

The constraint: hosted deployments run on a workers.dev address. If you want your own domain — or the email Gatekeeper, which needs a zone — you need Path 3.

Path 3 — the starter repo (a real deployment)

cloudflare/cloudflare-os-starter wraps a pinned upstream release with deployment controls, without modifying upstream source. This is how a company should run it.

git submodule update --init
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login

Account requirements: Workers, KV, R2, Browser Rendering, and Dynamic Worker Loaders. AI products are optional — AI is disabled by default and you opt into Workers AI and AI Gateway. With resource values left null, Wrangler auto-provisions three KV namespaces and an R2 bucket and reconnects them on later deploys.

Path 4 — self-hosting on workerd

Configuring external services

Most Gatekeepers need OAuth client credentials for their service. The README is refreshingly candid that this is annoying — many providers deliberately do not make it easy, since OAuth's intended audience is developers. Each Gatekeeper package carries its own setup instructions.

The GitHub Gatekeeper is a good illustration of the gotchas you will hit:

• Use a GitHub OAuth App, not a GitHub App. Only OAuth Apps honor the scope parameter, which is what enables minimal scopes on login (read:user user:email) and full scopes only on connect (repo read:user user:email).
• Callback URL: http://localhost:8787/gatekeeper/github/oauth locally; swap the host for your PUBLIC_BASE_URL in a real deployment.
• Credentials go in a gitignored .env in the package directory.
• To offer “Continue with GitHub” on the login page, add github to AUTH_GATEKEEPERS. Users are keyed by primary verified email.

Budget real time for this step. Eleven services × OAuth app registration, scope review, and callback configuration is not a morning's work, and each one needs someone with admin rights in that service.

Operations

• wrangler tail for live production events.
• Roll back from the Worker's dashboard deployment history or wrangler rollback.
• Backend error reporting works without a vendor account — explicit upstream issue events become structured logs in a private Error Reporter Worker.
• Follow the starter's upgrade checklist before bumping the pinned submodule, and review upstream release history first.

Check yourself

The honest version. Cloudflare OS solves a real problem Coursera has, using a security model better than anything else available. It also arrives as early-access software from a vendor you are not currently on, that will not accept your patches, with self-hosting unfinished. Both halves are true, and the recommendation follows from weighing them rather than picking one.

First, a correction that changes the math

The problem this would actually solve at Coursera

Strip away the technology and the organizational problem is this: a large number of non-engineers need leverage over internal data, and every path to giving it to them is currently bad.

Cloudflare OS is a credible sixth option: non-engineers build their own tools, against narrowly scoped capabilities, with every read logged and every write queued for approval. That is the pitch. Now the scrutiny.

Use case inventory

Ranked by value-to-effort, with the Gatekeeper work each requires. Verify marks assumptions about Coursera's internal systems that I cannot confirm from outside.

The case for

• The security model is genuinely better than the alternatives. Capability introduction instead of ambient access, plus observer verification on sharing, is a stronger story than anything in Module 8. For a company whose data includes learner records under multiple regulatory regimes, this is the argument that actually matters — not the productivity claims.
• Async human-in-the-loop is the difference between a policy that survives and one that gets disabled. Every governance regime you have deployed that required synchronous approval has degraded into rubber-stamping. Simulation is a real answer.
• Apache 2.0, deployed in your own account. No per-seat licensing. No vendor holding your workflows hostage. You own what you build, and Cloudflare's positioning is explicitly anti-lock-in.
• Battle-tested internally at real scale. Thousands of Cloudflare employees, engineering through sales, daily. That is far better evidence than a launch demo.
• It consolidates a tool sprawl you are probably already paying for. One platform can absorb several point AI tools, a chunk of internal-tools backlog, and the “custom GPT” deployments that have likely appeared organically.
• The MCP Gatekeeper preserves prior investment. Existing MCP servers get wrapped, not rewritten — and gain logging, approvals, and scoping they never had.
• The per-user model kills the internal-tools maintenance treadmill. Publish a Blueprint; forty teams fork it; nobody inherits a backlog.

The case against

• Early access, and Cloudflare says so. v2 is a complete rewrite with “many rough edges.” You would be adopting a platform whose public life is measured in days.
• New vendor, new perimeter, new expertise. Per the correction above, this is not free. Procurement, security review, DPA, IdP integration, and a team learning Workers and Durable Objects from zero.
• Upstream will not take your patches. Anything not expressible as a custom Gatekeeper or a config setting becomes a permanent fork against a fast-moving upstream. This compounds.
• Self-hosting is not ready. The workerd escape hatch that makes the Cloudflare dependency palatable is documented COMING SOON. Do not price it in.
• Custom Gatekeepers are security-critical code. The valuable use cases all need them, and each one needs authentication-grade review. That is the real engineering cost, and it is recurring, not one-time.
• Erasure is genuinely harder. Per-user instances mean learner data could land in thousands of separate SQLite databases. Your deletion pipeline has no way to enumerate them today. This is the risk I would rank first.
• Divergence. Forty forks of the revenue dashboard produce forty numbers. Mitigable by architecture, not by hoping.
• Adoption is a change-management project, not a deploy. The whole thesis depends on non-engineers building things. Cloudflare's culture is unusually technical; Coursera's distribution across sales, content, and support is different. This is the assumption most likely to be wrong.
• Unbounded AI spend without discipline. AI Gateway gives you per-user and per-team budget enforcement — but only if configured on day one, not month three.

Scorecard

My assessment across the dimensions that should drive the decision. Higher is better for Coursera specifically.

The pattern is unambiguous: the design is excellent and the operational readiness is not. That combination has a standard answer — a bounded pilot that buys you optionality without betting anything, and a deliberate re-decision when the readiness scores move.

What it would replace — and what it would not

The Gatekeepers Coursera would have to build

This is where the engineering estimate lives. Each is security-critical code requiring authentication-grade review, and each needs a Phase 1 (API design + auth) and Phase 2 (approvals, caching, simulation, observers) pass. Sizing assumes one senior engineer familiar with the codebase, following the write-gatekeeper skill. Verify against your actual systems.

A 90-day pilot

Designed to buy maximum information for minimum commitment, and to fail cheaply and visibly if it is going to fail.

Eight questions to answer before committing beyond the pilot

Recommendation

What I would do regardless of the adopt decision

1. Steal the async approval pattern. Any internal agent platform Coursera builds should queue side effects and simulate reads rather than blocking. This is the highest-value idea in the launch and it is free.
2. Steal capability introduction. Stop configuring MCP servers with ambient access. Move to per-task resource introduction wherever you already run agents against internal systems.
3. Adopt the “agent is a third principal type” framing. Not a user, not a service account — accountable to a human, with strictly narrower authority. Put it in your internal agent standards.
4. Apply the observer question to what you already run. “If user A's agent read something and shares the output with user B, what stops the leak?” Ask this of every internal AI tool at Coursera today. Most will have no answer.

The two-minute version for your staff meeting

Check yourself

What is the strongest argument against my own recommendation?

That the pilot is a distraction with a foregone conclusion.

The argument goes: the readiness scores are so low that no 90-day pilot will move them. Self-hosting will not ship by then. Erasure will not be answered by then. The contribution policy will not change. So you will arrive at day 90 with exactly the information you have now, minus an engineer-quarter, plus a group of 25 people who liked a tool you then take away — which has a real morale cost and makes the next platform rollout harder.

It is a serious argument and I would not dismiss it. Two things answer it. First, the two facts the pilot actually produces are not knowable from outside: whether non-engineers at Coursera will build their own tools, and what a custom Gatekeeper genuinely costs you to build and review. Both are decision-relevant for any agent platform you eventually choose, including one you build yourself. Second, the taking-it-away cost is manageable if you say at the start that it is a time-boxed evaluation — and unmanageable if you let it drift into unowned production, which is exactly what the hard stop and kill criteria exist to prevent.

If you cannot commit to the day-90 decision and the kill criteria, the counterargument wins and you should not start.

Almost everything in this category is a chat interface with connectors, or an app builder with AI bolted on. Cloudflare OS is the only one where the distribution model and the permission model are the product. That is either a decisive advantage or an unnecessary complication, depending on what you are actually trying to do.

The field

The two axes that actually separate them

Honest positioning

Cloudflare OS wins when you need non-engineers building real tools against sensitive internal systems, and you have to defend that to a security team. That is a narrow but valuable slot, and it happens to describe Coursera's situation well.

It loses when you need something today, when your estate is deeply Microsoft or Google and single-vendor integration outweighs everything, when your use case is retrieval rather than action, or when your users are engineers who are perfectly happy with an IDE agent and a few MCP servers.

Check yourself

🃏 Flashcards

Ten things to do, in order

1. Run it locally today. pnpm run-local, then the tic-tac-toe prompt. Fifteen minutes, no commitment, and you will understand the architecture better than any writeup can convey.
2. Confirm the CloudFront finding with your infrastructure team before quoting the vendor-cost argument either way.
3. Read workshop-shared/src/gatekeeper.ts and the write-gatekeeper skill. Roughly an hour, and it is the clearest articulation of capability-based agent security currently in public.
4. Ask the observer question of every AI tool Coursera runs today. If user A's agent reads something restricted and shares the output with user B, what stops the leak? Collect the answers — that inventory is valuable on its own.
5. Get written answers on erasure and observation retention before any pilot touches production learner data.
6. Name the owner. One senior engineer, ~60% time, for 90 days. If you cannot name them, do not start.
7. Agree the kill criteria in writing with whoever approves the pilot.
8. Turn on AI Gateway budgets on day one, per user and per team. Not month three.
9. Adopt the async-approval pattern in your own agent work regardless. Queue side effects, simulate reads. It is the best idea in this launch and it costs nothing to steal.
10. Put the day-90 decision on the calendar now, with the memo as a named deliverable.

Primary sources

• github.com/cloudflare/cloudflare-os — README, docs/blueprints.md, docs/sharing.md, docs/observers.md, and .agents/skills/write-gatekeeper/SKILL.md. Apache 2.0.
• github.com/cloudflare/cloudflare-os-starter — deployment controls, deployment.jsonc, customization and observability guides.
• blog.cloudflare.com/cloudflare-os — the launch post.
• Cloudflare press release, August 5, 2026.
• os.cloudflare.app — product site and hosted deploy flow.
• Supporting Cloudflare posts: Code Mode, Dynamic Workers, Durable Object Facets, and Cap'n Web.
• Coverage: SiliconANGLE, Phoronix, Decrypt, SD Times.
• Coursera edge-provider finding: DNS resolution and HTTP response headers for coursera.org, checked August 5, 2026.