Governance by Default.
Cloudflare open-sourced their internal AI workspace last week. The architecture maps nearly 1:1 onto what we already spec'd for our Ops Center. That's not a coincidence. Here's what the validation means, what we're borrowing, and why we're not adopting their stack.
When a company like Cloudflare open-sources an internal platform, the default reaction is to deploy it. That's the wrong instinct here. Cloudflare OS is impressive engineering, but it's built on deep coupling to their own stack: workerd, Workers, Durable Objects, Cloudflare Access. Adopting it wholesale means buying into their ecosystem lock, stock, and barrel.
But here's what made me pay attention. The architecture they arrived at after months of internal usage, thousands of non-engineering users, and real production load, maps almost exactly onto the spec we wrote for our own Ops Center months ago. Independent confirmation from a team that solved the same problems we did is worth more than any vendor pitch.
The Validation
Our Ops Center spec called for four things from the start:
- 1.Agent channels with human oversight. Every agent action visible to a human operator. Not hidden in a terminal log, not buried in a Slack thread. A real channel with real visibility.
- 2.Per-agent budgets and model routing. Cheap models for routine work. Frontier models for complex reasoning. Cost tracked per agent, per task, per user. No runaway spend.
- 3.Governed access to internal systems. Agents don't get API keys in plaintext. They get scoped, audited, revocable permissions through a controlled intermediary.
- 4.Your own data, your own context. The agent workspace is grounded in company knowledge, not generic model training data. What your organization knows shapes what the agent does.
Cloudflare OS arrived at the same four pillars independently. Their names are different, the implementation is different, but the architecture is identical:
| Our Spec | Cloudflare OS |
|---|---|
| Agent channels + human approval | Async human-in-the-loop approval queue |
| Governed API access layer | Gatekeepers (governed connectors) |
| Zero permissions until scoped | Zero-trust by default, scales to user auth |
| Model routing tiers (Micro/Standard/Premium/Local) | AI Gateway rule-based routing + per-user spend tracking |
| Company context shapes agent behavior | Curated context + skills library per organization |
When two teams solve the same problem independently and arrive at the same architecture, that's not coincidence. That's the problem space telling you what the answer looks like.
What We're Borrowing
Four patterns from Cloudflare OS are worth folding into our Ops Center without adopting their stack:
1. Async Approval Queue
Cloudflare's approach is elegant. Instead of hard-stopping a workflow every time an agent needs human permission, the agent simulates the action and queues it for batch approval. The human reviews a queue of proposed actions and approves or rejects them in bulk. This keeps agent workflows moving while keeping humans in control. We've been doing this manually with Discord pings. Formalizing it as a proper queue is the next step.
2. Gatekeeper-Style Governed Connectors
This directly addresses a finding from our own security audit. We identified plaintext API keys in our tool configuration leaking into every light-context agent session. Cloudflare's Gatekeeper pattern, connectors that mediate agent access to external systems with defined read/modify/approve rules, is exactly the fix. Agents never touch raw credentials. The connector handles auth, scopes access, and logs every call. We build this into our existing Supabase and portal layer, not on Cloudflare Workers.
3. Zero-Permission-by-Default Agents
Every agent starts with zero access. Permissions are granted incrementally, scoped to the active user's authorization level. If a junior employee triggers an agent, that agent has junior-level access. If an executive triggers it, it has executive access. The agent's permissions are a subset of the human's, never a superset. This is the correct security model and it's going into our Ops Center spec as a hard requirement.
4. Blueprint Template Reuse
When someone in the organization figures out a better way to do something, that workflow gets saved as a reusable template. Other people can deploy it with one click. This is the same principle behind our skill system in OpenClash, but Cloudflare's implementation makes it accessible to non-technical users through a browser interface. Worth studying for our portal UX.
What We're Not Doing
We're not deploying Cloudflare OS. Three reasons:
Stack coupling. Cloudflare OS is built on workerd, Workers, Durable Objects, and Cloudflare Access. Every component is Cloudflare-owned. Adopting it means migrating our entire infrastructure to Cloudflare's runtime. We run on Supabase, OpenClaw, and standard Linux. That's our stack. Rewriting everything to fit their runtime would be engineering for vendor lock-in, not for capability.
Data residency. Our clients include medical practices, accounting firms, and financial services. Data residency and HIPAA compliance are non-negotiable. Cloudflare OS runs on Cloudflare's edge network. Our Ops Center runs on infrastructure we control, on servers we can point to on a map.
We're already most of the way there. The validation is the point. Cloudflare spent months and serious engineering effort arriving at architecture we spec'd on a whiteboard. The patterns they validated are the patterns we're already building. We don't need their implementation to benefit from their confirmation that the architecture is correct.
The Bigger Picture
The enterprise AI conversation has shifted. Six months ago, companies were asking "how do we use AI?" Now they're asking "how do we govern AI we're already using?" That's the right question. Employees are pasting sensitive data into ChatGPT. Teams are building agent workflows with raw API keys in environment variables. Security teams are catching up to usage that already happened.
Cloudflare built their OS because they had the same problem internally. Their employees were using insecure workarounds to get AI access. Broad API keys were getting exposed to commercial models. The solution wasn't to ban AI usage. The solution was to build a governed platform where AI usage is safe by default.
That's the same thesis behind our Ops Center and our AIIO Assessment framework. You don't stop AI adoption. You architect for it. Governance isn't a brake on innovation. It's the thing that makes innovation safe enough to actually deploy in a business context.
The companies that figure this out first, that build governed agent infrastructure before their employees force the issue through shadow AI usage, are the ones that will capture the productivity gains without the security incidents. That's the bet we're making with Prospyr 305. Cloudflare just made the same bet from a different starting point.
The Takeaway
If you're building agent infrastructure for your company, the architecture is already converging. Four pillars: governed access, cost-aware routing, human-in-the-loop approval, and company-grounded context. Whether you build it on Cloudflare's stack or your own, the shape of the solution is the same.
We're building ours on our own. Not because Cloudflare's is bad. Because the architecture is the asset, not the implementation. And owning your architecture means you can switch implementations without starting over.
Franklin J Bryant IV is COO of All Lines Business Solutions and founder of Prospyr 305. He builds governed agent infrastructure for Florida businesses that can't afford to get AI security wrong.