In early 2024, an independent content PM tried to move a client-reporting automation pipeline to a different platform. The pipeline itself was simple: pull client data, summarize it, and send out a weekly report. But when he opened the code to estimate the cost of migrating, he found that the runtime's API conventions and state-storage architecture were deeply tailored to one specific platform. The conclusion was blunt: he'd have to rewrite it from scratch. So he dropped the idea. The features hadn't changed. The price hadn't changed. He was simply already built on top of it.
That scene is a good starting point for understanding an announcement Cloudflare made in the summer of 2025. The company officially declared itself the "operating system for agents, apps, and entire workflows." The announcement drew more than 400 points on Hacker News — a tech community where such scores are rare — and amounted to a company promoting itself from infrastructure to operating system.
From Pipes to Bedrock
For a long time, Cloudflare played the role of the internet's plumbing. It filtered traffic for millions of sites worldwide, blocked malicious requests, and delivered content quickly from servers close to the end user. Good plumbing works best when users never have to think about it, and part of Cloudflare's competitive edge came from being invisible.
But over the past few years, the company has quietly been building a different kind of layer.
In 2017, it launched Workers, a serverless environment that lets developers run code directly on Cloudflare's network of edge servers. In 2022 came R2, an S3-compatible object storage service that a large number of developers had already adopted because of its lower data-transfer costs compared with AWS S3. Durable Objects gave developers a way to keep state consistent across a distributed edge environment — a necessary layer for anything, like an agent, that needs to remember conversation context or task progress. On top of that came Workers AI, which runs AI model inference directly at the edge, and KV, a key-value store.
Each release looked, on its own, like just another feature launch. This latest announcement formally declares that they were never separate tools at all — that together they form a single, unified runtime, a single foundation on which agents, apps, and entire workflows now run. The pipes had become bedrock.
The "operating system" metaphor is less a technical description than a strategic positioning move. An OS is the layer underneath the applications that run on it. Switching from macOS to Linux is hard not because either lacks features, but because the software, settings, and habits stacked on top form an entire ecosystem — and replacing the OS means reassembling that whole ecosystem. By choosing this metaphor, Cloudflare is formally staking a claim to being the layer underneath agents and workflows.
Agents Create a Different Kind of Dependency
Migrating a conventional SaaS tool and migrating agent infrastructure are two very different jobs.
Moving off Notion, for instance, just means exporting your data to Markdown and importing it into a new app. You'll have to relearn an interface, but the information you've accumulated travels with you. The biggest cost of that kind of migration is the learning curve.
Agents are different. An agent operates embedded in the structure of its runtime. An agent built on Workers is written around Workers' request-response processing model. An agent that manages state through Durable Objects has its entire state logic built around that specific API. An agent that stores intermediate outputs in R2 follows R2's particular access patterns. Migrating these agents to another platform means replacing each of those layers one by one. You're not moving data — you're rewriting the agent.
Look closer, and this dependency accumulates fast precisely because it's invisible. One agent automates one pipeline. That pipeline connects to another. Six months later, drafting customer replies, summarizing reports, and sending schedule reminders are all running on the same runtime. By that point, switching platforms isn't swapping out one tool — it's redesigning how the work itself gets done.
As automation takes over more of the operational work, one of the judgment calls still left to humans is evaluating what foundation that automation actually runs on. Deciding which platform to build on, and how to respond if that platform changes direction, isn't something an agent can do on your behalf. And making that call requires first knowing exactly what you're standing on.
How to Estimate the Cost of Leaving — Before You Need To
The most practical way to check how entangled you already are is to actually estimate the cost of migrating. Calculate how much time it would genuinely take to move a currently running agent pipeline to different infrastructure.
If that estimate feels impossible to even begin, that's a sign the dependency has already set in.
There are specific things worth checking.
Runtime specificity: Is the agent's code written around one platform's specific API conventions, or is it abstracted behind portable standards like HTTP or OpenAPI? A single abstraction layer often cuts migration cost by more than half. On the other hand, if the agent's core logic calls platform-specific objects or methods directly, migration amounts to a rewrite from scratch.
Where and how state is stored: Is the state an agent accumulates while running — conversation context, task progress, intermediate outputs — stored in a platform-proprietary structure, or can it be exported in a portable format like JSON or SQL? A platform-specific state model like Durable Objects is, by its very format, difficult to reproduce in a different environment. If the state can't be extracted, then migrating the agent won't bring along whatever context that agent used to remember.
Independence of the authentication layer: Is access control tied to platform-specific mechanisms, or is it managed by an independent system? If authentication is locked to the platform, you'll have to redesign that layer separately even after moving the agent logic itself. This is especially costly when multiple agents share a single authentication scheme — if that scheme is platform-specific, migration cost scales with the number of agents involved.
If two or more of these are entangled with a specific platform, that platform is already bedrock.
None of this means building on such an environment is a mistake. There are real advantages to running agents on Cloudflare Workers: a global edge network, low latency, and storage and AI inference all handled within a single environment. It saves enormous effort you'd otherwise spend assembling infrastructure yourself. That convenience is real. The problem is that it only becomes visible after it has hardened into dependency. Knowing what you're standing on, versus not knowing, puts you in an entirely different position the moment you actually need options.
The Math Changes When You're Choosing Agent Infrastructure
If features and price are the main criteria when choosing a conventional SaaS tool, choosing agent infrastructure requires adding one more factor: exit cost.
Exit cost is the sum of the time, money, and risk it takes to get out if the platform raises its prices, changes its terms of service, or shifts its strategic direction. It's a criterion weighted more toward the breadth of your future options than toward what you're currently spending.
The reasoning "there's a free tier, let's just try it" carries a completely different weight two years down the line when it comes to agent infrastructure. The moment Cloudflare declares itself an operating system, the decision to run agents on top of it carries more implications than it used to. Even when the features are sufficient and the price is reasonable, that decision needs to include the question: what happens to me if this company changes its strategy?
Doing this math at the tool-selection stage takes far less effort than doing it after an agent is already deeply embedded. Before you start building, it helps to ask one question: if I had to move this agent somewhere else in six months, how long would it take? If the answer doesn't come immediately, it's worth taking one more look at the architecture before you build.
