On 5 August 2026, Cloudflare open-sourced Cloudflare OS — an agent workspace, a security and governance layer, and an app platform, published on GitHub and deployed into your own Cloudflare account. The company had been running it internally since May.
It is the third major agent platform to ship in ten months. Amazon Bedrock AgentCore went generally available on 13 October 2025 with seven components; it has thirteen today. Google renamed Vertex AI to the Gemini Enterprise Agent Platform on 23 April 2026, folding its agent tooling into a single lifecycle — and stating that Vertex AI services would from then on be delivered exclusively through it.
Three competitors, working independently, in different market positions, arriving at almost the same parts list. That convergence is the news. It means the architecture of an enterprise agent system is no longer contested, and the interesting question has moved from what should we build to what has to be true in our organisation before any of this works.
The parts list they all agreed on
Strip the branding and each platform assembles the same six primitives.
A runtime with per-session isolation. AWS gives each session a dedicated microVM with its own CPU, memory and filesystem, terminated and sanitised when the session ends. Google splits this in two — Agent Runtime for trusted agent logic, and a separate short-lived Sandbox for untrusted code execution and browser control. Cloudflare uses Dynamic Workers with Durable Object facets: V8 isolates, each app carrying its own SQLite database, without a container underneath.
Worth applying the same maturity test to all three. AWS publishes hard, falsifiable numbers and has been generally available since October 2025. Google’s Scale tier is GA but its runtime ceiling is unpublished, so there is nothing to hold it to. Cloudflare’s two load-bearing primitives — Dynamic Workers and Durable Object facets — are both in open beta with no announced GA date, and the repository describes itself as in heavy development, early access, and still carrying many rough edges as of the August 2026 release. That is a reasonable state for something published the week it was open-sourced. It is not a reasonable thing to leave out of a platform decision.
A memory layer split short and long. Turn-by-turn state inside a session, and extracted facts, preferences and summaries that survive across sessions. AWS calls these short-term and long-term memory. Google calls them Sessions and Memory Bank. The shape is identical.
A gateway that turns systems into tools. This is where the Model Context Protocol became load-bearing. AgentCore Gateway both produces MCP — wrapping OpenAPI specs and Lambda functions as tools — and consumes existing MCP servers. Google’s Agent Gateway parses MCP request data to enforce authorisation per tool. Cloudflare ships MCP Server Portals for the MCP servers an organisation already runs.
An identity model for the agent itself. Not the user’s identity — the agent’s. AWS issues workload identities and brokers outbound OAuth to third-party services. Google gives each agent a cryptographic persona with mTLS and DPoP authentication. Cloudflare grants typed capability bindings that hand an agent scoped access without exposing the credential behind it.
A registry of approved agents, tools and skills. AgentCore Registry entered preview in April 2026. Google has Agent Registry inside its governance tier. Cloudflare’s equivalent is the curated context and skills library in the workspace itself.
Observability shaped like OpenTelemetry. Traces over reasoning steps, tool invocations and model calls, feeding evaluation and optimisation downstream.
Cloudflare adds one primitive the other two do not have, and it is the most interesting idea in the announcement: an observation log. The platform records what an agent has read, and gates what can be done downstream on that record. If an agent reads restricted data, neither the agent nor anything derived from it can be shared with someone who lacks that access. Most governance models authorise the request. This one follows the data after the request succeeded.
Where they actually differ
Not on components. On who is buying, and what you hold afterwards.
AWS is selling substrate. Framework-agnostic, model-agnostic, thirteen services you can adopt piecemeal, priced purely on consumption — Runtime at $0.0895 per vCPU-hour plus $0.00945 per GB-hour, Gateway at $0.005 per thousand invocations, no seat concept anywhere. The buyer is a platform engineering team. AWS is not trying to own your agent; it is trying to own the ground underneath it.
Google is selling a governed lifecycle. Build, Scale, Govern, Optimize — with security as the headline rather than an appendix: per-agent cryptographic identity, an ingress/egress split at the gateway, Model Armor applied at runtime, telemetry landing in Security Command Center. Pricing is hybrid, layering seat licensing for the end-user application on top of consumption metering for the platform. That changes the buyer. AWS sells to an architect; Google sells to a CIO who needs the agents and the compliance narrative in one purchase.
Cloudflare is selling ownership. Apache 2.0, on GitHub, running in your own account. There is no published price for the platform because there is no platform product — you pay for the Workers underneath it, starting at the $5/month Workers Paid floor, because Dynamic Workers is a paid-plan feature and there is no free tier to evaluate on. The pitch is that you can read the source, audit the boundary, and run it without asking anyone.
One caveat that cuts against Cloudflare’s own differentiator: a managed version is on the published roadmap. If it ships, the thing you are buying converges toward what AWS and Google already sell, and the argument for self-hosting narrows to the cases where reading the source genuinely matters to you. That is worth deciding deliberately now rather than discovering later, because it changes which of the two things you are actually paying for.
Lock-in is real in all three cases, but it is not the same lock-in, and this is worth being precise about in a procurement document. With AWS and Google, your agent code is genuinely portable — any framework, any model — while the control plane is not: gateway, memory, identity and registry are proprietary APIs. Cloudflare inverts it. The code is yours and auditable, but it assumes Workers, Durable Objects and Access.
One more difference matters for anyone planning past a single vendor. MCP is now universal: Anthropic donated it to the Agentic AI Foundation in December 2025, and AWS, Google, Microsoft and Cloudflare all sit there as platinum members. Agent-to-agent communication has not converged the same way — A2A reached v1.0 in April 2026 under Linux Foundation governance with AWS and Google both supporting it, but it does not appear in Cloudflare’s announcement. Agent payments have already forked outright, with AWS backing x402 and Google backing AP2. Tool access is a settled standard. Agent-to-agent coordination is not yet a safe bet.
What this looks like when you actually run it
We have been operating this architecture in production since June 2026, and the useful part of the experience is not the components. It is the constraints they impose.
Our rank and content operation for two of our brands runs on two open-source projects we did not build — OpenSEO, self-hosted from a container image, and Sam, a drafting agent. OpenSEO exposes ten tools over MCP. Five are free and five spend money at a data provider on every call.
That split turned out to be the design lesson. Cost is a property of the tool, not of the agent, and nothing in the protocol tells you which is which. An agent given all ten tools and a broad instruction will reach for the expensive ones. Our gateway logic has to encode the distinction, our scheduled routine has to check the balance before it runs and refuse rather than degrade, and the whole thing has to be sequential — parallel calls fail under load where the identical query succeeds alone. None of that is in the vendor documentation for any of the three platforms, and all three will present you with the same problem the first time an agent has a metered tool.
Sam’s output contract taught the second lesson. It writes drafts to disk and cannot publish. The human gate is in the architecture, not in a policy document — which is the only place a gate survives contact with a system running on a schedule.
Everything around those two projects is ours: the tunnel and the localhost-only bind, the sequential query script with its balance and connectivity guards, the adapter that normalises MCP over JSON-RPC into a daily brief, the scheduled drafting jobs, the publishing path.
We then generalised it, and it is worth separating the two halves of what we built, because the seam between them is where all three platforms stop.
The workspace half is the part the vendors also sell. VaultOS, live since 3 July 2026, runs the same pattern: its skill library is seventeen markdown files read fresh from disk on every request — edit a skill, no redeploy, and every change is a reviewable diff rather than a paste into a console. The agent runtime spawns with its working directory set to a scratch folder and never the knowledge base, the knowledge base mounted explicitly, a scrubbed child environment, shell execution denied, and credential files unreadable.
Access runs through four independent layers: Cloudflare Access at the edge, then the origin verifying that token itself and failing closed if it cannot, then server-side scope filtering that discards any scope the client supplies, then guardrails in code — a save cannot execute until a search has run. Four layers because any one of them can be misconfigured, and the useful property of the arrangement is that being wrong about one of them is survivable.
The other half is the knowledge layer, and that is the half none of the three sells you. Underneath the workspace sit 1,038 wiki-linked documents with typed frontmatter — the decisions, terminology and history the agents actually reason over.
This is the distinction worth carrying into a vendor conversation. AgentCore, the Gemini Enterprise Agent Platform and Cloudflare OS are all workspace layers: runtime, memory, gateway, identity, registry. Each of them assumes a corpus. None of them produces one. Memory in the vendor sense means what an agent retains across sessions, which is not the same thing as what your organisation knows — and conflating the two is how a platform gets bought to solve a problem it was never going to touch. That corpus, not the runtime, is what determines whether any answer the system gives is worth reading.
Six things to do before you choose a platform
Every one of these is portable across all three, and none of them requires a vendor decision.
1. Make your context machine-readable first. This is the knowledge layer above, stated as an action. Decisions, terminology, procedures, the reasons behind past choices — if they live in individual heads and scattered file shares, a runtime will not rescue them. Format matters far less than existence and currency. This is the longest-lead item on the list and it is almost always started last.
2. Decide the identity model before the runtime. Whether an agent acts as itself or on behalf of a specific user is an architectural fork, not a setting, and the vendors have already diverged on how they express it. Answer it against your own audit requirements first. Every downstream authorisation decision inherits from this one.
3. Treat skills as version-controlled artefacts. An agent instruction sitting in a vendor console has no diff, no review, no revert, and no owner. The same instruction in a repository has all four. This costs nothing to adopt on day one and is expensive to retrofit at fifty skills.
4. Assume MCP. Do not assume A2A. Wrapping your internal systems as MCP tools is work that carries across all three platforms unchanged, and the standard now has every major vendor behind it. Multi-agent coordination protocols and agent payment protocols have not settled — build against them only where you can afford to redo the work.
5. Instrument before you scale. All three ship OpenTelemetry-shaped tracing. None of them make it retroactive. The first agent is where you learn what a trace needs to contain; the fiftieth is where you need it and cannot go back.
6. Choose your lock-in deliberately. Code portability and control-plane portability are separate questions with different answers per vendor. Both are acceptable answers. Not having asked is not.
What this means for a Gulf enterprise
The Vision 2030 procurement window rewards platform decisions that hold in 2028 and 2030. Three credible vendors converging on one architecture in ten months is a good signal for exactly that kind of decision — it means the shape is stable enough to commit to, and that a competent migration between them is a real option rather than a hopeful one.
It also means the differentiator is not the platform. When the primitives are the same everywhere, the organisations that get value are the ones that arrive with a governed knowledge base, a decided identity model, and a data classification that says which processes an agent may touch. The ones that arrive with a budget and a vendor shortlist will run a successful pilot and then stall, because the pilot was never the hard part.
For Government and BFSI buyers there is a further wrinkle worth putting on the table early. Each of these platforms makes different assumptions about where data sits, which regions are available, and how long agent memory persists — AWS, for one, enforces a minimum retention of seven days on memory events. That is a data-minimisation conversation, and it belongs in the architecture review rather than in the security sign-off at the end.
The architecture question is closed. The organisational one is open, and it is the one worth your quarter.
Choosing an agent platform this cycle? Book a briefing — we will map your knowledge estate, identity model and data boundaries against what each platform actually requires, before the shortlist.
Rami Alcheikh is the Founder of Emerge Digital — the Dubai Mainland local prime for enterprise CX, Data, AI, and digital transformation across the MEA region.