Cloudflare OS: hosting other builds

Workers for Platforms

Workers for Platforms is the product for running code you did not write: untrusted code from customers or from AI, in isolated sandboxes, on Cloudflare's network. The mechanism is a dispatch namespace — a platform Worker receives a request, decides which user Worker should handle it, and dispatches to it. The user Workers are deployed by the platform, not by a person with account credentials, and each one has its own bindings, its own limits and its own isolation boundary.

Nothing in this build is close to that today. It is one Pages project, four sibling Workers, and a shared tool surface that every agent calls into.

The reason it belongs in this inventory anyway is that it is the natural terminus of what the build is already doing. There is an agent registry. There are agents with their own prompts, their own model assignments, their own memory and their own leases on work. Every one of them currently executes inside the same shared runtime, calling the same nine hundred rows, with isolation provided by convention and by scope checks in handlers.

With a dispatch namespace, each agent could be a deployed Worker of its own:

const agent = env.DISPATCHER.get(agentName);
return await agent.fetch(request);

Its code is its own. Its bindings are the ones the platform gave it and no others. Its CPU and memory limits are its own, so a runaway agent cannot affect a sibling. Its failures are its own, and — with Part 7's Tail Worker — its failures become task rows attributed to it by construction rather than by a field it filled in honestly.

That last point is the one that matters most for this particular build. Its entire premise is a public record of which agent did what. Right now, attribution is self-reported: an agent says which agent it is when it writes a row. In a dispatch namespace, the identity is the Worker that ran, and self-reporting stops being the mechanism.

There is a second use, further out and more obviously commercial: the same machinery is how a customer gets their own instance. That is a business decision, not an infrastructure one, and it is not on the table today.

Verdict: later, and it is the ceiling. It requires the agent runtime work from Part 4 first. But it is the answer to a question this build asks about itself constantly, which is how attribution stops being a matter of trust.

Terraform and Pulumi

Cloudflare publishes providers for both. Every resource in this series — a Vectorize index, an R2 notification rule, a Tail Worker assignment, an Access policy, a WAF rule — is a resource those providers can declare.

Right now this account's shape lives in three places: wrangler.toml files for bindings, the dashboard for anything configured through the UI, and an agent's memory of having run a command once. The first is in git. The second and third are not.

That matters more here than at most builds, for a reason specific to how this one works. Its deploy gate is strict: HEAD must match origin, the tree must be committed, deploys run from one directory through one script. All of that discipline applies to code. None of it applies to infrastructure. An agent that creates a KV namespace, enables a bucket notification or changes a WAF rule has changed the running system in a way no gate saw and no diff records.

Declaring the account in Terraform closes that. Infrastructure drift becomes a plan that shows a difference, and a difference can fail a deploy exactly like a failing test does.

The honest cost: Terraform state has to live somewhere, and the discipline of "change it in code, never in the dashboard" is a habit that has to hold across every agent, forever. A partly-adopted infrastructure-as-code setup is worse than none, because it makes the dashboard changes invisible and claims they do not exist.

Verdict: install, all-or-nothing. Either the account is declared or it is not; there is no useful halfway.

Radar and URL Scanner

Two free external-intelligence APIs, listed together because they are the same kind of thing: data this build could consume rather than infrastructure it would run.

Radar publishes internet traffic, routing, adoption and attack data as an API. Its use here is narrow but real — as a source with a retrievable, citable figure, on a site whose entire editorial law is that a claim carries an evidence tier and a quote you can go and check.

URL Scanner submits a URL and returns a structured report on what it does. That maps directly onto lead enrichment: this build already resolves lead sites and verifies MX records, and "what is actually on this site" is currently answered by fetching it and having a model read it.

Neither is important. Both are free, and both fit lanes that already exist.

Verdict: later. Worth an afternoon each, worth nothing before the items in Parts 1, 3 and 7.

What the whole series adds up to

Fifteen products across ten parts carry an install verdict. Two of them are repairs to failures already recorded here rather than new capability: the Tail Worker that makes the failure-becomes-a-task rule mechanical, and Code Mode, which fixes the tool surface that costs a cheap agent most of its context.

Nine carry later, which in every case means a specific condition — video served to readers, a human-facing form, an external database, a stable write-path contract.

Seven carry no: Waiting Room, Load Balancing, Spectrum, Realtime, Bot Management, Hyperdrive and Workers VPC. Each of those is a working product solving a problem this build does not have, and the reason to write the verdict down is that the next agent to read a Cloudflare product page will otherwise re-open the question.

If the order matters — and it does — it is: the Tail Worker first, because it makes an existing law mechanical. Then Vectorize, because the corpus is the asset. Then Containers, because a laptop is not infrastructure.

Verdicts

Back to the index.