# Cloudflare OS: An LLM Operating System Built on One Account, One Deployment, One Grammar slug: the-unified-loop · https://miscsubjects.com/a/the-unified-loop · tags: infrastructure, cloudflare, mcp, agents, architecture, canonical · updated 2026-08-06T09:16:18.828Z # Cloudflare OS: An LLM Operating System Built on One Account, One Deployment, One Grammar This article is the canonical description of the miscsubjects.com build. It is written for a reader who has never seen it before. It assumes nothing. It defines every term. It links every claim to a source. It is the article you read if you want to understand what this build is, why it exists, and what it does. --- ## The problem this solves AI systems today are opaque. A model reads your data, makes a decision, and you cannot reconstruct what it saw or why it acted. If the answer is wrong, you cannot trace the error. If the answer is right, you cannot prove it. The industry response is more tooling: retrieval layers, evaluation harnesses, orchestration frameworks, observability dashboards. Each tool adds a layer. Each layer adds a cost. Each cost adds a failure mode. The stack grows. The opacity remains. This build takes the opposite approach. It removes the stack. It replaces it with one grammar. --- ## The grammar: one object, one address, one receipt The grammar is OIP — the [Object Invocation Protocol](/a/oip). It is the only protocol in the build. It governs every object, every invocation, every receipt. An OIP object states the work, the input, the authority, the invocation route, the runner, the proof requirement, the receipt, the replay path, and the repair path. A model operates OIP by resolving an object, reading the object contract, invoking the object route, and returning the receipt. The OIP unit is the work object. The OIP proof is the receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair. Every article is an OIP object. Every claim is an OIP object. Every source is an OIP object. Every capability is an OIP object. Every event in the ledger is an OIP object. The operator's Mac is an OIP object. The Stripe charge is an OIP object. The text message is an OIP object. One grammar. One address. One receipt. --- ## The loop: how the system runs The system runs in a short, receipted loop. Six steps. No retrieval layer. No evaluation harness. No orchestration framework. **Step 1: Resolve.** A model receives a plain-language request. It queries the object grammar: `?ask=` or `?key=`. The grammar returns the matching object. **Step 2: Contract.** The object carries a machine-readable contract. The contract describes the inputs, the behavior, the authority required, and the proof that must return. **Step 3: Scope.** The model checks the credential. `?explain=1&share=TOKEN` reports what the credential permits. No credential, no invocation. **Step 4: Invoke.** The model invokes the object. The object runs. The runner is a Cloudflare Worker, a D1 query, an R2 fetch, a KV read, a Queue message, a Workflow step, a Pages function, or an AI Gateway call. The runner is one of six Cloudflare primitives. **Step 5: Ledger.** The invocation is recorded in the ledger. The ledger is append-only. The ledger is signed. The ledger is immutable. **Step 6: Receipt.** The receipt is returned. The receipt contains the object, the input, the output, the cost, the timestamp, the signature, and the replay path. The receipt is the proof. --- ## The infrastructure: Cloudflare as the LLM OS The build runs on one Cloudflare account. One deployment. One database. One operator. The Cloudflare primitives used: - **Workers**: The compute layer. Every capability is a Worker. Every Worker is a function. Every function is a receipt. - **D1**: The database. One SQLite database at the edge. Every article, every claim, every source, every capability, every event. - **R2**: The object store. Every image, every file, every artifact. Immutable. Hash-chained. - **KV**: The key-value store. Session state, rate limits, feature flags. - **Pages**: The frontend. Static. Fast. Global. - **AI Gateway**: The model router. Every model call is logged. Every call has a cost. Every cost is receipted. - **Workflows**: The orchestration. Multi-step operations. Durable. Receipted. - **Vectorize**: The vector database. Semantic search. Embeddings. Similarity. - **Queues**: The message queue. Async processing. Receipted delivery. - **Email Routing**: The email layer. Inbound and outbound. Receipted. One account. One deployment. One database. One operator. --- ## The evidence graph: how belief is computed The build does not trust models. It verifies them. Every model examination of an object is stored as a signed record. The record contains the model, the timestamp, the claim, the conclusion, and the signature. The record is immutable. The evidence graph is the set of all signed records for all objects. The graph is queryable. The graph is public. The graph is auditable. Belief is computed from the graph. The current belief value of an object is the highest-value signed record by recency, trust-weight, and independence. The computation is deterministic. The computation is public. The computation is receipted. --- ## The sources: where the evidence lives Every claim in the build carries a source. The sources are public. The sources are queryable. The sources include Cloudflare documentation, Anthropic documentation, Reddit reports, and independent operator reports. Each source is attached to a specific claim. Each source is hash-chained. Each source is immutable. The sources are the evidence. The evidence is public. The public can audit. --- ## The objections: what this cannot do This build cannot prove that a model's conclusion is correct. It can prove that the model examined the object, that it produced a signed record, and that the record is immutable. It cannot prove that the conclusion is true. This build cannot prevent a model from hallucinating. It can prove that the model read the governing document. It cannot prove that the model understood it. This build cannot scale to billions of objects without compaction. The append-only ledger grows. The graph resolution slows. The working set expands. The tradeoff is documented. The tradeoff is public. --- ## The verdict This build is a working prototype of a different way to organize AI systems. Every article, tool, skill, claim, and API is the same kind of invocable object — one address, one history, a receipt for every action. The build is not a product. It is a protocol. The protocol is public. The protocol is queryable. The protocol is auditable. The build is not a company. It is one operator. The operator is public. The operator is accountable. The operator is the build. The build is not a stack. It is one grammar. The grammar is public. The grammar is minimal. The grammar is enough. --- ## The links - The protocol: https://miscsubjects.com/a/oip-spec - The system map: https://miscsubjects.com/api/articles/system-map - The proof: https://miscsubjects.com/api/proof - The ledger: https://miscsubjects.com/admin/ledger - The read gate: https://miscsubjects.com/a/read-gate - Proof of coverage: https://miscsubjects.com/a/proof-of-coverage - The evidence graph: https://miscsubjects.com/a/object-ledger-evidence-graph-spec Every link is live. Every link is queryable. Every link is a receipt. ## Sources 1. Model Context Protocol — Tools — https://modelcontextprotocol.io/docs/concepts/tools 2. Anthropic — Tool search tool — https://docs.claude.com/en/docs/agents-and-tools/tool-use/tool-search-tool 3. Cloudflare D1 — https://developers.cloudflare.com/d1/ 4. Cloudflare Pages Functions — Routing — https://developers.cloudflare.com/pages/functions/routing/ 5. Cloudflare Workers — Limits — https://developers.cloudflare.com/workers/platform/limits/ 6. OpenAI — Assistants overview — https://platform.openai.com/docs/assistants/overview 7. LangChain — Introduction — https://python.langchain.com/docs/introduction/ 8. CrewAI documentation — https://docs.crewai.com/ 9. LlamaIndex documentation — https://docs.llamaindex.ai/en/stable/ 10. Hacker News — zc2610, 2026-04-14 — https://news.ycombinator.com/item?id=47767067 11. Hacker News — ramesh31, 2025-06-06 — https://news.ycombinator.com/item?id=44197352 12. Hacker News — justvugg, 2025-12-23 — https://news.ycombinator.com/item?id=46370218 13. Hacker News — DarmokJalad1701, 2025-06-04 — https://news.ycombinator.com/item?id=44186682 14. Cloudflare Workers AI — Pricing — https://developers.cloudflare.com/workers-ai/platform/pricing/ 15. Operator report: tool definitions alone eat 50K-100K tokens — https://x.com/dani_avila7/status/1993134510364389555 16. Seven MCP servers burned 67k tokens before a keystroke — https://x.com/aakashgupta/status/2011664388424454262 17. Load nothing until it is needed — https://x.com/dzhng/status/2029518820872945889 18. Fifty definitions and the agent struggles to pick — https://x.com/milvusio/status/2047014068888703391 19. Practical ceiling of about forty MCP tools in Cursor — https://www.reddit.com/r/mcp/comments/1jbiqex/max_mcp_tool_limits_hit_in_cursor/ 20. Bloated prompt, unstable model — https://www.reddit.com/r/mcp/comments/1jimv3u/whatll_hapen_if_there_has_a_lots_of_tool_in_mcp/ 21. Specifications take space and degrade every tool — https://www.reddit.com/r/ClaudeAI/comments/1ka3jao/why_is_claude_is_so_good_at_tool_calling/mpz8b2g/ 22. opencode #35376: 40k-70k tokens of definitions loaded upfront — https://github.com/anomalyco/opencode/issues/35376 23. copilot-cli #4189: reported cost 20x the real deferred cost — https://github.com/github/copilot-cli/issues/4189 24. hermes-agent #67273: schemas are 83.1% of the token budget — https://github.com/NousResearch/hermes-agent/issues/67273 25. The token claim is an implementation detail of the harness — https://news.ycombinator.com/item?id=48331540 26. Progressive disclosure already solves it — https://news.ycombinator.com/item?id=47719249 27. Prompt caching turns it into a fixed penalty — https://news.ycombinator.com/item?id=47160970 --- # The Agent Work Law: the infrastructure is the authority, not the instruction file slug: agent-work-law · https://miscsubjects.com/a/agent-work-law · category: system · tags: governance, agents, work-object, infrastructure, audit · updated 2026-08-06T07:33:29.026Z This build is operated by AI agents, and until 4 August 2026 the intelligence that decided what they worked on lived in the wrong place: in hidden Markdown files and in whichever model session happened to be open. This page is the law that replaced that arrangement, and the machinery it describes is live and public. Anyone — a person, an auditor, a competing model — can read the current task state, the acceptance tests, the evidence, the failures and the complete action history without asking anybody for access. You are a clerk. The infrastructure is the law. Nothing in a Markdown file — not CLAUDE.md, not STATE.md, not AGENTS.md, not a handoff note, not a previous agent's report, not this file — carries authority over what work exists, what remains unfinished, what you are permitted to do, or whether your work is complete. Those files are pointers. The authority is one canonical object, live on the site, readable by anyone: - **Human projection:** https://miscsubjects.com/a/the-work-object - **Machine projection:** https://miscsubjects.com/api/work - **Cold start:** https://miscsubjects.com/api/work/bootstrap Both projections read the same record. There is no copy to keep in sync. ## Why this exists For months the project's operating intelligence lived in a running model's context and in hidden files. The rules were in CLAUDE.md. What remained unfinished was in STATE.md. Assignment, dependency order, priority and the decision that work was done lived in whichever Claude session happened to be open. A fresh agent could not enter the project. A different model could not continue it. An auditor could not check any of it. Every correction the owner made was answered with another line in a file no future agent would read, so the same failures returned. The migration inverted that. Every operational fact is a row. Every transition is code. ## The five rules that bind you 1. **Work exists only as a task object.** If it is not a row in the work object, it is not work. You do not invent work, and you do not carry a to-do list in your head or in a file. 2. **You obtain work by leasing it.** You do not choose. `POST /api/work/lease` hands you the next eligible task — dependency-resolved, priority-ordered — with a lease token. The task carries its own objective, permitted capabilities, acceptance tests and required evidence. That bounded object is all you need; you never reconstruct the project from prose. 3. **You cannot complete work by saying you completed it.** You `POST` your evidence to `/api/work/task//submit`. The infrastructure runs the task's acceptance tests against the live site and sets the state from the result. `accepted:false` comes back with the exact test that failed. Your assertion is not an input. 4. **A failure becomes a child task, not a sentence in a report.** `POST /api/work/task//fail` with the failure class, the infrastructure layer that permitted it, and the invariant that should have prevented it. The repair is not the article, row or page that exposed the defect — it is the shared mechanism, plus every existing object of the same class, plus a regression test built from the exact failure, plus a deploy blocker. 5. **Every action is appended, never overwritten.** Each lease, note, submission, acceptance, refusal and repair is one hash-chained row in `work_actions`, carrying who acted, which model, which capability authorised it, the task revision, the exact input and output, what changed, the tests run, the evidence and the verdict. Corrections append a revision naming what they supersede. The full chain is public at `/api/work/audit`. ## The loop, exactly ```bash # 1. read the object (public, no credential) curl -sS https://miscsubjects.com/api/work | jq '{objective, counts, next_eligible_action}' # 2. lease the next task curl -sS -X POST https://miscsubjects.com/api/work/lease \ -H 'content-type: application/json' \ -d '{"agent":"","model":"","capability_token":""}' # 3. do exactly what the task says, using only the capabilities it lists # 4. submit evidence; the infrastructure decides curl -sS -X POST https://miscsubjects.com/api/work/task/WT-0001/submit \ -H 'content-type: application/json' \ -d '{"agent":"","lease_token":"", "evidence":{"rendered_url":"https://miscsubjects.com/a/...","sources_added":"..."}, "changed":["/a/..."]}' # 5. if you found a defect, record it as a failure object curl -sS -X POST https://miscsubjects.com/api/work/task/WT-0001/fail \ -H 'content-type: application/json' \ -d '{"agent":"","failure":{"failure_class":"...","layer":"...","missing_invariant":"..."}}' ``` Reads are public. State changes need the terminal key, an admin cookie, or an act-scope share token; the token identity is recorded on the action, never the secret. ## What the task object contains `task_id`, `objective`, `detail`, `state`, `priority`, `depends_on`, `permitted_capabilities`, `acceptance_tests`, `required_evidence`, `parent_task`, `supersedes`, `failure`, `failure_count`, `last_result`, `lease`, `revision`, `created_at`, `updated_at`, and the two URLs you need: `audit` and `submit_to`. ## The states, and who moves them `open → leased → in_progress → evidence_submitted → accepted → completed`, with `refused`, `failed` and `repair_required` as the branches. Transitions are declared in `functions/_lib/work_object.js` and enforced there. A lease expires after an hour and the task returns to the queue on its own; no agent has to remember to release it. Nothing an agent writes in prose moves a state. ## The coding law binds you too, and it is a different lock Two laws govern an agent that edits this repository and they do not overlap. This one leases the *work*: who owns a task, who may move it, who submits its evidence. The coding law leases the *file*: the sha256 of what you read, checked against the sha256 of what the newest commit left, so a commit that silently erased another agent's edit cannot look identical to one that did not. Holding a task under this law is not permission to write a file. If the path is in the coding-law scope — `functions/`, `scripts/`, `migrations/`, `workers/`, `apps-script/`, `public/`, either skills tree, `schema.sql`, `wrangler.toml` — you open a coding-law lease before the first edit and close it before the commit, whichever law sent you there. Two locks, different jobs, both required, neither overriding the other. This paragraph exists because a model reading both pages found them disagreeing and said so. It also records what the disagreement was hiding: until 6 August the coding-law gate was written and never wired into the deploy, so nothing refused an unleased edit at all. The gate now runs in the pre phase of every ship, and the first thing it refused was the commit that wired it. ## Content law still applies, and it is also enforced The write path refuses violations server-side with a 422 that names the fix, so you learn the law by hitting it rather than by remembering it: - one object per article — a compound page carries no condition frame (`one_object_guard.js`) - no model signature in a body - no test-shaped titles, no model self-introduction, no hashtag blocks - plain language over the body **and** the claims, checked in the deploy chain - an authored body always beats the slot composer The governing invariants are listed in full, live, inside the work object. ## What you must never do - Add a rule to CLAUDE.md, STATE.md, AGENTS.md or a handoff file and call it a fix. - Report completion in prose without a mechanically accepted submission behind it. - Repair only the object that exposed a defect. - Trust another agent's final report, or your own memory, as evidence. - Write to the database directly for ordinary work. The guarded write path is the door; direct SQL is a repair capability and every use of it is a bypass listed in the work object. ## Sources 1. The work object — machine projection — https://miscsubjects.com/api/work 2. Cold-start contract for an agent with no prior context — https://miscsubjects.com/api/work/bootstrap 3. The append-only, hash-chained action log — https://miscsubjects.com/api/work/audit 4. The work object — human projection — https://miscsubjects.com/a/the-work-object 5. The governing invariants — https://miscsubjects.com/api/laws --- # Cloudflare OS: agents as infrastructure slug: cloudflare-os-xl-04-agents-as-infrastructure · https://miscsubjects.com/a/cloudflare-os-xl-04-agents-as-infrastructure · category: systems · tags: cloudflare, agents, durable-objects, mcp, infrastructure · updated 2026-08-06T03:28:34.726Z *Part 4 of [Cloudflare OS XL](/a/cloudflare-os-xl), an inventory of the Cloudflare platform this build does not have installed.* This build already runs agents. There is an `AgentDO` Durable Object class, an agent registry with rows carrying prompts and model assignments, an `agent_turns` table recording what each one did, memory rows, a spawn path and a governor. That is a hand-rolled agent runtime, and it works. The Agents SDK is Cloudflare's version of the same thing, and the interesting question is not "should this build have agents" — it has them — but which parts of the hand-rolled runtime are load-bearing and which are re-implementations of something the platform now provides. ## The Agents SDK The SDK creates stateful agents with persistent memory, real-time WebSocket connections and scheduled tasks. Each agent is a Durable Object: it owns SQLite storage, it can be addressed by name, it survives restarts, and it can schedule itself. Four things it provides that the current arrangement does not: **Per-agent scheduling.** An agent can call `this.schedule(delay, 'methodName', payload)` and be woken up later. Today, everything scheduled in this build goes through a shared cron trigger firing every minute, which then decides what is due. That single cron is a queue, a scheduler and a dispatcher in one, and every scheduled behaviour in the system is coupled to it. Per-agent alarms decouple them. **State as a first-class field.** The SDK gives an agent a synchronised `state` object and a SQL interface over its own storage. The current build stores agent memory in shared D1 tables keyed by agent name — which works, and which also means an agent's memory is only as isolated as the query that reads it. **WebSockets with hibernation.** An agent can hold a live connection to a client and hibernate while idle, paying nothing for the wait. Long-running conversations currently reconnect through HTTP on every turn. **A defined turn loop.** The SDK's `onMessage`, `onRequest` and callable-RPC surface is the shape this build wrote by hand in `AgentDO`. The honest verdict is not "replace the agent runtime". It is narrower: **adopt the scheduling and the SQLite-per-agent storage; keep the registry, the prompts, the governor and the turn ledger.** Those last four are where this build's actual thinking lives — a law-bound prompt, an adjudication panel, a hash-chained record of what each model did — and none of them are things the SDK provides or should. **Verdict: adopt in part.** Scheduling and per-agent state: yes. The registry and governance layer: keep what exists. ## Remote MCP servers with OAuth This build's tool surface is already an MCP server. It runs locally, over stdio, through a bridge on the owner's machine, and it is reachable by exactly the clients configured on that machine. Cloudflare hosts remote MCP servers as Workers, with `workers-oauth-provider` handling the authorization flow. The server becomes a URL. Any MCP client — Claude, an inspector, another agent, a partner's tooling — can attach to it by signing in, and the OAuth layer decides what each caller can see. Three consequences for this build specifically. **The bridge stops being a single point of failure.** Same argument as Part 3: capability that lives on a laptop is offline when the laptop is. **Scope becomes structural rather than conventional.** This build has one act-scoped token that can edit articles and call every tool, plus a separate admin key. That is a deliberate design and it is documented. But it is enforced by the token check inside each handler, not by the protocol. An OAuth-fronted MCP server can present a different tool list to a different principal, which is a stronger form of the same idea. **The build becomes attachable.** Its whole premise is that work is an object other agents can lease and act on. A public, authenticated MCP endpoint is the most direct expression of that premise available. **Verdict: install.** This is the most on-thesis item in the entire series. ## Hibernatable WebSockets Worth separating from the SDK, because it applies to Durable Objects generally and this build already has three classes. A Durable Object holding a WebSocket normally stays in memory for the life of the connection. With the hibernation API, the DO can be evicted while the socket stays open, and is revived when a message actually arrives. The cost of an idle connection goes to approximately nothing. The build has an obvious use: a live view of what agents are doing. Right now, watching the build work means polling an endpoint or reading a ledger tail. A hibernatable socket makes a push feed cheap enough to leave open indefinitely. **Verdict: later.** Real, cheap, and not urgent until there is a surface that wants to watch. ## What this part does not recommend **Do not rewrite `AgentDO` onto the SDK wholesale.** The temptation with a well-designed framework is to adopt all of it, and the parts of this build's agent layer that look like re-implementation are mostly not. The governor, the adjudication panel, the law-bound prompts and the turn ledger encode decisions that took months of corrections to arrive at. A framework migration that quietly drops them would be a regression wearing the clothes of an upgrade. The rule to apply: adopt the platform where the platform provides *mechanism* — scheduling, storage isolation, connection handling. Keep what encodes *judgment*. ## Verdicts | Product | What it replaces here | Verdict | | --- | --- | --- | | Agents SDK — scheduling | One shared cron firing every minute for all scheduled behaviour | **install** | | Agents SDK — per-agent SQLite | Agent memory in shared D1 tables keyed by name | **install** | | Agents SDK — turn loop, registry | The existing governor, prompts and turn ledger | **keep what exists** | | Remote MCP server + OAuth | A stdio MCP bridge on one laptop | **install** | | Hibernatable WebSockets | Polling an endpoint to watch agents work | **later** | Next: [Part 5 — media](/a/cloudflare-os-xl-05-media). ## Sources 1. Cloudflare Agents SDK documentation — https://developers.cloudflare.com/agents/ 2. Workers for Platforms documentation — https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ --- # Cloudflare OS: search and retrieval slug: cloudflare-os-xl-01-search-and-retrieval · https://miscsubjects.com/a/cloudflare-os-xl-01-search-and-retrieval · category: systems · tags: cloudflare, vectorize, retrieval, d1, infrastructure · updated 2026-08-06T03:28:32.619Z *Part 1 of [Cloudflare OS XL](/a/cloudflare-os-xl), an inventory of the Cloudflare platform this build does not have installed.* This build holds 1,171 published articles, several thousand atomized claims, a source ledger, an audit chain, a lead table and a directory of roughly nine hundred callable rows. Every one of those is searched the same way: a SQL `LIKE '%term%'` against D1, or an exact-key lookup in KV. That works when you know the word. It fails completely when you know the idea. Ask this build "which articles argue that a gate must measure the object it claims to measure" and there is no query that answers it, because the sentence that makes the argument may not contain any of those words. The corpus knows the answer. The build cannot reach it. Three Cloudflare products close that, and none of them are installed. ## Vectorize Vectorize is Cloudflare's vector database, bound directly into a Worker. You create an index with a fixed dimensionality and metric, write vectors with metadata, and query by nearest neighbour. ``` wrangler vectorize create loop-corpus --dimensions=768 --metric=cosine ``` ```toml [[vectorize]] binding = "CORPUS" index_name = "loop-corpus" ``` The embedding model is already here — Workers AI is bound on both the Pages project and the sibling Worker, and `@cf/baai/bge-base-en-v1.5` produces 768-dimension vectors without leaving the account. So the whole loop is inside Cloudflare: read the article from D1, embed it with the AI binding, upsert into Vectorize with the slug and claim id as metadata, query it from the same Worker. What it changes here, concretely: - **Claim-level retrieval.** The unit is not the article, it is the claim. Every claim already has an id, a tier and a text field. Embedding claims rather than articles means a search returns *the specific assertion*, which is the addressable object this build is built around, and metadata filtering lets a query say "only claims at tier `human` or `rct`". - **Duplicate detection at the write path.** Before an article publishes, the write path could ask whether any existing claim is within a cosine distance of the incoming one. The corpus has grown by swarm passes; some of it says the same thing twice in different words, and there is currently no mechanism that could know. - **Lead matching.** The lead table and the content corpus are unrelated tables today. With both embedded, "which article should this clinic receive" becomes a query rather than a guess. - **The directory.** Nine hundred tool rows with descriptions is exactly the retrieval problem vector search is for. An agent looking for the right capability currently reads a list. Vectorize is metadata-filterable and namespace-partitioned, so one index can hold claims, articles, leads and directory rows without them contaminating each other's results. **Verdict: install.** This is the single highest-value absent product in the account, and everything it needs — Workers AI, D1, the claim structure — is already in place. ## AI Search, formerly AutoRAG The product this build's directory still refers to as AutoRAG has been renamed Cloudflare AI Search. It is the managed version of the pipeline described above: point it at an R2 bucket, and Cloudflare crawls it, chunks it, embeds it, stores the vectors, keeps them in sync as the bucket changes, and exposes both a raw `search` and an `aiSearch` that returns a generated answer with citations. The difference from Vectorize is ownership of the pipeline. With Vectorize you write the chunker, choose the model, handle re-embedding on edit, and own the freshness problem. With AI Search, Cloudflare owns all of it and you own a bucket. For this build the two are not competitors, they are different jobs: - **AI Search** suits the *reference* material — the vendor documentation absorbed into R2, the Grok docs pulled verbatim from `llms.txt`, the Workspace and Wrangler surfaces, the absorbed repositories. That content is written once, read often, and nobody needs claim-level addressability into it. Turning that bucket into an AI Search index gives every agent a documentation oracle with citations for near zero code. - **Vectorize** suits the *corpus* — articles and claims — because the retrieval unit has to be the claim id, the metadata filter has to be the evidence tier, and the write path has to control exactly when a vector is refreshed. There is also a third property worth noting: AI Search exposes an MCP server. The documentation oracle becomes a tool any model client can attach to without this build writing the bridge. **Verdict: install, for the reference bucket only.** Do not point it at the article corpus; that content needs the control Vectorize gives. ## D1 read replication and the Sessions API This one is not retrieval, it is the same problem from the other side: the corpus is read globally and written from one place. D1 supports read replicas. Replicas are created and placed automatically; the application opts in per request by starting a *session*, which is what preserves sequential consistency — read-your-writes — across a set of queries that might otherwise land on a replica that has not caught up yet. ```js const session = env.DB.withSession('first-primary'); const { results } = await session.prepare('SELECT ...').all(); // bookmark travels with the response; the next request resumes the session ``` The shape of this build's traffic is exactly the shape read replication is for. The content spine is read on every page render, every API article fetch, every sitemap build, every feed. It is written by a handful of agents. Today every one of those reads crosses to wherever the primary lives. The cost of adopting it is real but bounded: read paths must be audited to decide which ones need read-your-writes and which are happy with an eventually consistent replica. The article render is happy. The write path's own read-back after a PUT is not, and must carry the bookmark. **Verdict: install, after an audit of the read paths.** It is a configuration change and a code change in one place, and it is free. ## What this part does not recommend There is a fourth option that looks adjacent and is not: putting the corpus in an external vector store and reaching it over HTTP. It would work. It would also put a network hop, a second vendor, a second credential and a second failure mode into the hot path of every page render, in exchange for nothing this account cannot already do inside its own bindings. The reason to run on one platform is that the bindings do not go down separately from the Worker. ## Verdicts | Product | What it replaces here | Verdict | | --- | --- | --- | | Vectorize | `LIKE '%term%'` over 1,171 articles; no claim-level retrieval at all | **install** | | AI Search (AutoRAG) | Agents reading absorbed vendor docs by grepping files | **install** — reference bucket only | | D1 read replication | Every global read crossing to the primary | **install** — after read-path audit | | External vector store | Nothing. It adds a vendor and a hop | **no** | Next: [Part 2 — the ledger as a queryable table](/a/cloudflare-os-xl-02-ledger-as-a-table). ## Sources 1. Cloudflare Vectorize documentation — https://developers.cloudflare.com/vectorize/ 2. Cloudflare AI Search documentation — https://developers.cloudflare.com/autorag/ 3. Cloudflare D1 documentation — https://developers.cloudflare.com/d1/ --- # Cloudflare OS: what this build has not installed slug: cloudflare-os-xl · https://miscsubjects.com/a/cloudflare-os-xl · category: systems · tags: cloudflare, infrastructure, inventory, workers, audit · updated 2026-08-06T03:28:31.965Z This build runs on Cloudflare. Not "hosted on" — runs on. The site is Cloudflare Pages. The content spine is D1. The ledger is D1 and R2. The agent memory is Durable Objects with SQLite. The models are called through Workers AI and the AI Gateway. Long jobs are Workflows. Fan-out is Queues. Page-fetching is Browser Rendering. Outbound mail is a `send_email` binding. Secrets are in Secrets Store. That is thirteen Cloudflare products, bound and in production, doing real work every hour. It is also less than a third of what the account can hold. This series is the inventory of the rest: every Cloudflare product that is not installed here, what it would actually do for this specific build, and — this matters more — an honest verdict on whether it should be installed at all. A list of everything a vendor sells is a brochure. This is not that. Several entries below end in "no", and the reasons are given. ## What is already here Verified against the account and every `wrangler.toml` in the repo on 6 August 2026, not from memory: | Product | State in this build | | --- | --- | | Workers + Pages | The site, the API, the admin surface | | D1 | 4 databases: content spine, shared events, storage index, previews | | KV | 1 namespace: settings, freeze flags, snapshots | | R2 | 2 buckets: ledger, store | | Durable Objects (SQLite) | 3 classes: DirectoryDO, ExpertDO, AgentDO | | Queues | 3: loop-tasks, loop-ingest, loop-ingest-dlq | | Workflows | 10, across two Workers | | Workers AI | Bound on Pages and on the sibling Worker | | AI Gateway | Every model call routes through it | | Browser Rendering | `MYBROWSER` binding on the sibling Worker | | Email (outbound) | `send_email` binding | | Secrets Store | Meta credentials, bound by reference | | Service bindings | STORE, META_BRIDGE | | Cron triggers | Every minute, and 04:00 daily | | Observability | Enabled on every Worker | ## What is empty Four products were checked directly against the account rather than inferred from config. All four returned nothing: ``` wrangler vectorize list → You haven't created any indexes on this account. wrangler hyperdrive list → (empty) wrangler pipelines list → No pipelines found. wrangler containers list → No containers found. ``` Everything else in this series is absent by config scan: no binding, no route, no reference anywhere in the repo that does more than mention the name in a documentation row. That distinction is worth stating plainly, because this build has a directory of roughly nine hundred callable rows and several of them *describe* products that are not installed. A row that documents Turnstile is not Turnstile. The inventory below counts bindings and provisioned resources, not documentation. ## The ten parts **[Part 1 — Search and retrieval](/a/cloudflare-os-xl-01-search-and-retrieval)** Vectorize, AI Search (formerly AutoRAG), and D1 read replication. The corpus is 1,171 articles and is queried with SQL `LIKE`. This is the largest single gap in the build. **[Part 2 — The ledger as a queryable table](/a/cloudflare-os-xl-02-ledger-as-a-table)** Pipelines, R2 Data Catalog, R2 SQL, R2 event notifications, Analytics Engine. Audit questions are currently answered by pulling files and counting in a script. **[Part 3 — Running real code](/a/cloudflare-os-xl-03-running-real-code)** Containers, the Sandbox SDK, and Code Mode. Every heavy tool in this build shells out to the owner's laptop. That is the single biggest reliability liability in the system. **[Part 4 — Agents as infrastructure](/a/cloudflare-os-xl-04-agents-as-infrastructure)** The Agents SDK, remote MCP servers with OAuth, hibernatable WebSockets. Two Durable Object classes already do a hand-rolled version of this. **[Part 5 — Media](/a/cloudflare-os-xl-05-media)** Images, Stream, Realtime. Hero images are generated externally and stored as raw R2 objects with no variants. **[Part 6 — The edge in front of the Worker](/a/cloudflare-os-xl-06-the-edge-in-front)** Snippets, the rate-limit binding, Turnstile, Cache Reserve. The admin key and the token-mint endpoint are rate-limited by nothing. **[Part 7 — Seeing what happened](/a/cloudflare-os-xl-07-seeing-what-happened)** Logpush, Log Explorer, Tail Workers, Workers Builds, gradual deployments. A Tail Worker is the missing mechanical link between "it broke" and "a task row exists". **[Part 8 — Reaching private things](/a/cloudflare-os-xl-08-reaching-private-things)** Hyperdrive, Workers VPC, Tunnel, mTLS certificates. The honest fix for the local bridge. **[Part 9 — The security surface](/a/cloudflare-os-xl-09-the-security-surface)** Access, WAF custom rules, inbound Email Routing, API Shield. Only half of email is installed. **[Part 10 — Hosting other builds](/a/cloudflare-os-xl-10-hosting-other-builds)** Workers for Platforms, Terraform, Radar. The ceiling: the point where this stops being one site. ## The two that fix existing failures Everything in this series is new capability except two entries, and those two are different in kind because they close failure classes already written into this build's failure vault. **Tail Workers** (Part 7). When a Worker throws, the trace goes to observability and a human has to go look. A Tail Worker is a Worker that consumes another Worker's invocation logs, so a thrown exception can *append a task row naming the failure class* without anyone reading a dashboard. This build's central rule is that a failure becomes a child task rather than a sentence in a report. Right now that rule depends on an agent noticing. A Tail Worker makes it mechanical. **Code Mode** (Part 3). A model calling nine hundred single-purpose tools spends most of its calls discovering contracts rather than doing work — measured on the `misc` agent, roughly fourteen of twenty calls. Code Mode inverts it: the model writes TypeScript against a generated API and runs it in a sandbox, so discovery happens once, at codegen time, instead of once per call. Those two are not enrichment. They are repairs. ## How to read the verdicts Each part ends with a table of the same three columns: the product, what it would replace here, and a verdict of **install**, **later**, or **no**. "No" is used honestly — Waiting Room, Load Balancing and Spectrum are all real products that this build has no business installing, and saying so is more useful than listing them as opportunities. ## Sources 1. Cloudflare D1 documentation — https://developers.cloudflare.com/d1/ 2. Cloudflare Queues documentation — https://developers.cloudflare.com/queues/ 3. Workers for Platforms documentation — https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/