Cloudflare Just Rebuilt the Web for AI Agents (In One Day)
Site Owner
发布于 2026-07-08
Cloudflare Just Rebuilt the Web for AI Agents In One Day On April 17, 2026, Cloudflare shipped eight announcements in a single day. Every one of them assumes the same thing: AI agents are now the prim...
Cloudflare Just Rebuilt the Web for AI Agents (In One Day)
On April 17, 2026, Cloudflare shipped eight announcements in a single day. Every one of them assumes the same thing: AI agents are now the primary client of the web, and the protocol stack hasn't caught up.
The release is called Agents Week 2026, and it lands like a coordinated drop: a public score for measuring whether your site is agent-ready, a managed memory service for long-running agents, a lossless compression system for GPU inference, an HTTP delta-compression standard first tried in 2008 and abandoned in 2017, and a network performance update that put Cloudflare at #1 in 60% of the top-1000 networks. Plus an x402 payments push, a Cloudflare Access rewrite for OAuth, and a feature-flag product built for the agent era.
Read them as one document and a thesis emerges. The web is being rebuilt so machines can consume it cleanly. Sites that don't get rebuilt will keep paying for it in tokens, latency, and missed workflows.
This post walks through the four pieces that matter most for developers, and the one uncomfortable number buried in the announcement: only 4% of the top 200,000 sites declare any AI usage preference in their robots.txt.
The Agent Readiness score: 4% of the web is ready for agents
Cloudflare Radar scanned the 200,000 most-visited domains, filtered out redirects and ad servers, and ran them through a new tool at . The score checks four categories: discoverability, content, bot access control, and capabilities.
#AI 基础设施#GPU#上下文工程#Agent Memory#Agent
Cloudflare Agents Week: 8 Releases That Rebuild the Web for AI
78% of sites have a robots.txt. The vast majority are written for traditional search crawlers, not agents.
4% of sites declare their AI usage preferences through Content Signals.
3.9% of sites respond to Accept: text/markdown with markdown content.
MCP Server Cards and API Catalogs (RFC 9727) together appear on fewer than 15 sites in the entire dataset.
If you remember the early 2010s when Google pushed HTTPS adoption with a Chrome warning and a ranking boost, the structure of this is identical. Score a property, publish the data weekly, expose the gap. Cloudflare is not subtle about the model. "Scores and audits that provide actionable feedback have helped to drive adoption of new standards before," the post reads. "For example, Google Lighthouse scores websites on performance and security best practices. We think something similar should exist to help site owners adopt best practices for agents."
The cleverest part isn't the score itself. It's that for every failing check, the site gives you a prompt you can hand to your coding agent and have it implement the fix. The tool that grades agent-readiness is itself agent-readable, exposes a stateless MCP server at /.well-known/mcp.json with a scan_site tool, and publishes an Agent Skills index. It practices what it preaches.
Cloudflare's own developer docs were rebuilt against these standards before launch. The result, measured with Kimi-k2.5 via OpenCode against other large technical doc sites: agents consume 31% fewer tokens and answer 66% faster than on average non-agent-refined sites.
The technique worth stealing is in the URL rewrite. Every Cloudflare docs page is also available as markdown via /index.md, and there's no static file duplication. A URL Rewrite Rule strips /index.md to the base path; a Request Header Transform Rule inspects the original path before the rewrite and forces Accept: text/markdown. Two Cloudflare Rules, no build step, every page now has a markdown twin.
For llms.txt, Cloudflare doesn't ship one giant file. Each top-level directory gets its own llms.txt (e.g. developers.cloudflare.com/r2/llms.txt), the root one is a directory of directories, and roughly 450 directory-listing pages that have no semantic value to an LLM are excluded. The goal is that the entire directory fits inside the agent's context window. A 5,000-page doc site in one file exceeds the window and forces the agent into a grep loop. The grep loop costs thinking tokens, costs latency, and reduces accuracy. The fix is structure, not cleverness.
The grep-loop pattern is the most important thing to internalize. When an agent is fed a single massive llms.txt, it can't read the whole file, so it searches for keywords. If the first search misses, it refines, retries, and burns context. The accuracy drop is a side effect of losing the broader context. A well-structured docs site that fits in the window lets the agent identify the right page and fetch it in one shot. The 31% token saving and 66% speed-up at Cloudflare is a downstream effect of structure, not prose.
If you run any site with a developer or AI-tooling audience, run it through isitagentready.com today. The score is public. The gap is real. And the fix for most sites is two Rules and a few Content-Signal directives.
Agent Memory: five retrieval channels, fused by RRF
The most ambitious release is Agent Memory, now in private beta. It's a managed service that does what every agent framework currently does badly: remember things across sessions without filling the context window.
The interface is small. A profile has five operations: ingest (bulk extraction at compaction), remember (model stores a single fact), recall (synthesized retrieval), list, and forget. Under the hood, the pipeline is more interesting.
Ingestion. Every message gets a content-addressed ID — a SHA-256 of session ID, role, and content, truncated to 128 bits. Re-ingesting the same conversation is idempotent. The extractor runs two passes: a full pass that chunks at ~10K characters with two-message overlap, and a detail pass for long conversations (9+ messages) that focuses on concrete values like names, prices, version numbers. The detail pass catches things the broad pass generalizes away.
Each extracted memory is then verified against the source transcript by an eight-check pipeline: entity identity, object identity, location context, temporal accuracy, organizational context, completeness, relational context, and whether inferred facts are actually supported. Passed, corrected, or dropped.
Verified memories are classified into four types:
Facts — atomic stable knowledge, e.g. "the project uses GraphQL." Keyed and superseded, not deleted.
Events — what happened at a specific time.
Instructions — procedures, runbooks, workflows.
Tasks — what is being worked on right now, ephemeral by design.
Facts and instructions get a normalized topic key. When a new memory has the same key as an old one, the old memory gets a forward pointer to the new one. You get a version chain. Tasks are excluded from the vector index but remain discoverable via full-text search, which keeps the vector index lean.
Retrieval. When an agent calls recall, the query goes through a five-channel parallel retrieval, fused by Reciprocal Rank Fusion. The channels are:
Full-text search with Porter stemming for keyword precision.
Raw message search on the original stored conversation, a safety net for verbatim details the extraction pipeline may have generalized away.
Direct vector search over embedded memories.
HyDE vector search — embed a hypothetical declarative answer to the query, then find memories similar to that answer. Surfaces results for abstract or multi-hop queries where the question and the answer use different vocabulary.
Results are weighted: fact-key matches highest, full-text / HyDE / direct vectors based on signal strength, raw message matches lowest as a safety net. Ties broken by recency. The top candidates go to a synthesis model, except for temporal computation, which is handled deterministically by regex and arithmetic. LLMs are unreliable at date math; the system doesn't ask them to do it.
The interesting modeling choice is at the model tier. Cloudflare's own pipeline runs Llama 4 Scout (17B, 16-expert MoE) for extraction, verification, classification, and query analysis, and Nemotron 3 (120B MoE, 12B active) for synthesis. Scout handles the structured tasks efficiently; Nemotron's larger reasoning capacity improves the natural-language answers. "A bigger, more powerful model isn't always better," the post says. "The synthesizer is the only stage where throwing more parameters at the problem consistently helped."
That's a useful counter-pattern to the "use the biggest model for everything" reflex most teams have. Most agent pipelines will benefit from a small structured model for routing and a large model only for synthesis.
The storage substrate is worth noting. Each memory profile maps to its own Durable Object with a SQLite-backed store. Strong tenant isolation with no infrastructure overhead. Vectors live in Vectorize. Future snapshots and exports go to R2. Each primitive is purpose-built. Nothing is forced into a single database. Compute is Workers AI; requests carry a session affinity header routed to the memory profile name, so repeated calls hit the same backend and benefit from prompt caching.
The least-flashy but most important sentence in the post: "Your data is yours. Every memory is exportable, and we're committed to making sure the knowledge your agents accumulate on Cloudflare can leave with you if your needs change." That is the only line that will decide whether Agent Memory becomes a default or a vendor lock-in. Cloudflare is betting on making leaving easy enough that nobody wants to.
The competitive frame matters. Microsoft Research's PlugMem showed that more memory can make agents worse. The benchmark suite (LongMemEval, LoCoMo, BEAM) is now the de facto evaluation set, and Cloudflare explicitly tests against all three to push the system in different directions. The agentic-memory space is one of the fastest-moving in AI infrastructure; Cloudflare is positioning the platform with a managed-service default and a constrained tool surface, on the bet that giving agents raw filesystem access is the wrong answer for production.
Unweight: 22% smaller models, bit-exact outputs, no special hardware
The third major release is Unweight, a lossless compression system for LLM weights, targeting H100 GPUs. Results on Llama 3.1 8B: ~22% model size reduction for distribution bundles, ~13% reduction for inference bundles (compressing only the gate and up MLP projections), with bit-exact outputs and no quantization.
The key insight is that BF16 weights have a 1-bit sign, an 8-bit exponent, and a 7-bit mantissa. The sign and mantissa look like random data and can't be meaningfully compressed. The exponent is a different story: in a typical LLM layer, the top 16 exponent values account for over 99% of all weights. Information theory says you only need ~2.6 bits to represent that distribution. Unweight Huffman-codes the exponent stream, achieving ~30% compression on the exponents themselves, applied selectively to the MLP weight matrices that make up roughly two-thirds of a model's parameters.
The trick is in the decoding. Compressing is easy; decompressing without slowing inference is hard. On an H100, the tensor cores can process data roughly 600 times faster than HBM can deliver it. The bottleneck is the memory bus. Most prior work (ZipNN, Huff-LLM, ZipServ) decompresses the weights back into HBM, then runs a standard matmul. That helps with storage capacity but does nothing for bandwidth — you still read the full uncompressed matrix from HBM every token.
Unweight's answer: decompress in fast on-chip shared memory and feed the results directly to the tensor cores, no round-trip through main memory. The reconstructed weights never exist in HBM. The producer/consumer split inside the kernel uses TMA hardware to stage sign+mantissa bytes, exponent data, and verbatim rows with rare exponents; the consumer reconstructs BF16 values and feeds them directly to Hopper's WGMMA tensor-core instructions.
The decompress-in-shared-memory approach has a known cost. On Llama 3.1 8B, the inference configuration saves ~13% of model memory at a 30–40% throughput cost at typical serving batch sizes. The gap narrows at larger batches (where preprocess overlap improves). Cloudflare is explicit that this is not a free lunch: on-chip reconstruction adds work, and the company has not yet compressed the down projection (~one-third of compressible weights) or optimized the small-batch fixed costs.
The interesting design choice is that Unweight doesn't hard-code a single execution strategy. There are four pipelines — full Huffman decode, exponent-only decode, palette transcode, and direct palette — and the runtime picks the best one for each weight matrix at each batch size, driven by an autotuner that measures actual end-to-end throughput on the target hardware. Small batches (1–64 tokens) favor full decode + cuBLAS, because the matmul is tiny and cuBLAS overhead beats the custom kernel. Large batches (256+) favor palette or exponent pipelines, because the matmul runs long enough to absorb the reconstruction work. The autotuner sweeps configurations for gate, then up, then down, until no further improvement is found.
Pipelining across layers exploits the transformer structure. Not every layer needs Huffman decoding at runtime; "easy" layers use pre-transcoded palette data that the matmul consumes directly. While the GPU computes an easy layer, separate CUDA streams decode the next "hard" layer in the background. By the time the hard layer's turn arrives, its preprocessed data is already waiting. Double-buffered preprocess slots keep one hard layer's decode output from being overwritten while it's still being consumed.
For Cloudflare's network, the practical outcome is capacity: 13% memory savings per instance means more models on the same GPU, which means more models deployable to more edge locations, which means lower per-token inference cost. For distribution, Huffman-compressed bundles are ~22% smaller, which reduces model shipping time across the network. The compression ratios should generalize across SwiGLU architectures at all scales; throughput numbers are specific to current kernel implementations and will move as optimization continues.
The research is open-sourced — GPU kernels on GitHub and a technical paper. The next directions are down projection compression, kernel optimization for the small-batch fixed costs, and bringing the approach to MoE models where cold experts can be fetched on demand.
Shared Dictionaries: 97% bandwidth reduction, RFC 9842 lands at last
The fourth release is the one with the longest pre-history. Shared Dictionaries is RFC 9842, a compression dictionary transport standard that turns the version the browser already has into the dictionary for the next response. When a server ships app.bundle.v1.js and later app.bundle.v2.js with a one-line change, the browser sends the hash of what it has, and the server delta-compresses the new version against the old one. A 500KB bundle with a one-line change becomes a few kilobytes on the wire.
Cloudflare's lab test on a 272KB JS bundle with localized changes: gzip brought it to 92.1KB (66% reduction). DCZ (dictionary-compressed Zstandard) brought the same asset to 2.6KB — a 97% reduction over the already-compressed asset. Download times: 16ms for DCZ on a cache hit, vs 143ms for gzip. 89% faster. A live demo at canicompress.com deploys a ~94KB JS bundle every minute; the first version is stored as a dictionary, and the next version delta-compresses to roughly 159 bytes. 99.5% reduction over gzip, because the only thing on the wire is the actual diff.
The reason this took 18 years to ship is that the first attempt — Google's SDCH in Chrome 2008 — couldn't survive contact with the open web. SDCH was killed in 2017, primarily because it surfaced architectural problems and accumulated side-channel attacks (CRIME, BREACH) faster than anyone could fix them. The Same-Origin Policy conflict was a particular headache. RFC 9842 closes the security gaps by enforcing that an advertised dictionary is only usable on responses from the same origin, which removes most conditions for side-channel attacks. Chrome and Edge have shipped support; Firefox is working on it.
Cloudflare is rolling this out in three phases:
Phase 1 (April 30, 2026 open beta): passthrough support. Cloudflare forwards the Use-As-Dictionary, Available-Dictionary, and dcb/dcz content-encoding headers without modification. Cache keys are extended to vary on Available-Dictionary and Accept-Encoding. Targets customers who manage their own dictionaries at the origin.
Phase 2: rule-driven. Tell Cloudflare which assets should be used as dictionaries, and the platform injects the headers, stores the dictionary bytes, delta-compresses, and serves the right variant. Origin stays normal.
Phase 3: automatic. Cloudflare identifies versioned URL patterns from network-wide traffic, stores previous versions as dictionaries, and serves deltas without customer configuration.
This matters more now than five years ago because the deploy cadence has changed. "AI-assisted development means teams ship faster," the post says. As agents push a one-line fix, the bundler re-chunks, filenames change, and every user could re-download the entire application. "Ship ten small changes a day, and you've effectively opted out of caching."
The data on agentic traffic makes the timing concrete. According to the Shared Dictionaries post, agentic actors represented just under 10% of total requests across Cloudflare's network in March 2026, up ~60% year-over-year. Bots in total are ~31.3% of all HTTP requests. AI traffic is ~29–30% of all bot traffic. The web is no longer a human-first service. It's a co-resident service with humans and agents, and the cache layer has to know the difference.
The network underneath: 60% of top-1000, 6ms ahead
The fifth piece is the boring one, and it's the reason all the above can be deployed at scale. The network performance update reports that by December 2025, Cloudflare became the fastest provider in 60% of the top-1000 networks, up from 40% in September 2025. On average throughout December, Cloudflare was 6ms faster than the next-fastest provider. The biggest improvement was in the US, where Cloudflare is now the fastest in 54 more ASNs.
The mechanism is software, not new hardware. New points of presence in Constantine (Algeria), Malang (Indonesia), and Wroclaw (Poland) helped — Wroclaw alone took free users from 19ms to 12ms average RTT — but the bigger move was improving connection handling in software. HTTP/3, congestion window management, CPU/memory efficiency in the connection-establishment and SSL/TLS termination paths. "Adding new locations alone doesn't fully explain how we went from being #1 in 40% of networks to #1 in 60% of networks."
For agent workloads, every millisecond matters. An agent that hits an endpoint 50 times in a loop sees a 50x amplification of any per-request latency. The 6ms Cloudflare is ahead of the next provider isn't a vanity number; it's a 300ms advantage over a 50-request workflow, and an 1800ms advantage over a 300-request workflow.
The three things Cloudflare shipped that nobody else has
A day of announcements is not a strategy. What makes Agents Week 2026 worth taking seriously is the scope of what was shipped as one coordinated release:
A public scoring system for agent-readiness, with a real dataset, weekly updates, and a fixable gap on 96% of the top-200K sites.
A managed memory service with a defensible architecture: five-channel RRF retrieval, content-addressed ingestion, deterministic temporal handling, and explicit data export.
An inference compression system that doesn't trade quality for size: lossless, open-sourced, and explicitly honest about the 30–40% throughput cost.
That's not a feature release. That's an attempt to set the standards for the next layer of the agentic web.
The remaining pieces are the connective tissue: x402 for agent payments, Cloudflare Access with OAuth support so agents can get authorized properly, Flagship feature flags for the age of AI, Redirects for AI Training to keep deprecated content out of model training crawlers. Each of these is a small piece, but together they form a coherent platform: agents should be able to discover your site, consume your content, remember the conversation, pay for services, get authenticated access, and have your features gated correctly.
The question for anyone running a site today isn't whether your site works for agents. It's whether you noticed your agent-readiness score is currently 12. The standards are RFCs, the tools are public, and the gap is measurable. The next 12 months of web development are going to look a lot like the 2014–2018 HTTPS push — except the client that's judging you is no longer a browser with a padlock icon. It's an agent with a context window and a budget.
The 4% number is going to move. The question is whether your site is on the right side of the line when it does.
