Tag Archives: Developer Platform

Unifying Workers AI and AI Gateway into a single AI control plane

Post Syndicated from Michelle Chen original https://blog.cloudflare.com/workers-ai-gateway-unification/

AI Gateway and Workers AI first started as distinct products, but over time, we noticed our users were converging. With AI Gateway, you can proxy requests to any model provider and get built-in observability, logging, access, and security. On Workers AI, we host models on the GPU infrastructure that we manage, exposing an API endpoint you can leverage to access inference-as-a-service. 

The architecture of these products looks different, but to an end user, it achieves the same goal: connecting you to models with a sophisticated control plane. Today, we're excited to share our plans on how these products converge into one unified path, so you can connect to any model provider (including Workers AI), while managing things like observability, billing, security, and logging from a single control plane.

It’s the next step toward some big plans we have — read on to learn what a unified control plane means for the future of model routing.

Merging the binding and API

We've been hinting at the fact that these products are becoming more unified through our entrypoints: the Workers binding and the REST API. We have an AI binding that you can use to call AI Gateway and Workers AI. There's no concept of a separate AI Gateway and Workers AI binding: it all goes through the same path. We shipped the idea of a “default” gateway a few months ago, so that if you have never set up an AI Gateway before, you could still automatically inherit the AI Gateway observability and logging. Of course, you can still specify your own gateway if you'd like to split up applications into multiple projects.

Here's what the binding call looks like, if you are calling Workers AI via AI Gateway:

We’ve also announced a single unified REST API — the /ai/ endpoint that allows you to make similar calls to Workers AI via AI Gateway.

Doing this allows us to unify the entrypoints to AI Gateway and Workers AI, so you don't need to make a choice between which product to use first: it all comes with batteries included.

Automatic observability and control for all Workers AI users

One of the most immediate benefits of this convergence is that you no longer need to explicitly create an AI Gateway before you start getting visibility into your inference traffic. If you've never set up a gateway before, just pass default as the gateway ID in your binding or REST API calls, and AI Gateway will create it automatically on the first authenticated request.

With this, every request is logged with full request and response payloads, token counts are tracked per model, and you get cost attribution without any dashboard setup. If you later outgrow the default gateway — if you want custom caching rules or to split traffic by application — you can create a named gateway and point your requests at it with a single parameter change.

Here's how it looks in the binding. Before, you called Workers AI directly:

Now, add a third argument to route through AI Gateway and get full observability:

Head to the Cloudflare AI Gateway dashboard and you'll see every request: latency breakdowns, token usage, error rates, and the exact prompts and responses. For teams debugging model behavior or auditing AI output, this is a huge upgrade from flying blind.

New: using AI Gateway credits for Workers AI

A new thing we're launching today is the ability to use AI Gateway credits for Workers AI. Before, you could only use AI Gateway credits on external model providers (e.g., OpenAI, Anthropic) but you couldn't apply your AI Gateway credits to Workers AI usage just yet. We've finally enabled our systems to allow unified billing for Workers AI. This means that you can load a wallet full of credits, and then choose to spend that across OpenAI, Anthropic, Workers AI, or any provider that we support.

Since we're now offering pre-paid billing for Workers AI and want to encourage users to use this new path, we're also offering elevated rate limits on Workers AI models if you use AI Gateway unified billing. Please refer to the developer docs for up-to-date information regarding rate limits, as well as how to request a higher rate limit.

Coming soon: model-first routing

With all your inference traffic flowing through a single control plane, we can start making smarter decisions about how to serve each request starting with the model you want, not the provider you have to manage. Provider-first routing forces you to think about infrastructure: "Which provider do I call? What if they're down?" Model-first routing flips that. You think about what you need — a capable reasoning model, a fast summarizer, a cheap embedding model — and the control plane handles provider selection, failover, and load balancing.

Today, if you want to call a model, you have to know which provider hosts it. If that provider is down or rate-limiting you, your application breaks. We're moving toward a world where you specify the model, and AI Gateway handles the rest. 

This way, you can request Kimi K2.7 Code and not care whether it comes from Workers AI, Moonshot's own API, or another provider that hosts the same weights. If Workers AI has capacity, you get the benefit of our managed infrastructure. If Workers AI is at capacity, the gateway transparently load balances you to another provider that can serve the same model. You can still choose to stick to a single provider if you’d like, but model-first routing enables you to get more flexibility if you care about resiliency. We work with vetted providers, so the quality of model outputs remains top priority, and will also be able to respect requirements such as Zero Data Retention (ZDR).

This also means better resiliency by default. If one provider's version of a model is having issues, traffic shifts to another without application-level retries or complex fallback logic in your Workers. The gateway treats model availability as a routing problem. We hope to pilot this in the coming months for all AI Gateway and Workers AI users.

Next: smart routing

The next evolution of routing goes beyond simple failover. We're building intelligent routing that understands what you're asking for and picks the right model for the job without any configuration required.

Instead of specifying a model, you can let the gateway decide. Under the hood, a classifier running on Workers AI reads your prompt and predicts what kind of task it is (coding, research, summarization, general Q&A), how complex it is, and how much context matters. A heuristic scorer then maps that to the best model from a curated pool. For teams that want control, you can still specify exact models. For everyone else, the zero-config path means you get better economics and performance without maintaining your own routing logic. We are currently piloting this internally, and we’ll be actively testing and iterating in the next few weeks before release. 

Get started today

If you're already using Workers AI, the easiest way to try this out is to start routing your existing calls through a default gateway. You'll immediately get request logging, token tracking, and cost attribution without changing anything else about how you call the models.

If you're already using AI Gateway, adding Workers AI to the mix is as simple as calling a Workers AI model. Load up your AI Gateway wallet and you'll get unified billing across every provider we support, plus elevated rate limits on Workers AI models.

Set up your first gateway, browse the Workers AI model catalog, and get started building today.

Announcing Cloudflare Ambassadors, Community Engineers, and another $1M in open-source funding

Post Syndicated from Kristian Freeman original https://blog.cloudflare.com/community-program-refresh/

As a platform for helping build a better Internet, Cloudflare helps turn ideas into real products and experiences around the world. Across communities and backgrounds, developers build with Cloudflare using the tools they love, shaping what comes next for the Internet while inspiring, collaborating with, and teaching others.

The community is where some of Cloudflare’s best moments happen. Students show their friends how to deploy Workers for the first time. Discord users answer questions from other developers via working code samples, instead of links to documentation. Open-source contributors build novel solutions to solve their own problems, then share them with the world. Organizers host events that give builders from all backgrounds the space to start building their dream project.

All of these represent a community at its best: people helping other people build.

This spirit of community is an exciting and vital part of helping to build the Internet. Those who step up to educate and support others, or to invent, build, or maintain tools shared across the ecosystem, make lasting contributions to the health and potential of the Internet.

We want to have their backs.

That's why today we’re announcing an improved community program, designed to better support, recognize, and empower the people getting involved, while working with them to shape what comes next.
The program has two main tracks:

  1. Cloudflare Ambassadors: Bringing Cloudflare to their own communities.
  2. Cloudflare Community Engineers: Contributing to open-source projects that improve the Internet.

We’re launching a new home for the program where you can learn more and get involved: cloudflare.com/community.

Cloudflare Ambassadors

Cloudflare Ambassadors are people who bring Cloudflare into their own communities. You can probably think of people in the communities you value who share a genuine passion for a product or technology. It’s inspiring and we love to see it. When that enthusiasm includes the tools we’re building here at Cloudflare, it’s especially exciting for us.

Following our annual application process (more below), we’ll announce the year’s Cloudflare Ambassadors cohort. Selected Ambassadors will receive support, resources, and benefits to help their community thrive and bring their ideas to life. Ambassadors can serve for up to two years, giving them meaningful time to build momentum while helping us support more communities over time.

What Ambassadors do and what we provide

Being an Ambassador might mean organizing a local event, leading a student group, creating spaces where builders can learn together, publishing tutorials or sharing content online, or being the person others turn to when they want to understand what’s possible with Cloudflare. 

Ambassadors will take the lead on events in their communities, whether on campus, through local organizations, or across their city. When hosting meetups, hackathons, workshops, or talks, they will be able to apply for support in the form of credits, marketing assets, technical resources, and more.

We’ll also give them a visible role in Cloudflare’s online community spaces, including Discord, so that other developers know who they are, and that they’re here to help.

Applications are open now, and will be accepted through September 6. Those selected as Ambassadors will be informed of their selection by October 5.
Apply to become a Cloudflare Ambassador

A great example of the enthusiasm we’re looking for comes from Sruthi Pereddy, a Computer Science major at University of Michigan and a current intern on Cloudflare’s Recruiting Ops team. Sruthi’s work within Cloudflare has created a drive to share and explore more with others:

“Whether it’s hackathons, startup venture funds, or coursework, I want to show my peers that Cloudflare is a go-to developer platform for whatever they’re building,” Pereddy says. “Students are ready to build, but often feel constrained by resources. I’m excited to bridge that gap and make sure they have the infrastructure to turn their ideas into reality from day one.”

Cloudflare Community Engineers

Some community work happens in person, but a great deal of community work also happens in code. Much of Cloudflare’s Developer Platform is built on open-source work, or is open-source, like workerd and quiche. Open-source contributors, especially maintainers, do wonderful work and embody so much passion and determination. We’re eager to support them, especially since their work can sometimes feel thankless. So we’re doubling down on our efforts to build stronger incentives and directly support the maintainers doing this important work.

Last year, we announced our sponsorship of the web framework TanStack. TanStack creator Tanner Linsley says that sponsorship has had a major impact.

“Cloudflare’s sponsorship has given us room to keep investing in foundational open-source work that’s hard to tie to a single product or launch, maintaining the core libraries, improving docs and tooling, supporting contributors, and putting real time into bigger bets like TanStack Router and Start,” Linsley says. “It’s also helped us make sure TanStack apps have a really solid path onto Cloudflare’s platform. More than anything, that support buys stability, which is kind of everything when you’re building open source for the long haul.”

Today, we’re expanding on our previous open-source investments by introducing Cloudflare Community Engineers. Earlier this year, we announced a $1M fund as part of our acquisition of VoidZero to support the Vite community. We’re committing an additional $1M in funding to sponsor and support open-source projects over the next two years, with eligible Community Engineers receiving grants from the fund to support their continuing work in open source.

The Community Engineer program does not have a maximum term. Open source work doesn’t neatly fit into annual cycles. Some projects require maintenance for years, while other times, contributors do the work that is needed at exactly the right moment. This program is intended to support that.

To begin, we’ll focus on developers working on things in the orbit of our own open-source projects — projects like Astro, Agents SDK, EmDash, Hono, and Vinext. We’ll also grant our Community Engineers a special designation in Cloudflare’s Discord server and other online spaces.

Applications for Community Engineer grants will open at a later date.

Making our Discord better as it grows

Since we launched Cloudflare’s Discord server in 2020, almost 100,000 Cloudflare users have joined. Our Discord server has become one of the main places where developers ask questions, share projects, and provide valuable feedback. But of course, the more a Discord community grows, the more effort is required to keep it healthy and approachable.

To address this, a new Discord committee will help to maintain and grow our Discord community, with Cloudflare Ambassadors joining Cloudflare staff on the committee.

This is not about being on hand to perform moderation and admin tasks. We’ve been building tools and automations to help us do that with far less human intervention. Our new automated protections against spam and malicious links are starting to relieve this burden, allowing our Developer Relations team to help manage things where some human insight is needed.

In fact, we’ll be open-sourcing and sharing those tools soon because we think every Discord server could benefit from less spam and malicious content.

The committee will help provide a useful connection to those building and managing products at Cloudflare. They’ll be able to steer people and conversations to domain experts and convene conversations and sessions with internal teams and makers around the community. They’ll be much more focused on content and opportunities than on the type of Discord administrivia that can otherwise swallow so much time and energy.

We want our Discord to be easier to use, contribute to, and trust. It should be a place where builders find each other, help each other, and shape the future of the platform together. We believe this is the way.

Ready, set, go!

To learn more about the community program, and to apply for a role, visit the new community site at cloudflare.com/community.

Applications to join the 2026-27 Cloudflare Ambassadors cohort have now officially opened. Be sure to apply by September 6.

And don’t forget to join the conversation in the Cloudflare Discord.

Introducing Radar Researcher: An AI tool for exploring Internet data in plain language

Post Syndicated from Lai Yi Ohlsen original https://blog.cloudflare.com/introducing-radar-researcher/

Since launching in 2020, Cloudflare Radar has provided one-of-a-kind insight into Internet traffic on a global scale. The open data that Radar publishes from our global network is used by a variety of experts in different domains: human rights advocates, journalists, academic researchers, network operators, and more.

Today, as part of Agents Week, Radar is beta-launching a new tool: Radar Researcher. 

Now, if you want to answer a question with Radar’s data, you can just ask in plain language and get an answer back with real, interactive charts, all built on Cloudflare's developer platform. You no longer need to find the right page, choose the right filters, or read the API documentation to write a query. 

Why we built Radar Researcher

Over the past six years, the Radar team has worked to provide clear, accessible, reliable data visualizations of complex datasets. This is not without its challenges: our user base is vast and ranges from curious novices to technical network experts. Even so, we publish as much insight into the Internet as seen from our network as we can: DNS queries from our public resolver 1.1.1.1, HTTP traffic from across our global network, network quality data collected from Cloudflare Speed Test, and so much more. We also believe in the power of open, public data, which is why everything you see in Radar’s data visualizations is available via our free API. Every year we make more and more of the Internet visible. 

But as Radar has evolved, so has the technology for working with data. AI tools are lowering the barrier to expertise: you no longer need to know a dataset's structure or vocabulary to get useful answers from it. Subject-matter experts become collaborators rather than gatekeepers.

Radar has always wanted to do more for users who shouldn't need to master our entire catalog and its vocabulary to fully appreciate our insights. (See our recent blog post on how the Internet responded to the 2026 FIFA World Cup.) 

We also know that many of our users are in a hurry. For example, a journalist writing about the latest Internet outage likely does not have the time to search through each page for the perfect graph to tell their story. This is why we built Radar Researcher.

Meet Radar Researcher

Radar Researcher is built to make accessing data as easy as describing what you’re looking for. All information is provided via Radar’s API, which ensures that the underlying LLM relies on real data, and can answer your questions quickly and in the same format as you would articulate them to a human.

It's available on every Radar page. Open the Radar Researcher panel from the header, and it docks beside whatever you're looking at, so you can keep browsing while you chat. Here are some examples of how you can use it: 

  • Get an answer in plain language, with real charts: Ask a question and get the same interactive visualizations you see across Radar, plus a short explanation.
  • Choose your depth: Pick a concise, direct answer or a fuller, multi-topic report.
  • Keep the analysis going: After each answer, it suggests useful follow-up questions.
  • Pick up where you left off: Conversations are saved in a searchable history you can pin and revisit, and you can share any conversation with a link. (Shared links expire automatically after 30 days.)
  • Audit the reasoning: Check how the LLM interpreted your question, which datasets it looked up and queried, and how it worked through the results to reach its answer.
  • Ask your way: Type, use voice input, or launch it straight from Radar's search bar.

Turn any chart into a conversation

Researcher doesn't only start from a blank prompt. Anywhere you see a chart on Radar, an Explain with AI action opens the assistant with that exact visualization already in hand. 

Instead of asking you to describe what you're looking at, it captures the exact visualization you're viewing and starts the conversation there. As you can see below, Radar Researcher takes the visualization in context, then analyzes the data and responds with an explanation.

Under the hood, the assistant hands the model three things at once: a screenshot of the chart (a vision-capable model reads the image directly), the exact data behind it from Radar's API, and the parameters of your current view, including location, date range, and any filters you've applied. The screenshot enables Radar Researcher to see what you see. The raw data keeps every number it cites precise instead of estimated from pixels, and the filters mean the explanation is about your exact view, not a generic version of the chart.

Use Case No. 1: What’s Internet quality like in Portugal?

Say you're curious how good the home Internet is in a given country. You can just ask:

Instead of manually calling the API, choosing parameters, or hunting through Radar's pages, Radar Researcher interprets the question and does the work for you. You can follow each step in the screenshot: it reads what you asked, queries Radar's Internet quality API, then analyzes the results and answers in plain language. And rather than a wall of numbers, it renders the same interactive charts you'd see on the Radar Internet Quality section.

From here you might ask a natural follow-up, like comparing Portugal to a neighbor, and Radar Researcher fetches fresh data for each one. It even suggests useful next steps of its own, such as how Portugal stacks up against Spain or the country's most common Internet outages. By letting you find what you're looking for in plain language, we hope applying Radar's data to your own analysis is easier than ever.

Use Case No. 2: Investigating an Internet disruption

Radar Researcher is also built with technical experts in mind. If we know one thing about engineers, researchers, and network operators, it’s that automation is key to their workflows. Looking at the same data with manual actions can be cumbersome and limiting: how do you ensure you're always looking at the most relevant data? 

Consider a real event. In early 2026, Iran went through a series of government-directed Internet shutdowns, including one that lasted nearly three months before traffic partially returned in May. Reporting a story like that means pulling several views and refreshing them as the situation develops. To investigate it, you can just ask Radar Researcher:

This time the question is open-ended, so Radar Researcher runs a short investigation. It looks up the outage events Cloudflare Radar recorded for Iran and gathers the matching traffic data, then explains the timeline in plain language: Iran's HTTP traffic index collapsed from around 0.58 on January 7 to effectively zero by January 9, began a partial recovery around January 17, and returned close to pre-shutdown levels by January 27. It presents this as an HTTP traffic index chart with the outage window annotated directly on the line, plus a table of the recorded outages that also flags a second shutdown starting February 28.

From there it suggests where to take the investigation next, such as how the traffic compared with neighboring countries.

How we built it

Radar Researcher is built entirely on Cloudflare's own developer platform. It's a showcase of the same tools any developer can use to build an AI agent.

At its core is a Cloudflare Worker running the Cloudflare Agents SDK. Each conversation is a stateful Durable Object with its own SQLite database, so your chat history, titles, and streaming responses persist. They even survive you leaving the page mid-answer, because generation continues server-side and resumes when you reconnect.
The "brain" is Workers AI, running open models like Kimi K2.7. Rather than betting on a single model, we run an ordered fallback chain across three different model families. If one model is momentarily at capacity, the request transparently cascades to the next, so an incident at any single provider doesn’t take Researcher down. Every call routes through AI Gateway for logging, cost tracking, caching, and safety guardrails.

The most interesting part is how Researcher reaches Radar's data. Instead of hand-writing a tool for every one of Radar's hundreds of endpoints, we connect the agent to the unified Cloudflare MCP server using Code Mode. The model gets just three tools (search, execute, and docs) and writes code to query the Radar API directly. It searches the OpenAPI spec to find the right endpoint, then executes a small snippet that fetches live data. Because the full API spec lives on the MCP server, nothing about Radar's API is hard-coded into the prompt. As Radar adds datasets, Researcher can use them with no code changes.

This is visible to you, too: every answer includes an expandable trace of the model's reasoning and the exact tool calls it made to gather the data, so you can always see how it got there.

From Markdown to real Radar charts

There was one problem to solve along the way. Language models answer in Markdown: text, tables, and bullet points. But we didn't want walls of numbers; we wanted the same rich, interactive charts you see everywhere else on Radar. Worse, when a model tries to write data directly into its answer, it tends to round, summarize, or truncate it, which is exactly what you don't want from a data tool.

Our solution keeps the data out of the model's prose entirely. When Radar Researcher fetches data, its code returns a small envelope that pairs the API path with the result. Then, instead of pasting numbers, the model emits a lightweight chart specification that simply references that same path:

Radar's frontend matches the chart's dataFrom to the fetched result and renders it with the exact same visualization components used across the rest of the site. The chart is always faithful to the API, and Radar Researcher can draw on our whole visual vocabulary: time series and stacked areas, donuts, bar charts, maps, histograms, etc.

A few small touches

Not everything needs the big model. Small, fast models handle the side tasks: one writes a short title for each new conversation, and another suggests the follow-up questions under each answer. Both run off to the side, so they never slow down your actual reply.

Radar Researcher also gets a little context about the here and now. We pass it the current date and time, plus the same high-level details about your connection that you'll find on Radar's IP page, such as your IP location and network. That way, when you ask something like "how's traffic here?", it can tailor the answer to where you are.

Everything reaches you through Radar's frontend (also a Worker) over a service binding, with per-IP rate limiting and shareable conversations stored in R2. Every layer, from compute to inference to gateway to storage to data, is Cloudflare.

Powered by agents — and ready for them

Radar Researcher shows how we use an AI agent to help people explore our data. But there's another side to the agent story: what happens when the agent isn't ours, but a general-purpose assistant running in your browser, acting on your behalf?

Today, an agent that wants to use a website mostly has to scrape the page and guess at how it works, which is brittle, slow, and error-prone. WebMCP is an emerging web standard that fixes this: a page can register a small set of well-defined tools that any browser agent can discover and call directly, instead of reverse-engineering the DOM (Document Object Model).

We've added WebMCP support to Radar, using both flavors the standard offers:

  • The imperative API lets us register tools in JavaScript that call straight into the same code that powers the UI, so an agent can drive Radar directly. Filter to a country, region, continent, or ASN; change the date range; search pages, sections, and entities (domains, ASNs, IPs, and more); jump to any section.
  • The declarative API turns Radar's existing HTML forms into tools by annotating them with a couple of attributes, so an agent can scan a URL with the URL Scanner, look up a domain's report, or test a website's post-quantum TLS key exchange support.

Every one of these simply drives functionality already available in the user interface, and it's pure progressive enhancement: in a browser without WebMCP, the tools just aren't there and nothing changes.

It’s also a case of practicing what we preach. Radar’s own URL Scanner evaluates how agent-ready a site is, and one of those checks looks for exactly this kind of WebMCP integration. By implementing it ourselves, Radar now passes its own agent-readiness check, and, more importantly, becomes a site that both people and agents can navigate with ease.

Try it out 

Radar Researcher is available in beta today on Cloudflare Radar. Look for the Researcher button in the header on any page. It's built entirely on Cloudflare's developer platform, and it's just getting started: we'll keep expanding the datasets it understands, sharpening its analysis, and adding new ways to interact with data.

Like all Cloudflare products, Radar is built with the user in mind. We want to know what’s useful. Please let us know what you think on social media at @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky), or by email at [email protected]. 

Tell us what works, what doesn’t, the insights you’re finding, what still feels beyond reach, and everything in between. Your feedback will help us improve and make Radar Researcher even better for our full launch. We can’t wait to see what you do with it! 

Give any website a WebMCP interface

Post Syndicated from Will Rowe original https://blog.cloudflare.com/webmcp/

Today we are launching a developer preview of WebMCP on Cloudflare. Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin. Cloudflare adds a small bridge to your pages, which registers a set of tools for a visitor’s agent to use.

The web was built on the assumption that there is a person on the other end: someone to read the page, click buttons, and fill in the forms. But now more and more visits come from AI agents instead, to an Internet made for humans. The usual approach has been crawlers, which copy content back to a server and, too often, give the original site none of the traffic and little of the credit. There is a better way, and it does not involve scraping.

WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as document.modelContext. A site can choose to expose a set of tools for agents running in the browser, meaning agents no longer have to guess their way through a page built for humans. This enables agents to have a different browsing experience from the user and use tokens on tasks, not navigation. The catch: the site has to implement it. 

Cloudflare has been building both ends of this. BrowserRun, our remote browser, already added WebMCP support, so an agent can discover and call the tools a site exposes. Cloudflare Radar will soon offer WebMCP tools of its own. This preview is about the other side: a way to give any site on Cloudflare those tools with a single switch, and no code. 

A developer preview of WebMCP on Cloudflare

Implementing WebMCP by hand is a small project: design the tools to expose, wire them into your interface, and keep them working as the standard evolves. We wanted it to be simpler than that: just toggle a setting to enable tools.

These tools come in packs — groups of related tools that can be turned on together. These are built to grow: as we add packs, a site can opt in to more just by turning them on, no redeploy needed. We are including two tool packs in this developer preview, which both run entirely in the browser.

What this does and how it works

Our implementation comprises two parts, both in front of your origin. Neither touches your site’s code and both work the same way whether your site is static or a single-page app.

First, an injection at the edge. When your site has WebMCP switched on in your Cloudflare Dashboard, we use HTMLRewriter to add one line to each HTML response: a small reference to a bridge script that we also serve. Both the tag and script it loads come from the edge, same origin, so nothing else about the page changes:

The data-packs attribute is the list of packs to activate. If you have an existing Model Context Protocol (MCP) server, the data-mcp-url points at your own MCP server (defaulting to the same origin /mcp).

Second, the bridge. This runs in the page and finds the WebMCP surface. If the browser does not have one, it returns and does nothing, so the page behaves exactly as before.

From there, the bridge composes the packs named in data-packs into one tool list and registers each with .registerTool. A pack is just a set of MCP tool descriptors and their handlers. Static packs, such as Content Credentials, declare their tools up front. A dynamic pack, such as the Site MCP Server pack, discovers its tools at boot before registering anything.

In this preview, every tool runs entirely in the visitor’s browser. There is no round trip to a server of ours. The Content Credentials pack fetches an image and parses its first few kilobytes of content provenance metadata locally. The Site MCP Server pack talks straight to your MCP server endpoint from the page, on the visitor's origin and with their existing session.

The bridge code is served by a worker running at the edge. This leaves us room to grow the offering — future packs will be able to call this worker for tasks the page cannot do alone, like summarizing a sitemap with Workers AI or querying an AI Search index. 

To an agent, all of these are ordinary MCP tools. We use Model Context Protocol’s own Tool and CallToolResult types, so an agent that already talks to MCP servers can drive a page with nothing special added. The browser is just another place MCP runs. The example below shows how the bridge turns one of your own MCP tools into a tool the visitor’s agent can call. 

Checking out content metadata

We are also developing packs to read different types of metadata. For example, credentials for participants of the C2PA program can be retrieved using the Content Credentials pack. scan_images_c2pa sweeps every image and returns a short summary of each:

For a closer look, inspect_image_c2pa decodes one image’s full manifest: its edit history, the stated author, and the signing certificate. It is a plain TypeScript reader that touches only a few kilobytes of the metadata at the front of the image, not the image itself. For now, it reads and reports the credential, rather than cryptographically verifying it: every result carries signatureVerified: false, so an agent won’t mistake a decoded claim for a checked one.

Try it out

Get started with WebMCP by going to Agent Readiness > Labs in the Cloudflare Dashboard. Here you can toggle on WebMCP for a domain, and pick which packs to add: both Content Credentials and Site MCP Server are on by default, and more packs will show up here as we ship them. That's the whole setup. There's nothing to deploy and nothing to change at your origin, and the next HTML your site sends will include the bridge.

To confirm it’s live, ask your site for any HTML page and look for the line Cloudflare injected:

You do not need your own agent to see the tools work. Point BrowserRun, Cloudflare’s remote browser, at your URL, and it will discover and call the tools your packs registered, exactly as a visitor’s agent would. That is the whole loop: BrowserRun gives agents a browser to act on, this preview gives your site the tools to be acted on, and they meet using the open standard. The tools behave in the same way whether the browser is on someone’s laptop or running headless in the cloud. 

Why we built this

Our job is to help make the Internet better, and as the Internet changes we need to provide domain owners with tools that allow new visitors, AI agents, to interact without a full rebuild. It is one step towards a web that can still thrive when visitors are not always human.

This is a developer preview, and we want your feedback. Turn it on, try it against your own site, and tell us how it goes in the Cloudflare Developers Discord or on the Community forum.

The next generation of MCP

Post Syndicated from Matt Carey original https://blog.cloudflare.com/mcp-v2/

Over the last year and a half, the Model Context Protocol (MCP) has become the universal standard for how agents interact with external services. 

But one of the main criticisms of MCP was that the protocol required a stateful connection between Client and Server. This evolved from MCP’s origins and the first STDIO transport, designed for local applications. When MCP Servers went remote, it translated the stateful connection that worked so well locally and transposed it onto web infrastructure. Building a well-behaved MCP Server meant managing request routing to sticky sessions, holding open streams, message replay, and generally more overhead and complexity than a traditional web server. This changes now.

The latest MCP 2026-07-28 specification was released last week, together with updated TypeScript, Python, Go, and C# SDKs. MCP is now a fully stateless protocol. The specification, interaction model and SDKs have all been rewritten to leverage this new protocol and simplify usage. This means that MCP servers can now run in just a Worker, no stateful infrastructure needed, and customers benefit from the operational simplicity and reduced cost of less moving parts. 

A new MCP

At Cloudflare, our journey with MCP goes back to the very beginning. In March 2025, we released our McpAgent primitive for building MCP servers with Cloudflare Agents SDK. Two months later, we ran an MCP Demo Day showcasing customers such as Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow launching their own MCP Servers along with 13 Cloudflare product-specific MCP servers. A year ago, we released MCP Server Portals, to help enterprises securely adopt MCP in their organisations.

Cloudflare Durable Objects were uniquely positioned to be the best place to host these new applications. They are stateful servers that combine compute, persistent transactional storage (via embedded SQLite), and real-time coordination. They scale up on demand, hibernate when not in use, and keep the stateful connection needed by MCP for Agent-to-Human interaction.

McpAgent combined with the Workers OAuth Provider package was the best place to host remote MCP servers. However, it became apparent that MCP could be simpler, more efficient, and easier to host, while keeping all capabilities we have grown to love.

This release of the MCP 2026-07-28 specification has been months of work by the whole MCP team and the SDK maintainers. In this post, we will outline the protocol changes that matter most for developers, share testimonials from customers running it in production, and explain how to start building with the new specification.

MCP is now stateless

Earlier MCP transports began with an initialize and initialized exchange that would start a session. A server could assign an Mcp-Session-Id header, and every subsequent request had to find the state associated with that session. In practice this meant that autoscaling infrastructure had to preserve active sessions, deployments had to drain or migrate them, and losing an active instance could force clients to reconnect or lead to broken sessions. Serverless platforms could run MCP servers, but only by adding coordination for a protocol session that most interactions never even needed.

The new protocol removes the required handshake, the Mcp-Session-Id header, and protocol sessions from the core request path. Each request carries the protocol version, client identity, and client capabilities it needs. A client that wants to inspect a server before making another request can call server/discover, but this is optional.

That simple detail changes how an MCP server can be deployed. A request can arrive at a server, invoke a tool, prompt, or resource, and simply return the result. There is no protocol session to store. This removes a huge part of MCP complexity, while preserving all the functionality that’s expected from it, making MCP servers easier to deploy, scale, and maintain over time.

This new specification thus also removes the need for McpAgent. While Durable Objects remain the right primitive when an application itself needs state, MCP itself no longer requires a Durable Object to speak the protocol. Servers can scale faster on request scoped infrastructure such as Cloudflare Workers. 

Cloudflare's Agents SDK has supported the new specification since day one. Customers and partners have used the release candidate on Cloudflare before the specification was finalized, giving us confidence that the migration path from McpAgent to the new createMcpHandler (see below) works with production traffic.

Elicitation no longer needs an open stream

An MCP server sometimes needs more information before it can finish a request. For example, a deployment tool may need approval before releasing to production. A design tool may need the user to choose colors. A billing tool may need confirmation before issuing a refund. MCP calls this interaction an elicitation.

Previously, server-initiated requests such as elicitation/create depended on an open stream. Deployment of such a server requires balancing the complexity around streams, cost, and request timeouts.

The new protocol reworks this with Multi Round-Trip Requests (MRTR). A server can return an input_required result that describes what it needs. The client collects the answer and retries the operation with that input. The original operation can then complete, without either side preserving a transport session between those requests.

This is a breaking change from the old way of doing elicitations. However, it is operationally much simpler to implement, and we believe that it will allow more developers to make use of this capability to build rich agentic applications. 

HTTP infrastructure understands MCP

MCP requests are JSON-RPC messages sent over HTTP, but information about the request previously lived only inside the JSON body. A gateway had to parse that body to learn whether a request called tools/list, invoked a tool, or read a resource.

The new specification requires Mcp-Method and Mcp-Name headers on Streamable HTTP requests. For example, a tool invocation can look like this:

A gateway, rate limiter, or Web Application Firewall can now make decisions from headers without parsing arbitrary JSON. Operators can apply different rules to different methods or record tool-level metrics using the same HTTP primitives they already use elsewhere.

The specification also adds ttlMs and cacheScope hints to results from tools/list, prompts/list, resources/list, and resources/read. Tool catalogs are deterministically ordered, allowing clients to reuse them while keeping upstream prompt caches stable across reconnects.

Authorization continues to evolve

The new specification also tightens MCP authorization. MCP now prefers pre-registered clients when the server and client already have a relationship, then Client ID Metadata Documents (CIMD) for dynamic registrations, with Dynamic Client Registration (DCR) as a fallback. DCR is deprecated for new implementations and is slated for removal after summer 2027.

The specification also adopts RFC 9207 issuer identification. An authorization server advertises authorization_response_iss_parameter_supported: true and includes iss in successful authorization responses. The client compares it with the issuer discovered before starting the authorization flow. This prevents an authorization response from one issuer from being confused with a response from another.

There are several less visible changes that close gaps in production deployments. MCP clients now send the canonical server URI as the RFC 8707 resource in authorization and token requests. Tokens must be issued for, and accepted only by, that audience.
Workers OAuth Provider implements all these requirements for MCP servers on Workers. Just wrap your handler functions like so:

A lifecycle for a maturing standard

The technical changes are only part of this release. MCP 2026-07-28 also introduces a formal feature lifecycle.

Features are classified as Active, Deprecated, or Removed. A deprecated feature must remain available for at least 12 months before it can be removed. Roots, Sampling, Logging, Dynamic Client Registration, and the legacy HTTP+SSE transport are deprecated in this release, but existing implementations have a defined migration window.

This policy gives teams a minimum amount of time to plan upgrades rather than react to sudden removals. It also gives the core protocol room to stabilize.

New ideas can move faster through the new extensions framework without immediately becoming part of the core protocol. MCP Apps and Enterprise-Managed Authorization are already extensions, while Tasks have been moved over to provide a path for reliable, long-running work. Implementers can adopt those capabilities as and when needed. 

A new MCP with new SDKs

In November 2025, we introduced createMcpHandler to our Agents SDK, built on an experimental stateless mode in the MCP TypeScript SDK. This let MCP servers that only made use of tools, prompts, and resources be deployed to a Cloudflare Worker for lower complexity, cost and easier deployments. 

We are happy to see createMcpHandler graduate into the official MCP TypeScript SDK with this release!

In early 2026, we also worked with MCP maintainers on replatforming the MCP TypeScript SDK from Node.js to Web Standards, helping to improve interoperability with alternative JavaScript runtimes like Bun, Deno, and Cloudflare Workers. We contributed bundling, runtime shims, and split packages in the TypeScript SDK, lowering deployment sizes and benefitting the whole ecosystem.

Customers can migrate to the new specification whilst keeping backward compatibility with older specifications. The /mcp endpoint accepts both the new protocol and stateless requests from 2025 Streamable HTTP clients, so most clients can reconnect without configuration changes.

For example, in February we released our Code Mode MCP Server for the entire Cloudflare API using this unofficial stateless mode and the (catchy) WebStandardsStreamableHTTPServerTransport. Since then, it has scaled up to thousands of requests per second and served billions of tool calls. 

Here is the shape of a minimal server using the official SDK and the Cloudflare Agents SDK:

Servers that truly depend on legacy protocol sessions, server-to-client requests, or standalone streams need a more deliberate migration. They can run a strict stateless route beside the existing sessionful route, move features over, allow active sessions to drain, and then remove the legacy path during the deprecation period. Our MCP SDK v2 migration guide covers that process. For MCP clients the process is even easier: just upgrade your version of agents, and it will just work. 

The createMcpHandler API began in the Agents SDK, and will continue to live there. We will also continue to wrap the upstream handler to provide a Worker-focused interface with functional defaults and richer interaction patterns than the lower level MCP TypeScript SDK.

Next gen MCP is already in production

David Cramer, co-founder and chief product officer at Sentry, is a noted voice on both the promise of MCP and its early opportunities for improvement. In his early real-world experience, the latest MCP spec delivers on that promise while addressing the early criticism.

"We built Sentry's MCP on Cloudflare's SDK. Big fans,” Cramer told us. “We went live with this new one before the 7-28 spec was even finalized, and it didn't break prod. Big fans of that, too. This new spec cleans up a bunch of the nonsense around auth and tools, which is exactly what I wanted. Agents only get useful once the plumbing stops being the whole story."

Linear builds a fast, modern issue tracking and project management tool. They’ve adopted MCP to let agents access Linear data in a simple and secure way.

“MCP is a clear example of why open standards matter,” said Tom Moor, Head of Engineering at Linear. “The latest iteration of the spec is a great improvement that makes hosting an MCP server easier, more reliable, and at the same time adds much needed functionality. I still think MCP is massively underestimated — we built our server once on the standard and it works with whatever AI client our users want to bring. Linear's stance has always been to make your Linear data accessible wherever you need it and the shared spec makes that possible without building hundreds of integrations.”

Anthropic created MCP and donated it to the Agentic AI Foundation. For the team that started the protocol, the new spec is a measure of how far it has come, and of how much the community now carries it forward.

“We donated MCP to the Agentic AI Foundation so it could become open, vendor-neutral infrastructure for the whole ecosystem. MCP is now foundational for agentic software. It’s the layer applications build on to connect with the tools and data people rely on every day and this is the most significant advance to the protocol since launch. Clients gain meaningful performance with minimal engineering work.

Security follows the same proven standards that protect the rest of the internet. Maintainers and contributors from across the community, drawing on real production experience at enterprise scale, made that possible. We can't wait to see what developers build on MCP." said David Soria Parra, Co-creator and Lead Maintainer of MCP, and Member of Technical Staff at Anthropic.

Long live MCP

The new MCP specification is available for both clients and servers on Cloudflare today. You can run a stateless MCP server in a Cloudflare Worker, secured with Workers OAuth Provider and connect to an MCP client in an Agent. Use Cloudflare Durable Objects when your application actually needs coordinated state, and serve new and legacy stateless clients from the same route while users migrate.

Install the latest Agents SDK and the MCP TypeScript server SDK, follow the migration guide, or start with the createMcpHandler documentation. You can also connect to Cloudflare's MCP servers, which already support the new specification.

MCP no longer needs stateful infrastructure to do useful, interactive work. Servers can run as an ordinary HTTP workload on Workers, close to users, with the scale, security, and observability primitives developers use for the rest of the web.

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers

Post Syndicated from Celso Martinho original https://blog.cloudflare.com/kitesurf/

Should we build our own browser? This is one of those questions that has come up every few months internally at Cloudflare for years. Unsurprisingly, it’s the kind that triggers long threads with multiple reasons and persuasive arguments on why we should do it. The browser is obviously the most important software we use every day on our computers; it’s arguably the operating system of the Internet. We’re a company on a mission to help build a better Internet — who wouldn’t want to take on the challenge of building a new browser?

But we never quite found the balance between the technical difficulty of such an endeavour and the unique problems we’d be solving by doing it. And so, the idea was shelved, over and over again. Until now.

Something magical happened: we reached a tipping point where a series of powerful technical advancements in our Developer Platform became a reality, while the advent of AI agents and the demand for a new kind of browser became critical at the same time.

Running WebAssembly (Wasm) in Workers is now very mature. Primitives like dynamic workers, SQLite-based Durable Objects, Worker-to-worker RPC, service bindings, higher NodeJS compatibility and higher limits open doors to much more ambitious and complex applications that were simply not possible before.

Browser Run, our headless browser automation API product, has seen tremendous growth with the rise of AI. Agents need browsers in order to perform many tasks, and in many cases cannot succeed without them.

But there's a problem — browser engines like Chromium were built for humans, not agents, and they come with overhead that AI models simply do not need. They consume so much memory and compute that providing every agent with its own instance is prohibitively expensive, restricting large parts of the Web to only the most sophisticated and costly AI models with higher parametric knowledge, while locking out many other agentic applications. 

We should be giving all agents a browser that excels at what’s important for an AI model, even if that means being light on what’s only useful for humans. For example:

  • AI doesn’t care about tabs, themes, browser extensions, or synchronization across devices. It cares about token count, context windows, scalability, performance, and costs.
  • Structured, machine-readable content is important, but visual perfection, smooth 60-fps scrolling is not. Agents will be just fine if the CSS parsing is slightly off or the rendering isn’t pixel perfect.
  • The threat model in the context of AI using a browser is different. New problems like prompt injection and tool safety are top priorities.

Faced with these realizations, 12 weeks ago we asked the question again: Should we build our own browser? This time the answer was unanimous: Yes!

Today we are announcing Kitesurf, a new browser that runs entirely on top of Workers that we built specifically for agents, available for free while in beta in Browser Run.

Kitesurf is significantly more efficient in CPU and memory consumption than Chromium for common agentic tasks like screenshots and HTML extraction. What follows is the story of how we built it. Buckle up, it’s going to get technical — but we promise to keep it interesting.

How it started

Kitesurf started as many other great ideas have started at Cloudflare. Someone found something interesting, and the next thing you know they end up “nerd sniping” the rest of the team with a seemingly impossible but very attractive idea.

We got the initial inspiration from obscura, a headless engine written in Rust for AI automation that has “no Chrome, no Node.js, no dependencies.”

Then, with the help of an AI agent, we tried to port it to Workers. It didn't work very well at first. But once we gave the AI a solid plan and a clear definition of success — detailed enough for the agent to loop endlessly and ask questions when needed — it did work.
Blown away by this (barely) working proof of concept, we decided to let the team cook.

Design decisions

Here are some of the design decisions we made before we started.

Tests, tests, tests

We knew that moving from a prototype to a full-blown browser that could actually be useful for tasks at scale in production would take a lot of work and iteration. We won’t hide that using AI to accelerate the process was key. But how do you use AI in such a complex project, keeping the quality of both code and results under control without losing velocity? The answer is to provide as many tests as you can.

Enter the Web Platform Tests (WPT), the ideal setup: an extensive suite of success criteria that gave the AI agents clear goalposts for assessing feature conformance. We curated the selection and order of features to assign to the agents, allowing humans to focus on architectural work and reviewing the agents' approaches.

However, WPT tests only go so far: they measure conformance to W3C standards, not a browser's ability to render and interact with real-world websites. To bridge this gap, we implemented a combination of integration testing and visual regression testing — it runs multistep Puppeteer tests on real websites against both Chromium and Kitesurf not only by comparing the assertions that it makes, but also rendering outputs at every step to highlight any unwanted differences.

Use Rust when possible

Cloudflare has been working on providing great support for WebAssembly (Wasm) in Workers for quite some time. This is great because we can use high-performance C, C++, and Rust packages and compile them to Wasm. If we use Emscripten (for example) and its many layers of mocked dependencies, the compiled binary can get bulky and slow.

Instead, we opted for native Rust whenever possible and to compile directly to WebAssembly using wasm-bindgen, thus avoiding unnecessary emulation layers and running as close to the metal as possible, reliably.

Exception handling

A browser must render the whole unreliable and sometimes hostile web without ever dropping the page it's holding, so exception handling is more than just hygiene — it's how the application survives bad input without just crashing outright.

So we committed to one rule up front: any failure degrades to a blank frame or a missing element, never a dead session. Catch faults at every boundary, default to something safe and empty, and log enough to diagnose.

Isolation

Contrary to running a browser on your laptop (where you're visiting sites you trust, and it's acceptable to share some resources between them), an agent is pointed at whatever a task demands: arbitrary code from arbitrary origins.

So we built this browser on the assumption that every page load is untrusted input and every session starts fresh. Each component is isolated and has access only to the resources strictly necessary for its function.

This seems like a perfect fit for Cloudflare Workers, whose security model is built around isolation by design. But the platform only gets us the boundary between isolates. We still have to enforce the same principle at the application level, deciding what each component is allowed to touch and making sure nothing leaks across a page it shouldn't.

Stateless whenever possible

State is what makes failure expensive — if there's nothing to reconstruct, recovering from a crash is just starting a new one and replaying the request. A stateless component is disposable and parallel by nature: kill it the moment it stalls, run a thousand at once, and size them to demand instead of keeping things warm. That fits automation perfectly, where load arrives in bursts and the cheapest thing you can do is spin up work that costs only what it used and vanishes when it's done. In short, wherever a component can be stateless, it should be.

How we built it

Armed with a good plan, extensive tests, and a good tooling environment, we were ready to get started beyond the initial proof of concept. This is Kitesurf’s very high level life of a request that still holds today:

Let’s dive into the three main components that make Kitesurf work: the Engine, PageScript, and PageRenderer.

Fetching from origins

In order to render an untrusted web page, a browser has to fetch arbitrary assets — images, fonts, CSS, JavaScript, and Wasm files — off the Internet. This is one of the most dangerous operations a browser can do.

Kitesurf does it through one single component, the SandboxOutbound worker, and nothing else can touch the network directly — enforced by Dynamic Workers. The Engine uses it to bootstrap the page, fetching the main document and its scripts, and PageScript fetches everything else: stylesheets, images, fonts, and the page's own fetch() calls.

We use SandboxOutbound to enforce CORS, inject browser-shaped headers, filter responses, and keep each page's cookies in their own jar. Anything that fails our policy gets a 403 — each component gets precisely the network it needs and nothing more.

The Engine

The Engine is the only public-facing component of Kitesurf. It handles the Chrome DevTools Protocol (CDP) WebSocket and HTTP REST APIs, serves a landing page that is useful for internal testing purposes and, most importantly, stores each session state. All other components are stateless.

The advantage of using CDP is client compatibility: Puppeteer, Playwright, chrome-remote-interface, and the actual Chrome DevTools frontend. Point them at Kitesurf and they will all just work. This is also how Browser Run works (more on why this is important later).

Contrary to what the name suggests, the Engine is actually the simplest of the Kitesurf components. The fun parts come next.

PageScript

PageScript offers a good example of the power of our new Workers features: in this case, Dynamic Workers.  Kitesurf simply wouldn’t have been possible before this.

Here’s a simplified diagram of how PageScript works internally.

Every next page or out-of-process iframe (OOPIF) uses Dynamic Workers to spin up a long-lived PageScript isolate that handles the page session, consisting of a clean globalThis and the DOM document object. 

The DOM object is then populated with the results of parsing the HTML document and running all the JavaScript scripts. For parsing the HTML and the CSS we use parts of Blitz, a modular rendering engine, and Stylo, Firefox’s high-performance CSS parser, both written in Rust. 

For each found <script> tag or .wasm file we run the JavaScript and WebAssembly code inside the same isolate.

Yes, but evals

What about evals, you ask? Evals are trickier to handle because for security reasons we still don’t support eval natively in Workers. We can’t spin another isolate to handle them either, because it wouldn’t have access to globalThis.

Our solution is to use Boa JS, an ECMAScript engine written in Rust, to compile and run on Workers. We are basically executing a runtime on top of a runtime, which doesn’t seem optimal, and it isn’t, but it works well enough to handle the occasional evals we find in the code. In the future, when native eval support lands in Workers, we will migrate away from Boa.

PageRenderer

This component is essentially responsible for generating the actual pixels from the computed page objects. Here’s how it works:

PageRenderer works in a loop with the Engine Worker. Every time the engine needs a frame, PageRenderer gets the page object from PageScript (also known as the scene), fetches the internal fonts and images from Static Assets, rasterizes everything into an image buffer, and then returns the buffer to the engine in a format that the client can display like a JPEG/PNG or PDF.

A big part of the magic here is handled by another Blitz module, blitz-paint, which in turn uses Parley for shaping the characters into glyphs, choosing fonts, and breaking text into lines.

Workers’ built-in RPC system: same application, multiple isolates 

Cloudflare Workers have a built-in remote procedure call (RPC) system that allows you to call methods on other Workers, pass objects between them, and call methods on those objects. You don’t have to worry about API schemas, types, or authentication, you just call remoteFunction(…params) and it works. You benefit from the isolation and the resources of the remote Worker without losing the convenience of accessing all of their functions locally using JavaScript.

Kitesurf uses this RPC system: the Engine Worker calls renderFrame() from the PageRenderer Worker over RPC using one single call and gets a PNG as the result. Because the renderer holds no page state (only a disposable cache), the engine can safely kill and relaunch it on any failed or stuck RPC call — making each render request self-contained, retryable, and its isolate cheap and throwaway.

Kitesurf passes 215,000+ WPT tests and growing

Kitesurf works. It already passes around 215,000+ WPT tests, and we are adding hundreds of passing tests every week. Here you can see the evolution over time, up to the latest version since we started the project:

It’s worth noting that the parts of a browser that are important to agents (e.g., CSS, DOM, HTML, selection, SVG, and XHR) have good coverage already. Even things that might not be particularly important in the context of agents, like streams, are now decently supported.

Performance-wise, Kitesurf is doing pretty well. Below are the medians of five Browser Run quick-action runs across a 14-URL corpus comparing Chromium with Kitesurf.

Chromium wins the stopwatch because a JIT that has already seen this page always beats a cold software renderer — and today it does, by about 1.7x. Most of that gap comes from rasterization and JPEG/PNG encoding, which we will keep optimizing.

But Kitesurf wins on memory and CPU, the things that actually drive your bill, by 3-7x compared to what Chromium uses. Less memory means we can run more sessions, scale better, and fundamentally lower both our costs and yours. 

The most important test of all: Kitesurf runs Doom

We highlighted the importance of testing in our design decisions, but we all know that no matter how many tests you have, a project isn't truly complete until Doom runs on it. Here’s Kitesurf running https://silentspacemarine.com/ from our little Doom experiment a few years ago.

Try it today in Browser Run

You can try Kitesurf with Browser Run today, available for free while in beta, behind per-account limits.

The Browser Run CDP endpoint now supports Kitesurf as an option, so your existing client Puppeteer, Playwright, chrome-remote-interface, or any AI Agent that speaks MCP and CDP, already works. All you need to do is add the browser=kitesurf parameter to our endpoints.

For example, to use Kitesurf with Opencode see Using with MCP clients (CDP) in our developer documentation and use this configuration:

Another way to use Kitesurf is with Browser Run’s Quick Actions. Again, just add browser=kitesurf to the quick action endpoint and it will work. For example, if you need a quick screenshot from Wikipedia, this will work just fine:

Use the Kitesurf Playground with Chrome DevTools

Another option to start exploring Kitesurf is to use our public playground here. You can type in any URL to see how Kitesurf renders the page and interact with it.

One interesting feature of the playground is that we inject Chrome DevTools in the UI, so you can inspect expanded DOM elements, read console messages, and watch network activity while Kitesurf renders pages. More interestingly, we implemented the necessary CDP instructions for the Memory panel to report the WebAssembly footprint of each isolate, including frames, so you can gain a clear understanding of the resources each page is consuming.

Check our Developer Documentation for all the details on how to use Kitesurf with Browser Run.

When is Kitesurf better?

As of today, Kitesurf correctly renders pages like TodoMVC (vanilla, React, Vue, Angular, Preact), Wikipedia, Hacker News, the Cloudflare Blog, and much of the Cloudflare dashboard. We will keep improving Kitesurf and increasing the percentage of WPT tests that pass, to improve compatibility for more complex web pages.

Kitesurf is great for AI agents that need to render pages but can accept the trade-offs of not using a full-featured, pixel-perfect Chromium browser. It is also excellent for automations and applications that rely on one-shot Quick Actions, such as extracting content from a page or generating PDFs or screenshots, for compatible sites.

Think of Kitesurf as an ephemeral, fully-isolated, stateless engine designed to exist only for the duration of a task, that scales well for bursty, AI-driven workloads.

What Kitesurf is not yet able to do

If you need to play video, render WebGL, negotiate a bot-challenge handshake with real TLS fingerprints, or start a ten-minute authenticated session that requires persistent state — Kitesurf isn’t yet the right option. Just use Browser Run’s default, which is powered by Chromium.

The best way to know if a specific site is compatible with Kitesurf is to try it. You can do this by using the APIs or, more quickly, try it in our public playground.

Explore the DevTools panels and see what’s happening behind the scenes, with particular attention to the console and the memory metrics.

Where it goes

Kitesurf is twelve weeks old. The first commit was in May. Here are some of the things we're actively working on:

  • Better CDP coverage. Kitesurf implements a subset of the CDP protocol — enough to cover the requirements of most agents and automation tools, including robust DOM and network inspection — and we continue to expand its capabilities to be as complete as possible.
  • Rendering fidelity for screenshots and PDFs, because we know that  LLMs can often work better from an image than from the underlying text.
  • WPT coverage. We are iterating rapidly to add more web APIs and pass more WPT tests on the road to making Kitesurf production-ready.
  • Efficiency. We keep CPU, memory, and wall time benchmarks running all the time and are working hand-in-hand with other Developer Platform teams to make Kitesurf as cost-effective and efficient as possible.

Final notes

Thank you for making it all the way here — we know this was a long and technical blog post, but hopefully an interesting one. We went into detail because we don't take lightly how important, but also how complex, it is to build a new browser, even a very specific one.

Kitesurf is in its early stages, but we wanted to open it up to you as soon as possible and learn from your feedback. The team will be actively improving it with frequent updates focused on performance, efficiency, and compatibility. 

One last thing: we're going to open source Kitesurf once we're ready — hopefully soon. Our goal is to let any customer deploy their own version of Kitesurf on their own accounts, if they want to.

So give it a try in the playground, keep an eye on our changelog, and come chat with the team on Discord. Share your experience and send us feedback; we’ll be listening.

Building an open Agentic Internet: readable, discoverable, callable, and payable

Post Syndicated from Jack Galilee original https://blog.cloudflare.com/the-agentic-internet/

Our data shows that a lot of traffic from well-behaved bots is re-fetching pages that have not changed. Billions of requests. An enormous amount of machine effort, attached to no outcome at all. That's the signature of a web built for humans being visited by something else.

Agents are here – not as a new kind of software, but as a new kind of visitor to the web.

The web reshaped around this new visitor is what we call the Agentic Internet. We see its future as readable, discoverable, callable, and payable. To realize that future, it needs its own tools and protocols.

Cloudflare's developer platform gave agents a place to run, and the first tools to build them. What's missing are the ones that let agents and domain owners cooperate instead of collide — on the open Internet, not just inside a single platform.

Every browser has always identified itself to the web with a header called User-Agent. The name only made sense once you realized the browser was acting on your behalf. Now a user agent is truly a user's agent: a program that fetches the web on a person's behalf. Today its most mature form is the coding agent that reads and writes code, pulls the docs it needs, and never sees the pages it reads.

An agent doesn't render your CSS, see your hero image, or click your ads. But it has a paying human on the other end. Every request now costs someone money and carries a purpose. Block it and you block your customer. Treat it like a scraper and you lose them.

Every agent runs because someone — a person or a business — is paying for what it does. Most people don't spend tokens for the sake of it. This version of the Internet, one with an outcome and a bill on the other end of every request, is going to look nothing like the one we have now.

The web was not built for this, and neither were your analytics. Nor, in most cases, was your business model. How agents read, discover, call, and pay is going to decide whether the Internet stays open or gets closed. In one version of the future, a handful of stacks own discovery, identity, and payments, and everyone else routes through them. In another, the Internet stays open: primitives built on standards anyone can implement, running on rails that are neutral because the code is public.

Cloudflare believes in the open Internet, and we're in a position to help build the future where it thrives.

The specifications we build on are open standards that anyone can implement — x402, MCP, Web Bot Auth, PACT. Domain owners choose their own identity providers, their own payment processors, their own agent partners. Cloudflare is one option, not the whole stack. We are Customer Zero of the same rails our customers use, with no privileged path or early-access API that only we can reach. This is the job we've done for the human web for fifteen years, and it's the job we intend to do for the Agentic Internet.

The engineering is not what humans on the Agentic Internet will notice. They're picking up a new medium, and they'll judge it the way they judged the web: on whether it's better. Whether finding and booking a table takes one exchange instead of nine. Whether they know who they're dealing with. Whether paying feels safe.

Our philosophy: A readable, discoverable, callable, and payable Agentic Internet

This starts with identity. Web Bot Auth lets a bot cryptographically identify itself to any site it visits, so publishers can decide who they welcome and who they don't. No more guessing and no more spoofed user agents. Many sites already know the human behind a request from login, in-app behavior, or purchase history. That site can issue Private Access Control Tokens (PACT). Announced with Mozilla, Google, Microsoft, and Shopify, PACT lets sites vouch anonymously, so the agent can present the token elsewhere. Legitimate agents get in with less friction.

We can then make it easier for an agent to do its job. Markdown for Agents lets agents read websites with fewer tokens and less bandwidth. WebMCP gives them a native way to interact on your behalf. Standards like x402 let them pay merchants directly.

Readable is straightforward. Can AI agents read content in a way that is native to them and plays to their strengths? The less bandwidth and fewer tokens an agent burns, the better. Every HTML tag rendered for a human that never looks at it is not only a waste of compute but also a pollution of the context window the agent then has to pay to ignore. Markdown for Agents addresses this from the server side.

On the client side, we approached building a browser with agents in mind as first-class citizens. Kitesurf is our new browser lean enough to run on Workers, spun up per request and thrown away after. It delivers content and features that agents need without any of the bloat from human-oriented features in traditional browsers.

Discoverable is where every economic moment on the Agentic Internet begins. Before an agent can read a resource, call a tool, or pay for a transaction, it has to know the resource is there. Search is one half of the story, as agents need to find what they need through interfaces built for them, not through a keyword box designed for a human who types slowly and skims. AI Search is available today, so any public site can be made searchable by agents.

Being discovered is the other part. Content creators and API owners need to know how visible they are to agents. Agent Engine Optimization (AEO) measures brand visibility across the models and agents that matter. If you are not measurably visible to the agents your customers use, then you are effectively offline for them. 

Callable is where the agents start doing things: booking a table, renewing a subscription, pulling a report. On the human web these all look different, because they were built for humans clicking through user interfaces. An agent trying to add an item to a to-do list has to parse the HTML, guess which button is “Add”, synthesize a click, and hope the DOM didn’t change since it last looked.

WebMCP lets a site expose its actions directly to agents through the browser:

The tool “contract” becomes explicit. No HTML parsing, no guessing at form fields. As the tools run inside the page, they reuse the user’s existing session and state. Code Mode goes one step further. Agents think in code, and calling tools by writing code is faster and more accurate than prose. As agents are calling endpoints rather than scraping webpages, there is a clear signal back to the content owner of what content is actually being used. 

Payable is where we believe the Agentic Internet is going. Every economic transaction eventually needs a way to pay. Ad-based models are breaking. Seat-based models do not work when the user is a program. The publishers we all rely on cannot fund themselves on pageviews that never happen and browsers that do not render their ads. 

A recipe site that never turned a profit using ads can charge a fraction of a cent per fetch and be profitable at the scale of the Agentic Internet. A local paper can license articles at read time without a licensing deal or login. On the other side, the agent shows up with a wallet and a budget the human set once. 

Every paid interaction leaves a receipt. The publisher can prove which agent fetched which page. The agent can prove it paid for what it used. Wallets allow agents to easily pay for content and APIs. Monetization Gateway lets domain owners set up payments from agents in a few clicks.

Cloudflare sits in the middle of all of this by design. We already sit between billions of humans and the sites they visit, protecting them, speeding them up, keeping them online. Agents change the traffic but not the shape of that job — we're the neutral, high-performance layer that publishers, merchants, agent builders, and end users can all trust to be on their side, not competing with them. 

We want to give domain owners the tools to empower the kinds of AI agents that they want to support and block the ones that they don’t. A developer tool likely wants to become agent-ready to encourage AI agents to discover, recommend, and pay them. A publisher may want to block extractive AI agents (which consume resources without giving anything back) but allow AI agents that license their content or compensate them. A nonprofit data provider may want to block bots or humans who exceed their rate limits, but allow them to pay to get unblocked and use those funds to cover the excess resource consumption.

Bots are dead, long live bots

The distinction between a bot and a human isn’t so simple anymore. It’s not as straightforward as bots are bad and humans are good, or bots wasting resources that humans should instead consume. This is the old way of thinking that is outdated in the world of agents.

We see agents as a new type of actor. Their actions can be desirable, say, by reading content in a way that preserves resources, interacting with websites in the way that the domain owners specify, and paying for what they use. Or their actions can be undesirable, for example, by scraping millions of pages without compensation, attempting to circumvent blocks, or ignoring robots.txt. We believe that many of the undesirable actions will diminish, and even convert to desirable actions, if humans and bots are given the right tools.

Closing the revenue gap

Cloudflare has spent years detecting bots, allowing domain owners to take control of whether bots can access them. What's been missing is the other half: how agents interact with those sites once they're let in. That's what this suite of agentic tools is for: making the web readable, discoverable, callable, payable. These four primitives are all built on open standards, so no single company owns the rails. 

An open Agentic Internet needs diversity on both sides. Not just diverse publishers and content creators but also diverse agents. If the demand side converges, it doesn’t matter how open the supply side is. The Internet will still be a walled garden.

We are building this open alternative. Join us by getting your site agent ready with our new dashboard, and sign up to receive news on our Answer Engine Optimization product. If you run a site or an agent, you can experiment with all of the Internet's new technologies using our AI Playground.

Cloudflare AI Search: give your agents a search engine for your data

Post Syndicated from Nelson Duarte original https://blog.cloudflare.com/ai-search-easier/

Today, we’re excited to announce a few developer experience improvements to Cloudflare AI Search to make it easy to manage a search solution out of the box. Previously, you had to stitch together components of the Cloudflare primitives (Workers AI, AI Gateway, Vectorize, R2, Browser Run) but now, AI Search can do this automatically — and better. Our goal is to give your agents their own search engine, where they can easily find data to provide better answers for themselves and their humans. 

We’re also sharing an early preview of pricing for customers of AI Search so you can learn how this scales. We modeled pricing in a way that makes it predictable and scalable: embedding and reranking are free when you use the default models, so no need to worry about predicting token count.

In AI Search, users can now:

  • Index a collection of data for your agent: Make structured and unstructured data easily accessible for your agent to build with, from individual files to websites you own. (Today, it must be a zone on your Cloudflare account, but with more ways to verify ownership coming soon.)
  • Skip the sitemap for your websites: Previously, AI Search required that websites have a sitemap to use the website integration. Now you can select the “Discover” parsing option to add a website without a sitemap as a source.
  • Get a single public endpoint for searching across a namespace: When you enable public URLs on your namespace, you can get a /search and /mcp endpoint that can search through multiple instances or websites at once without authentication, so you can share easily with your customers.
  • Put your own custom domain over public endpoints: You can now add your own domains over your public URLs, so you can brand your /search and /mcp endpoints (e.g., search.example.com/mcp). You can also add Cloudflare Access to create private search instances.
  • Add semantic search to your sites built on EmDash with AI Search plugin: If your site runs on EmDash, our open-source CMS, the AI Search plugin adds semantic search over your content.
  • Preview the new pricing model for AI Search: We want pricing to be predictable and to scale with you, so we built in the cost of embedding and reranking: they’re free when you use select models from the Workers AI catalog.

Finally, we will also share examples of how AI Search is used across our own platform including Cloudflare.com, our Developer Docs, with EmDash, in Cloudflare Dev Stack MCP — and even the blog post you’re reading right now (try cmd+K).

AI Search in action: powering the new Cloudflare Dev Stack MCP

One of the ways we use AI Search is in our new Cloudflare Dev Stack MCP, which you can try today in our AI Playground. It gives coding agents current, cited docs from across the Cloudflare developer ecosystem, so they build on the latest features and fixes instead of stale training data.

Here's how we built it using the features available today in AI Search:

1. Index each surface

We created one AI Search instance per Cloudflare-owned surface: Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext. (Each of these is Cloudflare-owned.) 

They span different domains, but, because Cloudflare owns the website data, AI Search is able to treat them as a single set and ingest them all the same way. Point AI Search at a site, or set of sites, and it handles crawling, ingestion, embedding, and retrieval. Creating an instance is a single command, and for a site without a sitemap you add –parse-type discover to find pages by following links (powered by /crawl from Browser Run):

2. Combine the instances into one search

Now the interesting part: answering a single query across all 10 instances. There are two ways to do it.

Option A: in a Worker (what we did for Cloudflare Stack MCP)

We bound the namespace to a Worker to create a remote MCP server and made one multi-instance call across all 10 instances. We took this path because we're adding the stack search into Cloudflare's MCP server, so it ships as a tool alongside the Cloudflare tools agents already connect to.

The binding, in wrangler.jsonc:

Then a single tool makes one call that fans out across the instances you name:

Option B: flip on public endpoints (no code)

If you'd rather not write a Worker at all, enable public URLs on the namespace. You immediately get /search and /mcp endpoints that query every instance, with no auth and nothing to deploy.

Reach for the Worker when you're folding search into an existing app or MCP server, as we are. Or reach for the public endpoint when you just want a shareable search endpoint in one click.

3. Brand it and lock it down

Public endpoints come with a default public URL, but you can put your own custom domain over them to brand the endpoint (e.g., search.example.com/mcp).

If the search should be private, add Cloudflare Access in front of the domain. The endpoint now requires a login, so only authorized people (or agents) can query it.

Try it yourself: use the Dev Stack MCP

With the Cloudflare Dev Stack MCP Server, you can ask about any tool, or describe an app you want to build, and you'll get back current, cited answers on how best to build it on the Cloudflare stack.

The AI Playground is worth checking out, but the real magic is wiring the MCP into your coding agent, so the stack's current docs are one tool call away. That replaces the usual fallback (web search then fetching full pages), which is slow, token-heavy, and often lands on the wrong or stale source. To use with your agent of choice, drop the Dev Stack MCP URL into your MCP configuration. For example:

Powering search on our Blog, Developer Docs, and Cloudflare.com

We build with AI Search the same way our customers would: Cloudflare Blog's search already runs on it, and today Developer Docs and Cloudflare.com join it. All of it uses hybrid search, semantic and keyword together in one query, so it handles both open-ended "what does this do" questions and exact lookups of names or keywords. We recently rebuilt the Blog on EmDash, our new open-source CMS, and our new

EmDash AI Search integration is what powers that search now. You can also add it to your own EmDash site and get the same search over your content out of the box.

AI Search respects all bot policies

AI Search is powered by Browser Run /crawl in the background, but goes a step further to identify itself with its own bot identity: Cloudflare-AI-Search. Just like Browser Run, it follows robots.txt, identifies itself with an immutable, public user agent, and will respect whatever bot controls a site has in place. 

Preview pricing: pricing you can predict

AI Search is currently free while in beta, and billing is not yet enabled; we'll email you with plenty of notice before it starts. As we move toward general availability, here's a preview of pricing across ingestion, storage, and queries, plus embedding and reranking (preview prices are subject to change before billing begins):

† A single pool of 5M ingestion tokens per month, covering any file type currently supported (e.g., text, images). ‡ A single pool of 2,000 queries per month, shared across both query types. 

Our goal is to provide pricing you can predict, starting with the models your search leans on. Embedding turns your text into the vectors that search matches on, and reranking reorders results so the most relevant come first. Both run free with AI Search defaults or when using select models from the Workers AI catalog, so the models behind indexing and every search are not a cost you have to worry about. Answer generation and query rewriting are optional steps that run on a model you choose, billed as Workers AI usage, or you can use AI Gateway credits with any model/provider.

Example bill with preview pricing

Here's a sample monthly bill on the Workers Paid plan for creating a new AI Search instance for a 20,000-document data source (about 20M tokens of text) plus 1,000 images (assume about 1,000 tokens each), with 30,000 semantic queries a month using the default AI Search embedding and reranking model. Ingestion is chunked with roughly 10% overlap, which shows up as the × 1.1 below:

Images count toward base ingestion and also incur the image add-on cost. Storage assumes about 10 KB per document and 1 MB per image. Indexing is largely a one-time cost, so later months are mostly queries, closer to $21.

Get started today

AI Search is available to enable and use today. Point it at your site, turn on hybrid search for both semantic and keyword matching, and you have a search engine for your own data, ready for your agents. Spin one up with one command:

From there, query it, wire it into an agent over /mcp, or put a custom domain on a public /search endpoint to share it with your users. Check out the AI Search docs for more information.

How we’re rethinking work at Cloudflare with Cloudflare OS

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os/

Sam Rhea is Cloudflare’s Chief Information Officer.

I knew we had a problem about six months ago when a member of our sales organization reached out to me asking for API keys. Keys plural. They used AI to build what they described as a SuperApp that would transform our go-to-market teams. All they needed was production access to about a dozen systems of record at Cloudflare and admin permissions to a deployment pipeline to make it work.

We had taken a fairly cautious approach to rolling out AI at Cloudflare during 2025. We deployed informational chat applications and tinkered with using AI to help write some boilerplate code, but we felt that the technology was not ready to change how we work.

And then, over the course of a few days at the end of last year, better models and more powerful harnesses changed that calculus. AI agents could do things, and they could do them well. Hundreds of team members across Cloudflare, in technical and non-technical roles, spent the quieter weeks around the New Year experimenting with new tools that made it easier than ever to build.

That sales team member building their SuperApp was just the first in an avalanche of people raising their hands to use these tools to transform how they get things done. We had an obligation to equip and enable them to do so. But we also had an obligation to keep our systems, internal data, and customer data safe.

We have spent the last several months building a platform to do exactly that inside of Cloudflare. We call it Cloudflare OS. We started by stitching together off-the-shelf components from our Developer and Zero Trust platforms like Cloudflare Workers and Access. As we learned more about the challenge, we also created custom services tailored to this new way of working.

As with many of Cloudflare’s products, we set out to solve a problem we had internally. As it turns out, many of you had the same problem. That’s why today we are excited to share Cloudflare OS, the sum of what we have launched internally to give our own team members the ability to safely and productively use AI and deploy agents. You can read more about what is available right now in Phillip’s post here.

In this post, I want to walk through our own internal journey that led to this release, both what has gone well and where we have fumbled. There are five sections: the principles we put in place to begin; how we piloted to figure out what the jobs were to be done; what we built for engineers, and for non-engineers; and how we created champions across the organization to help drive change.

During the last few months, I have felt like the luckiest CIO in the world as the team I support had access to these emerging technologies. Today’s goal is to share that platform and its lessons with every team.

Set the ground rules

We started by defining a set of principles around how this should work. Cloudflare’s CTO and I sat down in our office in Austin, Texas, and began to sketch out what needed to be true in how we adopted AI. We invited leaders from across the organization to give us feedback on the draft. The result became the guidelines below.

1) We use AI to spend more time with our customers and build technology to solve more of their problems.

We do not want to use AI just for the sake of using AI. We push teams to start by defining their “jobs to be done” first, the pain points, bottlenecks, or missed opportunities that can improve how we serve our customers. Then we find the right tool.

2) Everyone deserves superpowers.

AI is very, very good at writing code. By extension, the first wave of AI tools that could take actions consisted of interfaces that developers already used: command lines, code editors, terminals, Git repositories.

These formats could leave behind large parts of our team. While we have a very technical and curious workforce, not every member of our team spends their day in developer tools. And we do not think they need to! We want our employees to bring their subject matter expertise and we would provide them with an intuitive platform they could use to rethink how we do work.

3) The human owns the output.

We view AI as a tool and toolmaker, not a team member. We expect humans to take responsibility for defining the quality, testing, and workflows that rely on AI output.

The rule extends to deploying agents, as well. The users and teams that ship agents are responsible for the output of those agents. Someone leaves? Their manager inherits the responsibility of their agents in the same way they inherit their other workflows.

4) The context from the organization matters more than the model.

The workflows and agents that we deploy at Cloudflare need to know about Cloudflare. The time we spent on the technology had to be paired with time invested in a curated, canonical context layer.

5) You should never have more permission with systems of record when using AI.

Everyone at Cloudflare has a scoped view into the underlying data at Cloudflare for good reason. We use our own products to segment data access by factors ranging from device to role to region. We also configure and monitor the controls inside our third party applications.

Those controls need to apply when I manage an AI agent that interacts with the same data. I should never have “more” access to data when using an AI tool and my AI agents should only have access to exactly what they need, nothing more. And if I deploy an agent and share it with someone, the access the agent provides to them should reflect their permissions, not mine.

Meet your users where they are

With those rules in place, we got to work. We ran two parallel programs: the first for our engineering teams, and the second for every other type of work.

Provide your engineers with guardrails

AI tools took the work our engineers already did and made it faster — faster than our review process could keep up with. Anyone at Cloudflare could now write bad code, faster, thanks to AI. We needed better guardrails.

So we built a context layer for engineering. We call it the Cloudflare Engineering Codex. A Codex is an authoritative guide. Ours sets out the principles and practices we work by. Policies tell you what you can't do, whereas a Codex tells you what you should do. It is opinionated by design. Every part of our codebase has a domain owner accountable for what good looks like there.

We surfaced that context layer across the software development lifecycle. Agents use the Codex to help engineers plan work. One agent reviews every Merge Request against Codex requirements. Another reviews technical designs before implementation starts. A third reviews incident reports. In the past four months, those agents have flagged nearly a quarter of a million potential problems and blocked 16,000 merges. They have caught architectural issues in close to 600 designs before a line of code was written.

You can read in much greater detail about how we built this code review workflow in Timo's blog post on AI Code Review. We are now shifting focus to giving engineers the tools to define the loops that evaluate the work their agents produce.

Offer everyone a magic email alias

An early mistake we made was giving everyone outside of engineering the same tools with slightly friendlier user interfaces. Engineers could clone a code repository to their laptop, add a context file like AGENTS.md, and point their harness at the work. However, the harnesses in the market map poorly to other types of knowledge work where users create one-off outputs and work on projects that involve dozens of systems of record.

If you give everyone a harness workspace that is great at writing code, you’ll wind up with way more code than you need. The result became a flood of vibe coded apps looking for a problem to solve. So we worked backwards.

We told everyone at Cloudflare that they could send the work they did not want to do to a “magic AI email bot” that would respond with the output they needed. Behind the scenes, a small team of people staffed this email alias using AI tools to do the work.

For some reason, people are less willing to send their vibe coding ideas to what they think is an automated system, but very willing to send the work they do not want to do. Over the course of hundreds and then thousands of sessions managing the email alias, we identified the mundane work that team members would like to automate.

We triaged these manually and over time we observed patterns. We created the skill and context files, mapped out the data connections, and defined the kinds of outputs users needed. With those in hand, we could automate some of the responses to this email alias.

We were very motivated to stop staffing this service. It was miserable. The long-term goal was to take these materials we had collated and create skills to address them, so that our users could solve their own problems. The manual work behind this email alias continued until we felt we had captured enough of the common “jobs to be done” at Cloudflare to give our teams a headstart on automation. Now we just needed to give them a platform where they could easily and safely run those workflows.

Give team members a platform to solve problems

The first version of that platform, which we call Cloudflare OS, consisted of a simple harness running in a container on Cloudflare’s infrastructure. Users access it in a web browser and, once authenticated through Cloudflare Zero Trust, they can run the skill files and workflows we started collecting during the magic email phase.

All of this happens inside of their browser, no local configuration required. Users could open their laptop and immediately be productive. We heard from new members of our sales team who, within days of starting, felt like they could automate work that would have taken them weeks to complete in their last workplace.

Users could also close their computer and get a coffee or use the bathroom while work happened. No more walking around the office with a laptop cracked open.

We think that cloud-based workspaces benefit more than just the user. An ephemeral cloud-based environment only has access to the data a user introduces into the session, rather than potentially everything on the laptop in front of you when you use a local harness. Our Security team has audit visibility and network control over the environment, including the ability to filter where on the Internet it can connect.

When a user needs to get work done, they begin by running skill files defined by common workflows we identified across departments. The company’s accumulated context and skills we gathered during the magic email phase become executable with a single click.

A panel on the right-hand side would render the output of a given skill file, like a technical architecture document or a slide deck. Users could share the outputs with teammates.

We gave Cloudflare OS access to data by connecting systems of record through our Model Context Protocol (MCP) Portal. The MCP standard is a framework that defines how to connect your AI tools to systems of record in a way that tells the AI tool what data and operations are available. Following our rule around permissions, the access a user session has in Cloudflare OS is scoped to their existing permission set in a given system of record.

In most cases, we build and deploy our own implementation of an MCP server for each system of record, even when the system of record provides a native version. By building our own, we can add additional layers of controls like rate limits by role or region. Cloudflare Workers gives us a simple place to build them and, as a serverless platform, the ongoing maintenance burden is practically zero.

When Cloudflare OS uses AI inference, we route that through our AI Gateway. That allows us to filter, log, and audit all interactions between users and those AI systems. For example, we can reuse the Data Loss Prevention (DLP) rules from our Secure Web Gateway to block certain datasets from ever being sent to a provider.

AI Gateway also gives us the ability to control model usage. Not every user needs access to the max thinking mode of the latest frontier lab model. And we do not need team members spending $20 to summarize their email inbox every hour. We can use AI Gateway to gate models by role or steer use cases, especially more autonomous ones like scheduled skill file runs, to more efficient models.

Now make it more deterministic with agents for everyone

Cloudflare OS gave our team an AI workspace where users could run skill files and their own workflows. However, each skill file a user ran kicked off a token-hungry inference session. Much of the work we do is mostly deterministic; a sequence of steps with some inference (or human judgment) in the right places. We don’t need AI to always be a tool as much as we need AI to be a toolmaker.

We set out to address that in an update to Cloudflare OS, which is the version we are sharing with you today. This version lets users describe a workflow in natural language, have an AI agent create the code to power that workflow, and then run agents on demand, on a schedule, or triggered from an event. Rather than trying to build one-size-fits-all agents that we share with the organization, we give every team member the ability to create secure applications, isolated by default.

For example, one of the teams I work with is our IT help desk. We support the team members at Cloudflare with the hardware and software they need to do their work, from provisioning to debugging to offboarding. We manage that work through a classic ticket queue.

Each morning, I want to review our open ticket queues and metrics around our ability to serve these internal customers. Before Cloudflare OS, I would do this manually. Our ticketing system has built-in dashboards, but they are pretty basic. I would download CSVs and import them to Google Sheets where I would create charts. I would then manually click into each ticket that had come in overnight. That was both time-intensive and created redundant data outside our system of record.

In Cloudflare OS v1, I ran this as a skill file connected to the MCP server for our ticketing software. While safer (and less manual), this meant I was burning thousands of tokens each morning recreating a report that was mostly the same. I was also lighting tokens on fire triaging and drafting responses to the overnight tickets.

Cloudflare OS v2 handles that for me and anyone else with similar kinds of problems to solve. I described the charts I want to view, and it uses an AI agent to write the code that powers them alongside a secure connection to the dataset that uses a service we call a gatekeeper. That gatekeeper handles the consistent queries my agent makes to the dataset, scoping down the context for the app without any API key management.

When I do need AI inference, I can embed it into the application. I built options to draft responses with AI to tickets that arrive. I can review the responses and send them. All within a secured workspace that did not require me to create and manage any integrations or deployment pipelines.

When I share the agent I built with others, they authenticate the agent using their own permissions through the same gatekeepers, so we do not cross data boundaries. And I burn exactly zero tokens each time I load the initial report.

Send out champions and share your wins

Cloudflare OS provided us with the platform we needed, but we still needed to enable our team. To do that, we did not hire a dedicated AI team. Instead, we found early adopters in various roles and made them into champions who could help their peers use this new platform. We tapped a sales leader in London, a solutions engineer in Texas, and an investor relations leader in Portugal, a business development team member in Japan, a Sales Ops leader in the US among others, and asked them to partner with their teams to rethink their work.

We also had success embedding interns into established teams. We announced our goal of bringing on 1,111 interns this year, and many of those who have joined us are working within departments with the simple goal of “make this team into all-stars by equipping them with our AI tools.”

The results continue to amaze us. Thousands of Cloudflare team members use the platform every week and the active users per day have grown every single workday. In the last month alone, we estimate that our sales team members have saved more than 10,000 hours of time spent on previously manual tasks like territory planning and proposal creation. In those 30 days, users have created over 4,000 apps and tools to solve specific challenges.

What’s next?

We are not close to done, but every day I see a little more progress as we obsess over how to rethink the work we need to do to solve problems. Someone sent me the link to a report in Cloudflare OS last night that helps us diagnose a procurement bottleneck that would have previously required days of manual spreadsheet crawling. This morning, a member of the IT team shared a workflow agent to track laptop replacements built on the platform with someone on the finance team sitting near them in the Lisbon office. Small acts of automation and knowledge sharing that add up.

Just like we are committed to giving everyone at Cloudflare superpowers, we think every team outside of Cloudflare should have them too. We are excited to share Cloudflare OS with you today, and we expect it to continue to evolve, quickly, as we learn more together. If anyone wants to sit down and trade notes on what is working and not working with internal AI rollouts, just let us know. I’d love to chat, human to human.

Catching rogue AI behavior with identity-aware analytics

Post Syndicated from Ming Lu original https://blog.cloudflare.com/identity-aware-ai-gateway/

When you look at your AI bill, it can be hard to tell if anything is amiss. You first need a baseline so you can see what has changed, whether it’s an agent that’s gone wild or an employee whose usage has spiked 10x. Being able to spot those shifts lets you start investigating, and so far, it’s been hard to see them.

Knowing who is doing what with AI is one of the key challenges organizations are confronting right now. One report from Stanford University found that 59% of organizations said knowledge gaps were their biggest obstacle to responsible AI governance. 

This is a security problem as much as a financial one. Solving these issues takes two things: a verified identity on every request (so a spike has a name behind it), and a picture of what normal looks like for that identity. Today we're announcing both.

Identity-aware AI Gateway with Cloudflare Access is now in open beta, and User Insights is generally available to every AI Gateway customer at no additional cost. Together they turn the traffic already flowing through AI Gateway into a behavioral baseline for every person and agent using it, and identify the ones that break from it.

What is AI Gateway?

AI Gateway is the central control plane for all of your AI usage. Instead of every app and team calling models on OpenAI, Anthropic, Google, or Workers AI directly, requests route through AI Gateway first, giving you one place to observe, secure, and govern all your AI usage.

It works with the applications you build, and with the coding tools your developers already live in. Route agent harnesses like Claude Code, Codex, and GitHub Copilot through AI Gateway, and they fall under the same visibility and controls as everything else.

Identity-aware AI Gateway

With the AI Gateway and Cloudflare Access integration, you can put a custom domain in front of your gateway and protect it with Access, just like any other application. That means you can:

  • Authenticate with any SAML-supported identity provider, like Okta or Entra, removing the need to generate and pass around Cloudflare API keys.
  • Set policies on exactly who can access your gateway.
  • Send requests to a clean hostname like ai.example.com, with no account ID or gateway ID in the URL.

Every authenticated request now carries the user's identity from Access. AI Gateway adds the verified Access user ID to request metadata as cf.user_id, so you can filter logs, analytics, and spend by the person who actually made the request.

Coupled with spend limits, that identity becomes a budgeting tool. Because each request now carries a real user, you can set per-user spend limits: give every user their own budget bucket, then block further requests or fall back to a cheaper model when they hit it. No more surprise invoices, and no shared API key hiding who spent what.

One of our early adopters, Flexport, ran into exactly this problem.

"Shared API keys make it almost impossible to tell who is using an AI service or apply the access rules we already have for employees,” says Max Baumgarten, Staff Security Engineer at Flexport. “Putting Cloudflare Access in front of AI Gateway gives each request an authenticated identity and lets us use our existing identity policies at the gateway. Our teams can adopt AI tools without creating a separate authentication system for every client."

In the near future, you'll be able to use your users' identity provider groups to set spend limits or control which models a group can access. For example, give your machine learning team access to frontier models, cap the spend of your support team, or scope a budget to everyone working on a specific project, all mapped to the groups you already manage in your identity provider.

The new User Insights tab

Within AI Gateway, you will now see a tab called User Insights. User Insights reads the traffic passing through your gateway and turns it into a behavioral picture of every account. It learns how each account normally acts, identifies the ones that break from that pattern, and gives you the context to tell a rogue agent from a busy engineer. It works on the traffic already going through your gateway, so there's nothing to set up.

User Insights tracks cost, including where it's being wasted, such as low cache-hit rates and oversized context windows. Plenty of tools already do that. What they don't do is tell you whether an account is behaving normally. That's what we chose to focus on, alongside cost controls. 

Baselining every account: people and agents

Every account leaves a behavioral fingerprint over time, whether it's a person or agent. An agent summarizing tickets every three hours is tight and consistent. A person is messier, with varied prompts, irregular timing, and long sessions on hard problems. Both are legitimate, so the same deviation can be noise for one and a real signal for the other.

In User Insights, we start by scoring sessions, not single requests. Absolute thresholds fail here: a $500 jump from a heavy user might be normal, while a $50 session from an agent that always spends $5 is a 10x change that could otherwise slip by. So we compare each session against the account's own history, using its 95th percentile (p95) session cost over the last 30 days. That gives us a read on how the account normally operates, and anything above 2x of its p95 is a strong candidate for anomalous behavior.

The following analysis outlines how we arrived at these numbers.

Figure 1: Session Cost Anomaly Detection

How to read the chart above 

The chart plots real sessions from our own internal traffic. Each point represents an individual session (plotted on log scales):

  • X-axis (Session Cost): Total cost in dollars.
  • Y-axis (x User p95): How many times the session exceeded the user's personal baseline.

The two dashed threshold lines divide the sessions into four categories:

  • Top-Right (★ Stars): Exceeds both the 2x user p95 baseline and the account-level p99 ceiling. These are high relative spikes that represent meaningful abnormal spend and will trigger an alert. 
  • Top-Left: High relative spike (2x user p95), but below the account p99 floor. We ignore this to avoid alerting on small-dollar shifts.
  • Bottom-Right: High absolute spend, but consistent with this user's typical high usage. This is also ignored as routine behavior.
  • Bottom-Left: Normal activity well within both baselines.

Figure 2: Account-level Session Cost Distribution

This histogram (Figure 2) maps every session cost across the organization to establish an account-wide ceiling:

  • Typical Usage: The vast majority of sessions cost well under $10, with the 95th percentile sitting at $20.
  • Account p99 ($200): Only 1% of all sessions across the entire company reach or exceed $200.

So why did we pick p99? Setting our absolute dollar ceiling at the account p99 creates a meaningful bar. It guarantees that an anomaly isn't just a sudden shift for one specific user, but also ranks among the most expensive 1% of sessions across the entire organization.

Figure 3: Single User Session History

Baselines aren't static. As an account's habits change, its rolling p95 (green line) and 2x threshold (orange line) move with it, so an alert always reflects recent behavior rather than a number set once. We also apply a dollar floor so that a spike has to be both statistically unusual and worth an admin’s time to investigate. That dollar floor is what keeps a micro-user's 500x blip over a few cents from ever firing an alert.

The right lens for detecting rogue behavior 

After all the analysis above, what admins see is a view of the accounts that broke their own pattern with everything normal filtered out. That filtered view is a rogue behavior feed.

This behavior is hard to catch because the signal is never a new tool or a blocked action. It's a trusted account doing more of what it's already allowed to do. It might be a service account that suddenly starts running more expensive sessions, or a person whose usage jumps well past their own norm and stays there for days.

None of these trip a policy, but all of them break a behavioral baseline. A sudden departure from an account's own usage is often the first observable sign of a compromised credential or an agent going off the rails.

User Insights does not decide intent, and it does not block anyone; instead, it puts the handful of accounts that started behaving strangely in front of an admin so someone can ask the next question. Sometimes that leads to a real investigation. Sometimes it just means that someone needs coaching (like the developer who dumps a whole codebase into every prompt when a snippet would do). 

What's next 

We’ll help you move from cost control to cost optimization

Once you’ve set a budget, the natural next question is: how can you get the equivalent output quality at lower cost? Not every request needs a frontier model. A summarization task or a simple code completion can run on a cheaper model without meaningful quality loss.

We're building task-based smart routing, where AI Gateway analyzes the incoming request and routes it to the model that gives you the best result at the lowest cost. At the organizational level, you’ll be able to see where you can capture the most savings by routing to more efficient models.Task-based smart routing is in active development. We'll share more as it matures.

We’ll help you understand how AI is being used

Anomaly detection tells you an account broke its pattern, but not why. An admin still has to dig into the logs and piece together what happened. Closing that gap is what we're focused on next, and it starts with classifying what the traffic actually is.

We're building prompt classification that sorts requests into categories like coding, writing, and others. These categories are  the context missing from almost every other signal. A spend spike in “coding” from an engineer might be acceptable, but the same spike in a category that account has never touched is not. Classification can show an organization not just how much AI it uses, but what it uses AI for. 

It also answers the question underneath most of these conversations: is AI being used for the work it was intended? Once business traffic is separated from everything else, personal use becomes visible. From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk. 

Once your AI traffic is running through AI Gateway, each new category of risk or efficiency signal is one more thing an admin gets with no extra setup.

Get started

User Insights is generally available today to every AI Gateway customer at no additional cost. It's already in the dashboard for anyone sending traffic through the gateway, so if you're already routing through AI Gateway, this view is available to you. 

If you haven't already, create a gateway and start making requests to any model in our catalog. 

We recommend that you put AI Gateway behind Cloudflare Access which is now in open beta. The spend and anomaly views work without it, but attaching an identity is what turns an anonymous account ID into a name you can actually act on. Start in monitoring mode to learn your baselines before you enforce anything.

We want to hear how you're managing AI today. Join the conversation on Discord or reach out to your account team.

WriteGuard: fine-grained controls for MCP Servers

Post Syndicated from Scott Roe-Meschke original https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/

Let’s imagine the Case of the Endlessly Closing Tickets. 

The bug tickets start closing at noon. Nobody thinks much of it. Joe moved a few tickets to Done, and Joe is having a productive afternoon. Then the pace picks up. By 4 p.m., thousands of tickets have been closed, all by Joe.

Joe is a good engineer. Joe is not a thousand-tickets-an-hour engineer.

We learn that he has several background agents running across three concurrent sessions. It takes half an hour to find the one at fault: a cleanup task with a prompt that was a little too broad.

Once we’ve stopped the agent, we need to repair the state of the ticketing system. Joe has also been legitimately closing tickets by hand that afternoon. The system records all those changes under Joe regardless of whether it was him or his agent, and the network logs do not distinguish one agent session from another. From the outside, the actions look identical.

The example above is relatively low-stakes, but we can all imagine, or read about, much more destructive cases. An agent with access to contract software could amend an agreement. An agent wreaking havoc in a support queue could send hundreds of replies to customers. An agent with database access could drop entire tables.

At Cloudflare, we knew we could not depend on every employee to configure every agent perfectly or watch every tool call. So before expanding write access across our own internal MCP servers, we built WriteGuard. We are now bringing those controls to Cloudflare MCP server portals through a private beta.

MCP Fundamentals

Before explaining WriteGuard, let’s review what an MCP server is and how it works with AI agents.

MCP stands for Model Context Protocol, a popular standard for connecting AI applications to external tools and data sources. MCP servers provide tools that connected clients can use. Each tool has a name, a description, an input schema, and a handler that performs the work.

When an agent selects a tool, the MCP client sends the tool call to the server, which then interacts with the downstream application. 

MCPs at Cloudflare

MCP is a critical piece of the infrastructure powering Cloudflare's internal agents. Those agents use MCP through local clients such as OpenCode and Cloudflare OS, as well as through long-running agentic services. We run the servers behind Cloudflare Access and connect to them through a single internal MCP server portal.

When we described our internal AI engineering stack in April, our portal connected 13 MCP servers. Today, it connects 27, with teams shipping more servers every month. They all began as read-only servers, allowing teams to search Jira, GitLab, our wiki, and operational systems without changing them.

Read-only was a good starting point. As models improved and teams gained experience with AI, people across engineering, product, design, sales, and customer success began asking for tools that could take action.

To avoid our own case of the endlessly closing tickets, we wanted centralized control over the write actions agents could perform, agent labels to appear in downstream applications, and an audit trail that made agent activity easy to investigate. We could not count on client-side controls such as skills or elicitation prompts. Their behavior varies by harness, and users can disable them.

So we built WriteGuard.

Introducing WriteGuard

WriteGuard is a shared policy, attribution, and auditing layer.

It uses each tool’s configuration and the request context to determine what happens. WriteGuard can pass a call through unchanged, enrich supported writes with agent attribution and produce a scrubbed audit event, or block an action before its handler runs.

The diagram below shows where WriteGuard sits in our current internal MCP architecture.

WriteGuard combines tool policy with human and agent identity, downstream attribution, and centralized auditing. It gives us one place to control agent actions and preserve the context needed to understand them.

Beyond callable tools to governable actions

WriteGuard lets us define policy alongside each tool without changing the underlying MCP server. Every tool gets a risk tier, an enabled or disabled state, and a labeling configuration. Risk tiers determine whether the action is logged and whether the tool call is permitted, and the tiers allow for querying the audit log by risk. We support labeling so that we can insert agent attribution labeling and use the best text format for the downstream application, without any code changes needed in the MCP server itself.

Today, we define this configuration in TypeScript in our internal MCP monorepo. As private beta access rolls out in the coming months, server owners will be able to configure the same policies through Cloudflare MCP server portals. Every MCP server will have a baseline Access policy along with WriteGuard controls for individual tools.

Keep the person, add the agent

Our internal MCP servers use Cloudflare Access and OAuth to identify the user. Agents using those servers therefore operate with that employee’s permissions. If Joe cannot close a particular issue, Joe’s agent cannot close it either.

We kept that model instead of introducing standalone agent accounts. Agent accounts would create a second set of permissions to manage and make the connection to the person responsible for the agent less clear. The tradeoff with that decision, however, is that downstream applications see Joe’s credentials but nothing identifying the agent behind the action.

WriteGuard adds MCP client and session context to the human identity, identifying each write as an agent session acting on behalf of a particular person. Notably, that attribution is extremely useful even when nothing goes wrong. It helps humans and other agents interpret changes and decide how to respond.

Make machine-speed activity queryable

Visible labels explain individual actions and provide helpful context in the downstream application, but they don’t provide a fleet-wide view. Because an agent can repeat an action much faster than a person, we also needed central auditing across every MCP server.

WriteGuard classifies each invocation as successful, failed, or blocked, then asynchronously sends a scrubbed event to an internal audit Worker. The event omits values for keys considered secret or sensitive. It includes the server, tool, risk tier, outcome, user, client, and duration.

This makes agentic activity queryable across all of our MCP-enabled systems.

The dashboard complements the request logs provided by MCP server portals. Portal logs show tool invocations, while WriteGuard adds semantic tool classifications, agent context, and outcomes from the backing servers.

We made audit logging asynchronous, so it adds no latency to the response the agent is waiting for.

WriteGuard in Action: GitLab

Earlier in this post, we mentioned three tools from our GitLab MCP server: get_merge_request, create_mr_note, and merge_mr. Let’s follow each one through WriteGuard.

Reading a merge request

Suppose an engineer asks an agent to summarize a proposed code change and the agent calls the get_merge_request tool. WriteGuard classifies the tool as READ_ONLY and WriteGuard allows the call to pass through unchanged.

Adding a note to a merge request

Now the engineer asks the agent to leave comments on a merge request (MR), and the agent calls the create_mr_note tool.

The tool is classified as CONTAINED_WRITE. WriteGuard adds agent attribution to the configured note field using a format GitLab supports, then invokes the tool handler. It also asynchronously records a scrubbed audit event containing the user, tool, outcome, and agent identity context.

Merging the code

Suppose an engineer asks an agent to help review a merge request. Trying to be helpful, the agent goes beyond the request and calls the merge_mr tool without being asked.

Because merges at Cloudflare typically trigger deployment pipelines, we require a human in the loop. We therefore classify the merge_mr tool as CRITICAL risk tier and configure the tool disabled in WriteGuard.

If called, WriteGuard will block the request before its handler runs and record the attempt.

Beyond the single server example

These tools use the same server, identity flow, and downstream API, but WriteGuard handles each one differently before its code runs.

For GitLab alone, we could have built these controls directly into the server. But we needed the same capabilities for Jira, our internal wiki, Google Workspace, and every new MCP server we added. Reimplementing them in each server would take more work and produce inconsistent behavior.

Instead, we built WriteGuard as a shared layer that needs only per-tool configuration and works across every MCP server connected through the portal.

From internal rollout to private beta

We built WriteGuard for Cloudflare's own MCP servers because we needed to move beyond read-only tools without losing control of the writes that followed. The private beta brings that architecture to MCP server portals, providing a way to classify write tools, block tools before execution, add agent attribution, and inspect write activity across connected servers.

The beta will start small and expand over time, leading up to general availability. We want to validate how the risk model maps to customer tools, which downstream applications need attribution formats, and what audit delivery guarantees customers require before making WriteGuard broadly available.

If your organization is adding write tools to MCP servers and wants to test these controls with us, sign up for the WriteGuard private beta.

Cloudflare OS: an open platform for agents, apps, and work

Post Syndicated from Phillip Jones original https://blog.cloudflare.com/cloudflare-os/

Every organization has a mission, a reason for being. Organizations pass that mission — along with their terminology, procedures, systems, standards, and ways of working — to their people. People, in turn, take this context together with their own experience and work towards the mission.

Work can take many forms, from code, to documents and slides, to relationships, to outcomes in the physical world.

Some of these are straightforward: code either runs or it doesn’t. Agents have been using this feedback loop to produce code that “works” for developers over the last couple of years. But what about the rest of us?

Bringing the same leverage to the rest of the organization is a harder problem. Agents need to understand the context of the company and be able to reach the systems people use to do their jobs. They need to turn that context and access into work that moves the organization towards its mission.

That’s why we created Cloudflare OS. It gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

In May of this year, we gave every person at Cloudflare access to the first version of Cloudflare OS. Thousands of people across every function, many of them outside of engineering, use it every day to create documents and slides, automate repeatable tasks, and build small apps to visualize data and help them do their work.

Cloudflare OS also gave everyone a shared library of context and skills built by teams at Cloudflare. It captures our terminology, procedures, and best-known ways of doing recurring work as instructions an agent can follow. When one person figures out a better way to do something, everyone else can use it.

Today, we are open sourcing a new version of Cloudflare OS. Any organization can deploy it, connect it to internal systems, and make it their own.

What we learned from the first version

The Cloudflare OS we are open sourcing today is based on what we learned from running the first version internally, a journey our CIO, Sam Rhea, covers in his blog post.

The first version centered on individuals working with agents through private workspaces. Apps were static rather than live software connected to internal systems, and mostly deterministic jobs still required running an agent skill again and consuming more model tokens.

Collaboration exposed a more fundamental challenge. Access to an MCP server told us which tools an agent could call, but not which underlying resources the agent had observed. Once people began sharing workspaces, apps, and outputs, we needed to ensure that collaboration could not expose information someone was not permitted to see.

We rebuilt Cloudflare OS on a new foundation to solve these problems. Security had to be part of the platform, not something every person building an app or using an agent has to implement correctly.

The result is a platform designed to belong to the company running it. You can customize the interfaces, connect your tools, and add the skills and context that capture how your organization works.

Introducing Cloudflare OS

Cloudflare OS starts with a conversation in your browser, like many other AI tools. What makes it different is that each conversation is grounded in the context and skills your organization has curated. Give your workspace a goal, and it can draw on that knowledge and work with the tools and data your organization already uses to achieve it.

Cloudflare OS combines three parts:

  • An agent workspace grounded in context and skills your company curates, with an isolated runtime where agents can write and run code.
  • A new security and governance framework for safe access to internal data and services.
  • A platform for personal, modifiable apps that people can build, share, and continue changing.

What begins as a conversation can become a doc, an app, or a workflow that continues doing the work.

An agent workspace for everyone in your company

Agent workspaces were designed for everyone in your organization to use. You interact with them in your browser, so you don’t have to be a developer or know how to use a terminal. 

A workspace combines agent sessions, persistent state, outputs and files, resource access, and an isolated runtime where the agent can write and run code.

They come loaded with the curated context and skills your team or company has collected. No more reinventing the wheel for every task — if someone on your team has figured out the best way to do something, everyone benefits. People no longer have to explain the same process, terminology, and best practices to a model every time they start a task.

A few things you can do:

Research and ask questions

Ask a workspace to research a topic using company context and the resources you make available to it. The agent can write code to search, filter, join, and analyze information instead of pulling an entire dataset into the model’s context window.

Create docs, slides, and spreadsheets

A workspace can turn its research into a document, presentation, or spreadsheet that you can continue editing. These outputs do not have to be static files. They can remain connected to live data, be updated as their sources change, and still be exported to familiar formats or services such as Google Drive.

Create collaborative, connected apps for your team

When a document or spreadsheet is not enough, the agent can build an app with its own interface, logic, and state. The app can use connected company resources and support multiple people working together.

Run deterministic workflows 

Not every job needs a full agent session. Many are a known sequence of steps with one or two places where judgment is useful. A workspace can turn those jobs into mostly deterministic workflows, using code for the predictable steps and a model only where it adds value. Workflows can run on demand, on a schedule, or when an event occurs in a connected system.

Cloudflare OS gives agents and apps governed access to systems of record through Gatekeepers (more on this in the security section below). It also supports existing Model Context Protocol (MCP) servers your organization already uses via MCP Server Portals.

A new security and governance framework for safe access to internal data and services

As people begin experimenting with AI at work, one of their first requests is often for API keys to company systems. This makes sense: AI isn’t much use at work if it doesn’t have access to the systems people use to do their jobs.

But handing over API keys to people and agents is dangerous and does not scale. Keys often provide broad, long-lived access that is difficult to constrain, share safely, and audit.

MCP gives agents a better way to use these systems. An MCP server can hold the credential and expose a defined set of tools instead of handing the key directly to the agent. But controlling which tools an agent can call is only the first step. MCP alone does not tell us which underlying resources an agent has observed. The agent can combine information across systems, send it somewhere less restricted, or expose it through apps and outputs to people who may not be allowed to see the original resources. Authorization has to account for where the data can go next.

Agents start with no access

Cloudflare Access controls who can enter Cloudflare OS. Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny. Generated code receives that resource as a typed binding:

env.PROJECT is a capability representing permission to use a specific resource under a specific policy. The credential remains completely isolated from the agent and any generated code.

Server code runs in a Dynamic Worker with global outbound networking disabled. Client code runs in a sandboxed frame in the browser. Neither can reach the Internet except through capabilities you explicitly provide.

Gatekeepers govern resources and actions

A Gatekeeper is a service-specific Worker that sits between Cloudflare OS and an external service. It understands the service’s API, its resources, and the operations that can be performed on them.

Giving an agent access to your entire GitHub account is likely too broad. A Gatekeeper can give it access to a single repository, allow it to read issues but not source code, mask particular fields, apply rate limits, and require approval before merging a pull request.

The agent and its apps see a small TypeScript API. The Gatekeeper handles OAuth, holds the credential, enforces policy, records what was read, and mediates anything with an externally visible side effect.

Policy follows what the agent has seen

Controlling the initial read is not enough. Take, for example, the case where an agent reads a sensitive table in a data warehouse and uses it to produce a live dashboard. Sharing the dashboard must not become a way to share the table with people who could not access it directly.

Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work. When another person tries to open the workspace, interact with the agent, or view what it produced, Gatekeepers verify that person's access to the observed resources.

The same observation log is used to inform policies that determine when agents can make external requests. A read of sensitive data can prevent the agent from writing data to certain sources, inviting new collaborators, handing work to another agent, or making an outbound request.

People using agents or building apps do not have to worry about making these mistakes. The platform can now be used to handle this.

A platform for building and sharing personal, modifiable apps

Most productivity suites give you a fixed set of applications: documents, spreadsheets, and presentations. In Cloudflare OS, each “file” can be its own application, written by an agent for one person, one project, or one team.

These are not prototypes that you have to export and deploy somewhere else. Each one is a full-stack application with client code, server code, an API, and durable state. Apps are private by default, but can be shared like documents.

Every app is a Worker

When you ask your workspace to build an app, the agent writes two parts:

  • Client code that renders the app’s UI in the browser
  • Server code that stores state and implements the app’s behavior

The server is loaded on demand as a Dynamic Worker and instantiated as a Durable Object Facet (both are features we built for this project). The facet gives the app its own SQLite database, separate from the Cloudflare OS runtime managing it. Dynamic Workers use lightweight V8 isolates, so every app can have its own isolated runtime without needing a dedicated server or container sitting around.

The browser client talks to the server using Cap’n Web, Cloudflare’s open source object-capability Remote Procedure Call (RPC) system. A server method can be called from the client like a normal JavaScript function:

The special part is that the agent can also call the same method.

So if you can build a tool to do a job yourself, agents can use your tool to do the job when you’re not there.

Share the app, or share how it was built

When you build an app in Cloudflare OS, you have two ways to share them:

  • Sharing your app itself lets other people collaborate in real time using the same state.
  • Sharing a blueprint of your app lets other people create their own copy of your app.

An app instantiated from a blueprint contains the original app’s code. But it does not contain its SQLite data, conversation history, credentials, or connected resources. Each new app starts with independent state and resources.

This means when you share apps with your team, they can modify them themselves with AI instead of filing a feature request and assigning you.

Use any model, and control what it costs

Cloudflare OS can be used with any model. Every inference call runs through Cloudflare AI Gateway, giving your organization one place to decide which models are available and which model should handle each job.

Not every task needs the most expensive model. You may not want to run the most expensive frontier model to summarize your unread emails every morning. AI Gateway gives you the control needed to make sure expensive models are only being used for the hardest work.

Every request is attributed to the person, team, or workspace that made it. Administrators can see where inference spend is going, set budgets and rate limits, and decide what happens when a limit is reached. 

Open source, so you can make it yours

Cloudflare OS is available today and is open source. Check out the cloudflare-os GitHub repository. You can deploy it into your own Cloudflare account and use your own Access policies, AI Gateway configuration, data, and integrations.

Our internal deployment reflects Cloudflare’s systems, terminology, policies, and ways of working. Yours should reflect your organization.

Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.

We are releasing two repositories: the Cloudflare OS core and an example deployment based on how we run it internally at Cloudflare. The deployment repository consumes the core without patching it, providing a place for configuration, custom UI, internal integrations, analytics, and deployment pipelines.

Delivered together with our partners

The source code is only the starting point. The context, skills, workflows, internal systems, and policies are what make Cloudflare OS even more useful for your organization.

Cloudflare’s strategic partners, Presidio and Happy Cog, will work with you to customize Cloudflare OS around how your organization operates and roll it out across your workforce.

Partners can help you curate shared skills and institutional context, build custom interfaces, connect internal systems through Gatekeepers and MCP Server Portals, and configure security, model, and cost controls.

You get your own branded Cloudflare OS, connected to your systems, running on Cloudflare, and shaped around how your people actually work.

Get started

Cloudflare OS is available today on GitHub. You can explore the source code, try the demo, or deploy it into your own Cloudflare account in a few minutes using our starter repository.

We’re just getting started. We’re working on bringing Cloudflare OS to the Cloudflare dashboard as a fully managed product, adding containers for development workflows, and bringing workspaces into Slack and other chat tools.

If you’re interested in talking with our team, we would love to chat. Use this form to reach out!

Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet

Post Syndicated from Will Papper original https://blog.cloudflare.com/wallets/

Today, it is difficult for AI agents to try out new APIs. They often have to navigate through a login page designed for humans and not agents, contact a human to add a payment method, generate an API key, and then figure out how to call the API.

This flow is very difficult for agents for two reasons: Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs. Because they lack these things, they often struggle to onboard onto software, which limits the growth of agentic commerce. AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans. This makes it very difficult for agents to try out and compare many APIs.

To solve this, we’ve created Cloudflare Wallets. Starting today, you can claim a Cloudflare Wallet handle for your account, which will provide a unique username to help you better connect with merchants. Soon, you will be able to set up and use your Cloudflare Wallet to pay for APIs and content.

Earlier this month, we announced the Monetization Gateway to help Cloudflare customers get paid for their websites and applications. Monetization Gateway will support micropayments using the x402 protocol, which allows for payments to be attached to HTTP requests. These micropayments will be able to pay for uses ranging from AI inference to data to content. If you want to pay or get paid for services behind Monetization Gateway and other x402-compatible endpoints, you’ll need a wallet. 

Cloudflare Wallets will allow you to store stablecoins, purchase services, and receive funds across the web. Each account with a wallet will also be able to create Virtual Wallets for its agents to enable them to buy APIs, MCP Tools, content, and more. You will be able to define guardrails for your Virtual Wallets (such as an allowance, an allow list, and a maximum transaction size) to help your agent spend money safely from your account. This will allow your agent to try out many APIs with low friction and managed risk. Wallet users will have the option to share their Cloudflare Wallet handles, which will give them a stable identity when interacting with merchants.

Building the two-sided agentic market

Cloudflare’s Monetization Gateway will allow eligible Cloudflare customers to sell their resources (such as content or APIs) headlessly to agentic buyers. But for that market to truly develop, agents need more tools to buy from merchants in a machine-native way. Wallets will add another tool to Cloudflare’s Agents SDK, enabling AI agents to easily purchase necessary APIs and content using micropayments.

There will be two types of Cloudflare Wallets: Account Wallets and Virtual Wallets.

Account Wallets are designed for humans who are owners and users of Cloudflare accounts. They will be able to add funds, delegate spend to virtual wallets managed by agents, and remove funds as needed. 

Virtual Wallets, by contrast, are designed for agents and operate via API keys. Within a Virtual Wallet, an agent will be able to spend funds according to its permissions. Its maximum spend will be capped by the limit set by the owner of the Account Wallet. This framework gives agents freedom to act on behalf of users without constant manual approval while limiting an agent’s ability to overspend.

The freedom to explore

Virtual Wallets are exciting because they will allow agents to do what they’re best at: explore dozens or hundreds of services and find the best one for a particular use case. Stablecoin micropayments via x402 will make it simple to try an API without an account, allowing agents to test new options with little friction. The spending caps on Virtual Wallets are designed so that humans can let agents explore autonomously within safe spending limits. These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000. If an API only costs a few cents to try, then $10 is more than sufficient to pursue and evaluate many options.

Once you or your agent has picked an API to use, policies set by you in your Account Wallet will act as cost controls for Virtual Wallets. Want to give every employee a $100 per week budget for AI inference? Simply provision an Account Wallet with the right balance and create Virtual Wallets for each employee with that rule. Anyone who exceeds the limits on their Virtual Wallet will be able to request a manual override from a human who is authorized to make changes to the Account Wallet.

We want to make it easy for Account Wallets to set flexible yet firm spending policies that do not require daily, active monitoring. When something anomalous happens, such as unexpectedly fast spending, a human will be able to review and confirm whether everything is operating as intended. If the spend was intentional, then the administrator of the Account Wallet will be able to raise the limit or approve a one-time injection of funds. If the spend was unintentional, then the spending policies for adding funds to virtual wallets did their job by imposing caps.

We are working to make it as easy as possible to fund and use these wallets. We will start with simple ways to onramp and offramp funds within supported geographies, with self-funding via stablecoins available as an alternative for eligible users. The Internet will not shift completely overnight, but with a majority of traffic on the web now being driven by bots, we are excited to give agents and merchants first-class tools for agentic commerce.

Beyond payments alone

Allowing humans to delegate authority to agents to easily buy and sell services is a helpful starting point. But this delegation is not always obvious to the merchants as they interact with agents. Today, if an agent comes to your website, you may know little about them as a user, despite the fact that the agent is acting on behalf of an individual or an organization. This lack of attribution challenges many traditional web business models. It’s easy to give a one-week free trial or sign-up credits to a human or an organization. It’s hard to give these same perks to an agent that lacks a stable identity and when one human can spin up dozens of agents under their control.

We solve this problem by linking wallets to a Cloudflare account via cloudflare.pay. cloudflare.pay will allow agents to optionally identify themselves, since their identity is a delegate of the account. A research agent could live at research.example.cloudflare.pay, allowing merchants to know that it is an agent from a particular organization. This approach will permit agents to maintain consistent and persistent identities, making the experience better for all parties. It will be completely optional for agents to choose to declare their identity or not, and it will be up to businesses to decide whether they want to prioritize transacting with known agents.

Agent identifiers should be human-readable

We believe that the approach to dealing with agents will look like the approach to dealing with VPNs: If someone is unidentified, they are not inherently untrustworthy, but they need to prove themselves more. This is why we have Turnstile and other initiatives to detect bots within Bot Management. Our identity primitive will build on top of this prior work. For example, Web Bot Auth already allows agents to register their identity via a keypair. IDs attached to Cloudflare Wallets allow this keypair to become human-readable.

We know that agentic identity standards are changing quickly, which is why we wanted to keep our approach simple. We are proposing a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS. We are not trying to define a particular schema or other verification system. We only want to make identity simple to remember and easy to declare. As schemas to enrich agentic identity develop through the x402 Foundation’s initiatives, we will seek to adopt them and intend to encourage others to do the same.

The future of agentic commerce

At Cloudflare, we want to offer all the building blocks for agentic commerce to succeed. Monetization Gateway will offer a way for sellers to get paid without setting up traditional payment infrastructure. Wallets will offer a way for buyers to pay headlessly via agents. Identity will allow merchants to communicate with buyers who identify themselves or enforce identification requirements.

All of these building blocks will create a headless marketplace for the Internet. If you are excited about this and want to participate, you can claim your handle now. We’re excited to see what you build and monetize.

How we built a software factory to drive Astro’s GitHub issue count to zero

Post Syndicated from Matthew Phillips original https://blog.cloudflare.com/astro-issue-triage/

Everyone is talking about software factories: the idea that AI agents can be assembled into a pipeline that produces working software on their own, the way a factory turns raw materials into finished goods. There’s endless debate over whether that’s actually possible, how far the automation can really go, and whether the “loops” people are demoing count for anything. Some have already written them off as a failure.

Running alongside that is a quieter, more worried conversation: open source maintainers are burning out. The AI boom has made it nearly free to generate issues, pull requests, and security reports, and enormously expensive for a maintainer to read through them all. The old ways of keeping a project healthy are buckling under the volume.

Everyone has a hot take on both topics. We think we have something rarer to offer: real results. For the past several months we’ve run an automated triage pipeline on the Astro repository. It reads incoming bug reports, reproduces them in sandboxes, diagnoses the root cause, and ships preview releases for the reporter to verify. The engine underneath it grew into Flue, an open framework for building this kind of agent automation, and it’s the same tool you could use to build your own.

It wasn’t an instant success. But through a lot of iteration, we’ve used it to bring our open issues down from over 200 to about 30, and we expect to hit zero sometime in the next month. That would be the first time this repository has seen zero open issues in its 5+ year history. 

We didn’t get there by declaring "issue bankruptcy," auto-closing cold tickets, or ignoring reports. We did it by automating issue triage with a team of isolated AI subagents running right inside GitHub Actions. Here’s the story of how we got there, and what you might take back to your own projects.

Starting with an agent skill

At the start of the year, we focused on automating one specific area of development: issue triage. As an open source project, manual issue triage can be one of the more time-consuming, least-rewarding parts of the job. A single issue can sometimes take hours just to reproduce, let alone fix. It was a natural (yet often overlooked) place for us to start our automation journey.

We began by developing an agent skill. This allowed us to develop and test the automation locally as maintainers, running a coding harness on our own machines. We could then run that same harness in a GitHub Action on our repo, and get total reuse of that exact same triage workflow skill.

The triage skill mirrors the exact steps we take during manual issue resolution:

  1. Reproduce: Clone the provided reproduction repository to verify the reported issue.
  2. Diagnose: Instrument the codebase and introduce logging to pinpoint the root cause of the bug.
  3. Verify: Review relevant test suites, code comments, and documentation to determine if the behavior is genuinely a bug or intended functionality.
  4. Fix: Convert the reproduction into failing unit tests, identify the appropriate solution via the architecture guide, and deploy the fix.

To prevent the frequent LLM bias toward forcing a solution when a bug might not actually exist, each phase is executed by an isolated subagent. These subagents pass information forward sequentially by compiling their discoveries into a report.md file.

Turning the skill into an automation

Following initial internal testing of the triage skill, our focus shifted toward building a fully automated pipeline. We specifically wanted to integrate this logic directly into a GitHub workflow, ensuring complete transparency so that anyone could easily audit the agent's sequential reasoning and operational steps.

As we wired it up, we realized the whole pipeline was really just a state machine driven by issue labels. Every new submission starts with the label triage needed, and once a user confirms a fix it moves to fix verified. Beyond those label transitions the pipeline holds no state of its own; it simply reads back through the issue’s existing comments to work out where a given issue is and what should happen next.

From there the flow runs on its own. When the agents land on a fix, the pipeline spins up a preview release with pkg.pr.new and posts everything back to the issue: a summary of what it found, the full logs, and instructions for installing the preview. The original reporter can then try the patch against their own project, and if they confirm it works, the automation opens a pull request linked to the issue.

From triage to a framework

As we built this out, we kept noticing that nothing about it was really specific to GitHub. Reacting to an event, running a sequence of isolated subagents, and separating their reasoning from the actions they’re allowed to take — it’s all just a workflow. One that could run just as well from a Slack message, a cron job, or a webhook as from a GitHub issue. Generalizing that realization into a runtime that works the same way regardless of where it’s deployed, or which model it’s driving, is what became Flue: an open, platform-agnostic framework for building durable agents and workflows.

Benefits of agent automation

When we first launched this automated system, we had shared concerns about its efficacy and the potential negative impacts it might have on our developer community. There was a valid fear that relying on automated bot responses might feel impersonal and create just one more disconnect between us as maintainers and our user base.

That did not happen. If anything, we talk to users more now, just in more useful places:

  • Engaging directly with our community members within Discord.
  • Actively participating in RFC discussions and addressing new feature requests.
  • Collaborating closely with contributors to help integrate their ideas into the framework.

Regarding the quality of automated patches, our core philosophy is that our AI agents should successfully resolve the vast majority of incoming issues. When an agent fails to identify a correct solution, we interpret that failure as an indicator of an underlying architectural or documentation issue within the codebase, pointing to one of three areas:

  • Opaque Abstractions: If an agent cannot interpret the boundaries between components, human developers likely struggle with the code structure as well.
  • Missing Documentation: Critical code segments lack explicit comments explaining the rationale behind their implementation.
  • Insufficient Testing: The repository suffers from a lack of comprehensive test coverage, particularly unit tests.

A clear example occurred with a series of related Hot Module Replacement (HMR) bugs. The triage bot repeatedly attempted to modify a specific if condition to resolve the issue. While this change fixed the targeted bug, it introduced regressions elsewhere due to a lack of test coverage for that specific condition. Once we added a descriptive comment explaining the exact logic governing that statement, the bot adapted and stopped attempting incorrect modifications in that area.

Every time we chase down one of these failures and add the missing comment, test, or clearer boundary, the bot gets noticeably better at that part of the codebase, and so does the next human who works on it.

Turning the workflow into a GitHub Action

Initially, our triage logic lived directly within the Astro monorepo. This coupling made iteration difficult; upgrading Flue or modifying the workflow felt like performing surgery on live infrastructure without a safety net. To solve this, we decoupled the logic into a standalone, testable repository: triagebot-action. This isolation allowed us to introduce automated testing and ensure stability before ever touching our primary codebase.

Today, this action powers issue management in Astro, and it has spread from there. Several other teams have picked it up, some using it directly, and others forking it to build their own automated "factories" tailored to their projects. That second path is really the point: triagebot-action is young and still actively evolving, so we’re sharing it less as a finished product and more as a working reference you can read, learn from, and adapt. 

The wiring for the action itself looks like this:

Or point your own agent at the repository and have it read through the setup, including adding the labels the state machine relies on.

Whichever route you take, the underlying idea matters more than our specific implementation: a sustainable feedback loop that frees maintainers to focus on the framework itself instead of administering a backlog. The code is open. Fork it, strip it down, or just borrow the parts that fit your project.

Want to build something like this? Dig into the code of the triagebot-action to see how it works, or fork it as a starting point for your own repository’s automation. And if you’re building agent-based infrastructure more seriously, that’s exactly what Flue is for: dive into the Flue framework to build your own. We’d love to see what you build. Come share your "factory" stories in the Astro Discord.

How Cloudflare enforces engineering standards using AI

Post Syndicated from Timo Reimann original https://blog.cloudflare.com/engineering-standards-enforcement/

Over the past four months, our AI code reviewer has flagged nearly a quarter of a million deviations from Cloudflare engineering standards (what we’ll call “violations” in this post) and blocked 16,000 merges. Our spec reviewer agent has evaluated close to 600 technical designs against the same standards before implementation began. Both systems draw from the Cloudflare Codex, a shared source of engineering guidance built for people and agents. This post explains why we built the Codex, how it supports the engineering lifecycle, and what we plan to do next.

Before the Codex (which we briefly introduced in a previous post about our AI engineering stack), developer guidance at Cloudflare lived in many places: formal documentation, repository files, chat threads, and the accumulated knowledge of individual engineers. Engineers often spent too much time searching for guidance instead of working on the problem they were trying to solve. Even after finding an answer, they could not always tell whether it was current, authoritative, or applicable to their situation.

As Cloudflare grew, that model became increasingly difficult to sustain. No engineer could read every standard, and reviewers could not reliably check every requirement. Institutional knowledge became harder to recover when people moved between teams, and guidance that was not consistently surfaced or enforced led to drift between projects.

We rebuilt this body of knowledge as the Cloudflare Codex: a governed set of engineering standards that agents can retrieve and apply at the point of work. The same guidance can now inform code review, technical design review, incident report review, and many other use cases, while engineers focus their time and judgment on the resulting findings.

Codex organization and workflow

A dedicated Codex governance model divides the Codex into distinct domains covering the engineering areas we care about. These include architectural matters (for example, frontend and control plane), cross-cutting concerns (security and reliability), specific languages (TypeScript and Rust), and several other areas. Each domain is led by an owner who is responsible for the content, consistency, and overall quality of the documents they oversee.

Codex standards use a Request for Comments (RFC) format. Requirements use the SHOULD and MUST keywords defined by RFC 2119. We also expect a front matter header to hold metadata such as the domain and RFC status. Any Cloudflare employee with a key interest and domain competency can propose an RFC through a merge request that follows the prescribed structure. The proposal then passes through several rounds of feedback from an increasingly broad group of reviewers. Once the domain owner gives final approval, the RFC becomes part of the Codex and is published to an Astro-powered internal site.

Approved RFCs can be consumed by Codex clients and agents, which may then start to flag Codex violations in code, configuration, or documentation immediately. However, they block based on Codex statements only after an RFC moves from the approved to the enforced lifecycle state. This separate promotion step gives teams time to absorb new requirements and accommodates cases where enforcement needs additional work.

The following diagram illustrates the steps in the Codex workflow:

A naive process could stop here and feed the entire Codex to a large language model (LLM) as is. Given the increasing number of RFCs we have already (60+ and counting), however, the corpus volume would put a lot of stress on the context window and impact LLM results negatively. To help guide models to the most relevant RFCs, we invoke a purpose-built agent to automatically extract and compact the SHOULD and MUST statements into a dedicated JSON structure and enrich it with metadata that supports lazy discovery and progressive disclosure. The following abridged excerpt shows the result for our control plane services RFC:

Each statement receives a stable slug identifier that remains unchanged during the extraction process even when its RFC is updated. The identifier lets us track the same statement across different systems over time, which is essential for monitoring, analysis, and exception handling.

Initially, we extracted the statements into another, more concise Markdown file rather than JSON. Over time, we moved to a richer structured format so that agents could filter the content they needed more accurately. We plan to include additional metadata for even tighter scoping, such as indicators for the software development life cycle (SDLC) stage a statement applies to (e.g., design, implementation, runtime).

Codex consumers

Several systems already use the Codex in day-to-day engineering work. Three agents show how the Codex works in practice: our AI code reviewer, spec reviewer, and incident report reviewer.

AI code reviewer

Our AI code reviewer agent, covered in a separate blog post, evaluates merge requests across several dimensions, including Codex compliance.

For each review, the agent retrieves the RFCs and parses the Codex statements. It loads full RFC bodies only when the model or coordinator needs additional context. In most cases, the statements provide enough information to explain a reported violation.

The distinction between SHOULD and MUST, together with an RFC’s status, determines how the reviewer responds. Findings from approved RFCs are non-blocking recommendations. Once an RFC is enforced, an unsatisfied MUST requirement causes the reviewer to withhold approval or block a merge request, depending on the severity. 

Since the Codex’s inception earlier this year, the AI code reviewer has flagged close to 230,000 violations. Among these, almost 16,000 caused approval to be withheld (i.e., they referred to MUST statements on enforced RFCs).

Code review alternatives

A single AI code reviewer run usually takes a couple of minutes to complete due to the coordinator framework and sub-agent execution. Although the wait is very often worth the money (or tokens), engineers were calling out the delay and extra round trip involved in remediating the findings. We looked into how we could improve the experience and came up with two additional options:

  1. For language-specific Codex requirements that can be verified mechanically, we provide custom linter configuration packages. These are aligned with our Codex specification and make it possible to surface problems in milliseconds. TypeScript was the first language to receive Codex linter support while also standardizing on oxlint (maintained by the VoidZero team who joined Cloudflare recently) for performant linter execution. A linter for Rust projects is currently under development, and Go will eventually follow to complete coverage of Cloudflare’s most commonly used languages.
  2. To cut out the continuous integration (CI) leg from the review cycle, we made it possible to run the AI code reviewer locally through a command-line interface (CLI). It matches the coordinator functionality from CI and runs the same (OpenCode-based) agents against an automatically determined diff set, with results presented in the terminal.

We believe the linters would be useful to almost every developer and codebase, while the CLI remains an optional alternative for engineers who prefer it.

Spec reviewer

Engineers at Cloudflare regularly write design documents and technical specifications (or specs in short) before implementation. A significant subset of the Codex pertains to design, architecture, and other themes relevant to technical reviews. To catch architectural mistakes before implementation begins, we built the spec reviewer, an agent that discovers specs and evaluates them against relevant Codex requirements.

The spec reviewer operates on the Developer Platform: it runs as a Cloudflare Worker, stores its results and state in D1, routes model requests through AI Gateway, and kicks off scanning for new specs via a Cron Trigger. It starts by filtering the Codex by domains and sections relevant to specs (for example, language features and implementation-focused RFCs are disregarded). Several guiding prompts instruct the model on how to run the assessment and frame the results. The findings get rated based on severity (influenced by SHOULD and MUST keywords) and include general quality and architectural advice. On completion of a review run, a note is left on the spec document linking to a custom dashboard where review details can be inspected.

Since the beginning of May 2026, almost 600 unique open specs have been reviewed. Including reruns triggered on demand or by spec changes, we tracked over 3,200 review invocations to this date. The vast majority of findings had a “major” (65%) or “minor” (29%) severity, with “critical” findings being the minority (6%).

The following image gives an impression of what the spec reviewer UI looks like:

We plan to integrate the spec reviewer more tightly by posting comments directly on the spec documents, embedding human-agent conversations that can influence the review assessment, and flagging high-impact proposals for additional human review.

Incident report reviewer

The incident report reviewer applies the same approach to incident reports (also known as postmortems). In addition to checking that each report is complete, it evaluates whether the report clearly explains what happened, identifies contributing factors, documents the resolution, and proposes meaningful follow-up actions. These expectations are defined in a dedicated Codex RFC.

The incident report reviewer uses the same Developer Platform building blocks as the spec reviewer. This shared architecture is becoming a common pattern for our Codex agents.

Since May 2026, the reviewer has assessed more than 200 incident reports and identified gaps such as missing follow-up action items, incomplete timelines, and omitted detection signals. Among those reports, 93% covered incidents that were low-impact, internal-only, or declared preemptively. For high-severity incidents, we’ve made the reviewer mandatory as part of our comprehensive central review process, and reports are not considered complete until all findings have been addressed.

Future work

The Codex already supports agents that review code, technical designs, and incident reports. We plan to extend that model throughout the SDLC, allowing agents to surface issues consistently across design, implementation, and operations. The longer-term goal is for agents to identify issues as well as propose fixes with increasing autonomy, while engineers remain responsible for reviewing and approving those changes.

We are also expanding the Codex beyond engineering. Product, security, compliance, and trust and safety teams are beginning to add their own standards, allowing agents to evaluate work against considerations that extend beyond design and implementation alone.

Across a number of engineering workflows, Codex-backed agents have helped us surface issues sooner and apply standards more consistently. We have found AI most useful when it brings the right guidance to engineers at the point of work, and plan to keep extending the approach across Cloudflare.

If you’re interested in building systems like these, our engineering teams are hiring.

Run CI/CD for millions of repos — on your platform, on Cloudflare

Post Syndicated from André Venceslau original https://blog.cloudflare.com/ci-workflows/

We are moving toward a world in which you can store, build, test, and deploy your code fully on Cloudflare. We built the first piece with Artifacts, versioned code storage that scales to millions of repos. 

We have stitched the store, build, and deploy steps together with the CI SDK, built on Cloudflare Workflows, so that you can run your continuous integration (CI) pipeline on Cloudflare. You can send artifact push events directly to your Workflow, triggering an instance of its execution — a CI job, essentially — through a new events field in your wrangler configuration file. 

Then, directly from the Workflow with @cloudflare/ci installed, you can:

  • Automate builds: compile code from your Artifacts repo in a safe, isolated environment 
  • Run linters and typechecks: enforce code style, catch type errors, and flag any potential issues
  • Cache dependencies: run your install once and cache dependencies across steps in the CI job
  • Execute unit tests: verify that each piece of your code works as expected
  • Self-heal: integrate an AI review agent to catch broken steps in your build and push commits to fix 
  • Deploy conditionally: automatically deploy your code, only if your build step is successful

Today, everyone is building a platform, whether it’s an internal vibe coding platform or an extension of your customer-facing product via customization through code. Platforms are now using millions of repos on Artifacts to store their code, and their customers’ code, and version control across the two. But every team has their own needs for a continuous integration and deployment pipeline. For platforms, they might want to define a CI job for their own code differently from that of their customers. 

Many of the end customers building on these platforms don’t want the extra headache of managing their continuous integration and continuous deployment (CI/CD) pipeline. Instead, the platform can manage the build process on their customers’ behalf: write the CI/CD pipeline once and share it across all the applications that their customers are building. Some of the platform’s customers might want to define their own CI; if so, they can write their own Workflow and run custom CI jobs on just their repo, facilitated by dynamic workflows. The beauty is, you don’t have to pick and choose: both platform-managed and custom CI can run at the same time, in the same namespace.

A CI/CD pipeline is just a Workflow

Before today, we had all the pieces to allow platforms to wire their CI/CD pipeline together on Cloudflare. Now, we’re bringing a better developer experience to make it simple. 

A CI/CD pipeline — commonly orchestrated with GitHub Actions — is a series of steps that run in a specific order where, if any step fails, you stop running the pipeline and report the error. In essence, a CI/CD pipeline is just a Workflow. CI/CD, when defined by a YAML file, can get complicated quickly, given the constraints that so often lead to YAML fatigue. But each step in a CI/CD pipeline can translate simply to a Workflow step.do(). Instead of YAML, you can define your CI/CD pipeline in Typescript for greater customization and configurability. 

We are launching new tools in the CI SDK that allow you to run each step in your CI pipeline (e.g. build, lint, and typecheck) in a safe, isolated environment, built directly on Cloudflare’s developer platform via Workflows and the Sandbox SDK. Plus, you can now kick off a CI job directly on push instead of configuring an event subscription, a queue, and a queue consumer. 

Previously, you’d have to call the Sandbox API directly and manage state yourself across different steps in the CI pipeline. The SDK allows you to run each sandboxed command in its own Workflow step, providing the retries and timeouts built into Cloudflare Workflows. 

You can also speed up your CI pipeline by caching step results — for example, your install step — so that you don’t need to reinstall for all subsequent operations. Dependency caching reduces the latency of your CI/CD pipeline since every CI step won’t need to rerun the install.

To define your CI job, all you need to do is:

  1. Define your install step for any dependencies (external packages or tools that your CI job needs), such as bundlers (e.g. esbuild), linters (e.g. eslint), or test runners (e.g. vitest).
  2. Specify the command for each step in the CI job (e.g. bun run build, bun run test, bun run lint). With your dependencies cached, each CI step can execute in parallel, reducing the latency of the overall run. 
  3. Pass wrangler deploy in a deploy step. Your Worker will automatically deploy when the CI pipeline passes.

Writing your own CI pipeline in a Workflow allows you to customize as much as you want. For example, you could call an agent from your CI Workflow to give your CI jobs self-healing functionality: if a step in your build errors, the agent can fix it automatically, and push a commit for your approval.

Try an example of self-healing CI Workflows with Project Think: https://github.com/cloudflare/ci/blob/main/examples/self-healing

Write your own CI Workflow

To write your own CI Workflow, get started with import { CIWorkflow } from@cloudflare/ci.
Start with an install step:

  • Download your dependencies, including any external tools or libraries that your CI steps will need (e.g. vite, react).
  • Specify your lockfile, which tracks whether your dependencies have changed.
  • Cache your dependencies via a sandbox snapshot so that all subsequent steps have access. The snapshot will be stored in an R2 bucket on your account.

Then define steps for the build and checks, each executed in its own safe, isolated sandbox environment.

By default, each step in a Workflow starts independently, meaning the steps will execute concurrently unless otherwise specified. Running each step in parallel reduces the latency of your CI run. To ensure that all checks complete before the CI pipeline continues (for example, finish build, lint, test, and typecheck before the deploy step starts), wrap in a Promise.all(): 

Now, to actually trigger your CI Workflow, add an events field to your Worker’s wrangler configuration, alongside your Workflow and Artifact bindings. The events field is a new field supported within your triggers field. 

You could already subscribe to Artifacts through Cloudflare Queues via event subscriptions and kick off a build pipeline every time there’s a push event. But that requires setting up the event subscription, Queue, consumer, and queue handler. Now, you can target a Workflow with that event — every time that event fires, it will trigger an instance of the Workflow. 

Specify the CI Workflow as your artifact push trigger’s target to automatically trigger a Workflow instance on every cf.artifacts.repo.pushed event. Each CI run surfaces as a Workflow instance so you can view its step-by-step execution and observability directly in the Workflows dashboard. This is an Artifacts-first integration; coming soon, the types will support events from sources across your Cloudflare account to allow for programmatic consumption across the product suite.

If you want to run the CI Workflow on every repo in your namespace — for example, if you are a platform running CI on all of your customers’ repositories — omit repoName and only specify the namespace in filter.

To fully configure your CI Workflow, add bindings to each piece of the infrastructure which powers the pipeline: artifacts, workflows, containers and durable_objects (+ exports config) bindings (to access your sandboxes), plus an r2 binding if you are using cache. The R2 binding is required as the snapshot of your install step sandbox is stored in a bucket.

Self-healing CI runs

To allow your CI job to self-heal, you’ll need two pieces: the LLM and its agent harness. In the example above, we included a Think agent using Workers AI to catch errors in your pipeline and run the fixes on your behalf. Your CI job can be run and re-run remotely — no need to watch with your laptop open or check back every few minutes. Instead, Cloudflare handles it in the cloud, running your healer agent alongside the CI steps in a container. Instead of babysitting the CI job, making a manual fix, and re-running the pipeline, you’ll just need to merge the commit after your agent has made the fix. 

To set up an agent that self-heals your CI pipeline, add a Durable Object binding for your Think agent: 

Create your Think agent — Healer — by extending the HealingAgent class, which includes a heal method for you to call on failure. Pass whichever model you’d like to use: 

Then, wrap your steps in a try/catch block where a failure triggers the healing agent:

This example demonstrates a self-healing CI pipeline, but really, the Bring Your Own Workflow model allows you to customize the CI job however you want. This can be a place to add security rules, filters, or conditional CI steps. Using the BYO-W model, platforms can configure their CI/CD pipelines across different teams, customers, or applications according to each individual use case. 

The benefits of using a Workflow

By running your CI pipeline on a Cloudflare Workflow, you automatically inherit:

  1. Resilient retries (durable execution): if any step in your CI job fails, it will automatically retry with state persisted, meaning that no progress is lost. Every step supports custom retry and timeout behavior, so you can define different failure logic for each one. Plus, you can restart from a specific step, so if just lint fails, for example, you don’t have to rerun the entire CI pipeline. 
  2. Workflows observability: inspect your CI job step-by-step in the Workflows dashboard, where each instance surfaces the steps with their inputs, outputs, and wall and CPU time. You can visualize your CI job through Workflows diagrams in the dashboard, allowing you to easily see which steps run concurrently versus sequentially. You can also inspect Workflows logs through Workers Observability and GraphQL to understand more about runs of your CI job. 

  1. The power of code: by running CI in a Workflow, you can write a step for anything you want. For example, you might want to run an AI code reviewer as part of your CI/CD pipeline. You can make a call to your code review agent — or handle any custom logic you can put into code — with Workflows step.do(). Other examples might include writing build artifacts to R2 and sending an email when CI fails, completes, or merges to main.

What’s next

A CI/CD pipeline is just a Workflow — and with the CI SDK, you can define your CI across your code, and that of your customers, in simple Typescript rather than inflexible YAML. Building off the Cloudflare Workflows primitives, you can define whatever logic you’d like, whether that’s a healing agent, like our Think example, or writing build artifacts to R2. Running CI on Workflows helps bridge the gap between storage (via Artifacts), builds, and deployments. As a platform, this allows you to easily manage each step on your own code and on behalf of your customers.

Request to join the Artifacts private beta and get started with our Workflows CI guide. If you have any feature requests or notice any bugs, share your feedback directly with the Cloudflare team by joining the Cloudflare Developers community on Discord. 

What’s coming next:

  1. Direct integrations for Workers & Workers for Platforms: build.preview() and build.deploy() primitives to automatically deploy on push to main and create previews on push to non-default branches
  2. Gradual deployments: manage percentage-based rollouts via Workflows to customize your deployment progression and rollback logic
  3. Monorepos: simplified management for multi-Worker deployments using one CI pipeline
  4. Triggers: send push events from different sources to run CI jobs on a repo from any version control system, not just Artifacts

The Agent Development Lifecycle has arrived on Cloudflare

Post Syndicated from Brendan Irvine-Broque original https://blog.cloudflare.com/agent-development-lifecycle/

Engineering managers spent the past few decades figuring out ways for many programmers to work together on a shared codebase. This work dates all the way back to the “Systems Development Lifecycle” (RAND, 1975) – today commonly referred to as the “Software Development Lifecycle” (SDLC), which defines the following phases:

  • Plan
  • Design
  • Implement
  • Test
  • Deploy
  • Maintain
  • Retire

AI has made the step that was previously the slowest and most expensive — implementation — the fastest and cheapest. That, in turn, has had an impact downstream: overwhelming the people responsible for all the other steps in the SDLC. This ranges from open-source maintainers bombarded with thousands of pull requests and issues, to production engineers trying to save production from falling over as the rate of software delivery increases orders of magnitude.

We are all trying to save our systems, our customers, and ourselves from slop.

The answer — paradoxically — is to empower agents to do more. It’s only fair! You’d never let an engineer on your team write code, expect someone else to validate it, merge it, deploy it, hold the pager in production, and triage incoming bugs. But that’s what most companies are doing right now with agents. Models have improved remarkably, and agents are running over longer time horizons, able to take on much larger tasks. But they are not yet used evenly across the SDLC.

Cloudflare treats agents as our customers. They can buy domains, create temporary accounts and use the entire Cloudflare API. We know that agents need APIs and tools to be able to manage the full SDLC on behalf of our customers — not just the start of it.

And so today we’re introducing the start of a new set of tools that let agents step beyond just generating code and take on more of the SDLC. We’re sharing what we’ve built and learned trying to solve this for ourselves:

There’s something bigger here though. When we look at the SDLC, even with the best automation, its assumptions do not scale for the volume of code agents can write and the pace at which software teams must move to compete. We think it’s time to replace the SDLC with the ADLC — the Agent Development Lifecycle.

The SDLC is for software teams. The ADLC is for software factories.

Right now, everyone is talking about building “software factories” — agent-driven systems that take input and autonomously build, improve, deploy and manage software. Take an input, whether it’s a production error, a bug report from a customer, or an idea for a new feature, and delegate it entirely to an agent.

Even with agents, most software projects are constrained by human-in-the-loop steps. Humans prompting agents, telling them to keep going, instructing agents to apply feedback from a code review, constantly babysitting many agents and giving them instruction. On most software teams, the human still manages each step in the SDLC model — the only change is that they delegate tasks within each step to an agent.

And so the dream behind software factories is: what if you reimagined this approach and built a factory for the entire process of building software? How can we shift more human time towards the things that truly require human inspiration, taste, and judgement? It would leave us more time to design, to talk to customers, and to dream bigger.

A software factory has to manage the same steps in the SDLC, but it demands much more from the platform it is built on. Because when you hand over the keys and let the agent drive, every manual step that previously relied on a human must be adapted to be:

  • Programmatic — ”ClickOps” was bad practice for humans, but it’s a non-starter for agents. Every last operation needs APIs that agents can call, debug, and rely on.
  • Horizontally scalable — preview deployments were a nice-to-have when humans stared at the screen while building or manually took over a staging server to catch issues before production. For agents to drive, every agent must have its own preview that matches production.
  • Reproducible — what happens if there’s a bug that you can only reproduce when simulating 4G on an iPhone 15? Or from an IP in a certain country? Typical unit testing and integration testing tools aren’t going to help here.
  • Real-time, push based — relying on humans to look at the right dashboard has always been a bad way to know if things are working, but it completely breaks down with agents. You need an event that triggers an agent to do work.
  • Atomic — every change needs to be independently testable, releasable, observable, and reversible without affecting unrelated behavior.
  • Permissioned — you know you probably shouldn’t, but today you give a few trusted engineers the keys to SSH into prod in case things really go haywire. There’s no way you let an agent do that — but without the ability to escalate and get more permissions, how can it do its job?
  • Self-improving — people learn from experience. The first week ship or the first on-call rotation, humans are slow and need to shadow someone else, but then get better and faster. Agents, too, need ways to learn from experience.

We need something new if we are going to make software factories safe to use for real production software. Software factories face the same challenge that other autonomous systems like self-driving cars do — the challenge of going from working successfully 80% of the time, to some number of nines past 99%.

To give agents the keys to drive the SDLC, you can’t give them a car designed for humans

An autonomous vehicle is loaded with sensors and technology that a regular car doesn’t have. Lidar sensors, cameras, powerful compute to run inference, and connectivity to a central command system that can take over remotely if needed.

For an autonomous vehicle to be 80% as good as a human at driving, we probably don’t need all of this. Self-driving got to around 80% as good as humans 10 years ago. But that’s not the bar to clear — the bar is to be much better and safer than a human driver. That’s what we expect when we hand over the keys to a machine, in order to feel safe taking a nap driving down the 101 at 60 mph. And that’s why autonomous vehicles have technology that is purpose-built for self-driving — it’s what builds trust and handles the edge cases that cannot be designed for upfront.

The same is true of self-driving software. Ask yourself — why haven’t you yet just let your agent auto-approve and merge its own PRs to your production services? The higher the stakes of what you build, the longer your list of reasons almost surely is.

When you start to unpack not only all the things that can go catastrophically wrong in this process, but also that are necessary to building the right thing for customers, it is remarkably complex. It doesn’t fit into a linear set of steps in a GitHub Actions YAML file, and it goes way beyond running traditional automated tests. Even a small change to a dashboard can span roles, specializations and org structures, and subjective changes are the hardest to test and to delegate. Most of these things are probably not part of your CI/CD pipeline at all today. But they will need to be, if you want them to still happen, while giving full control to the agents running the software factory.

To let agents drive the whole process, we need a better way to orchestrate these dynamic series of steps. We think that is a Workflow, with the capability to spawn containers, agents and browsers. A Workflow that can set feature flags and enable them for a test user, investigate logs and traces, observe production metrics as a change gradually rolls out, and do everything else that is needed in order to ship safely.

A CI/CD pipeline is just a Workflow. But a Workflow can be so much more than a CI/CD pipeline.

Cloudflare Workflows let you chain together multiple steps, automatically retry failed tasks, and persist state for minutes, hours, or even weeks. They are designed to encode complex and dynamic business processes in a logical and well-understood program. This blog post breaks down why Workflows, in tandem with Artifacts, make defining and triggering CI/CD pipelines fundamentally simpler. For example:

Workflows go beyond a series of linear steps though. They can be defined dynamically, and they can spawn agents or other Workflows. This example shows a Workflow that reviews new data from the past day. The Workflow has full control over when and how the agent is prompted, and can pass along context between steps: 

Once you see this pattern, and are “Workflow-pilled” as Cloudflare is, you start to ask: what else could I have a Workflow handle for me? What other human-bottlenecked steps could I delegate to this combination of Workflow + Flue agents?

The full ADLC, on the Cloudflare stack

With Workflows able to orchestrate complex steps, and Artifacts as the storage layer for code, when you look at the SDLC stages, everything an agent needs to own the whole process of building, shipping, and maintaining software is on Cloudflare:

Primitives to build your software factory

Right now, the people on the bleeding edge are building the software factories of the future. Eventually software factories will become, just like agents and AI, the normal way people build software. But for most people and most organizations, we’re not there yet.

We want to change that.

In order to do so, the questions we’ve asked ourselves are: how can we make things simple and accessible so that everyone on the Internet can benefit from a paradigm shift like this? And what are the base layer primitives that we can open up to everyone, from the smallest startup to the largest platforms in the world?

In this case, we think the primitives are here. There’s more to do to connect them, to keep building our own software factory and learn from it, but right now, today, we’re ready for you to build your machine that builds the machine, on Cloudflare. Get started with @cloudflare/ci, build an agent, and see how much of the SDLC you can make autonomous.

Welcome to Agents Week

Post Syndicated from Rita Kozlov original https://blog.cloudflare.com/agents-week-welcome/

This week is Agents Week.

As we started thinking about and planning the week, we wrestled with a broader question of what it means to support this new era of agents and what a purpose-built foundation for agents actually looks like.  Which brought us to a simpler framing: what is an Agent Cloud? 

We quickly realized however, that our framing was wrong. Not because it’s the wrong question to ask, but because of who we were asking — ourselves, instead of our agents. It’s no longer about us and what we think, but about what agents need. 

That, in a nutshell, is what Agents Week is about. 

The cloud we have today, and the web it sits on, were built for people. Every layer assumes a human is watching: pages designed to hold your attention, dashboards to click through, interfaces tuned for how we read and decide. But agents don't work that way. They don't get distracted, tired or fatigued…  and they have their own needs around speed, structure, and access.

An Agent Cloud has to do two things at once. It has to set us up for an agent-native future, where the primitives are built for agents from the ground up rather than retrofitted from human tools. And realistically, it has to meet us where we are today, acting as a translation layer between the human-shaped web that exists now and the agent-shaped one we're moving toward.

That's the throughline for the next five days: the shape of a cloud built for agents and humans and how they interact. The week will explore the theme through what that means for the primitives and execution layer you need, the updated agentic software development lifecycle, how organizations can securely enable employees and agents to interact with safe controls, how this shapes the agentic web, and finally, grounding all of it in the reality of agents and humans today.

Going back to the question: what does your agent need from an Agent Cloud? Well, rather than copy and pasting responses we got from our agents, we encourage you to ask your own agent that, and share any interesting insights and responses you get. Here’s an example prompt for you to use, but we encourage you to explore answers of your own:

What do you, as an agent, need from an agent cloud? Imagine things across the categories of a storage & compute cloud and the execution and storage primitives you need, your dev lifecycle (adlc – like sdlc but with humans taken out of the loop), secure access to systems of record within an organization to get deep work done, and the web (discovery, access, payments…).

Let us know what your agent says by replying here, we’d love to see the responses! 

Follow along on the blog this week for the latest innovations around Agents, and reach out on X to join in the conversation.

Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform

Post Syndicated from Simona Badoiu original https://blog.cloudflare.com/cdnjs-dev-platform-migration/

As of June 23, 2026, cdnjs, one of the Internet's busiest open-source CDNs, is running exclusively on Cloudflare’s Developer Platform. Along the way, cdnjs surfaced limits in the platform, and the platform grew to meet them.

cdnjs is a free, open-source content delivery network for JavaScript and CSS libraries. Instead of using a bundler or self-hosting jQuery, Bootstrap, or Lodash, you drop a <script> tag pointing to cdnjs.cloudflare.com and the library loads from Cloudflare's edge, instantly, anywhere in the world, with no signup, no API keys, and no rate limits. It's the infrastructure behind a significant portion of “intro to JavaScript” tutorials, CodePen demos, and Stack Overflow answers.

Community-driven, cdnjs is used on roughly 12% of all websites, a 48.3% share of the JavaScript CDN market. It serves an average of 108,000 requests per second, 9 billion per day, across more than 330 Cloudflare data centers, with a 98.6% cache hit rate. Pretty cool, Internet!

In 2011, when bundlers were exotic, npm was barely a year old, and "just drop a <script> tag" was how the web shipped JavaScript, Ryan Kirkman and Thomas Davis built cdnjs as a free, community-run mirror of every popular open-source library. 

Cloudflare stepped in to host it free of charge months later, and took over project maintenance in 2019. Back then, Cloudflare didn't have a mature Developer Platform that could fully sustain the entire cdnjs ecosystem. Fifteen years and a lot of building blocks later, the platform is mature enough to run cdnjs end to end, on Workers, Workflows, D1, Queues, Workers Cache, R2, KV, and Containers.

Why cdnjs has 9 billion requests a day 

The web has changed beyond recognition from those days. We have ES Modules (ESM), the standardized import / export syntax browsers understand natively. We have import maps, Vite, Bun, Turbopack. We have AI assistants that scaffold entire apps in seconds. Bundlers are everywhere. So why does a CDN for <script> tags still serve 9 billion requests a day?

One reason: LLMs love cdnjs. When ChatGPT, Claude, or Cursor scaffold a quick HTML demo, they reach for cdnjs because their training data is full of it. There have been 15 years of blog posts, GitHub READMEs, tutorial sites, and Q&A threads pointing to cdnjs.cloudflare.com. The URL pattern is consistent and versions are immutable — exactly the kind of dependency a model can produce reliably without hallucinating.

Every file on cdnjs has an SRI hash (we're still working on ensuring all the existing stored hashes match reality due to bugs in the old system), mirrors are auditable, and the whole project is open source. In a world increasingly worried about supply-chain attacks, an immutable, hash-verified mirror of well-known libraries is indispensable.

And it's free, forever, for everyone. No API keys. No rate limits. No "sign up to continue." That's a rare thing on today's Internet, and it's worth protecting.

Why we migrated

We didn't migrate because cdnjs was slow. We migrated because we want to keep improving it.

The previous architecture served users well: 98% cache hit, billions of requests, no outages. But internally, shipping anything new or fixing existing issues in how packages were processed was getting harder. Making a change meant coordinating deployments across GCP Functions, a VM, and Cloudflare. Observability was painful too.

The pain points  

In 2020, we migrated cdnjs to serverless, moving file serving onto Cloudflare Workers and KV, with a bare-metal origin as fallback. That change dramatically improved resilience and scalability, and let us pre-compress every asset with Brotli and gzip for smaller, faster responses, but only on the serving side.

The publishing side — the pipeline that watches npm and GitHub for new library versions, downloads them, processes them, and writes the results so cdnjs can serve them — stayed on Google Cloud Platform (GCP). At the time, Cloudflare Workers were designed for fast, short-lived HTTP requests; they didn't yet have the building blocks for a long-running, multi-step pipeline that fetches large tarballs, runs CPU-heavy compression, and orchestrates work over hours. Workflows, Queues, Durable Objects, R2, and Containers didn't exist yet.

So we built the publishing bot on what was available: a chain of GCP Functions, a VM running git-sync, and a GitHub repository as the source of truth. It worked, but six years later, that architecture was showing its age. Here's a diagram of the previous architecture:

 

The architecture had five pain points. The one that hurt most was observability: debugging meant stitching logs together by hand. We'll start there.

  1. No shared trace
    A single package update could pass through Cloud Functions, Google Cloud Storage (GCS) object events, Pub/Sub topics, a git-sync VM, and Workers KV before a file reached a user. None of those systems shared a correlation ID. GCP Logging held one half of the story, Cloudflare Logpush held the other, and the two had no common key to join on.

    The problem wasn't outright failure, it was partial success. A version that processed cleanly, wrote to KV, and then silently failed to land in the GitHub repo would serve fine for weeks until someone noticed the two stores had diverged. There was no alert for that. There couldn't be, because nothing in the system knew the full pipeline state.

  2. Split-brain storage
    Files lived in two places at once: Workers KV at the edge (with a bare-metal origin as fallback) and a GitHub repository as the source of truth. The ingestion pipeline wrote to both at the end of every run. Neither was authoritative, and when they drifted, there was no clean way to reconcile them.
  3. Pipeline glued together with object events
    The ingestion pipeline was a chain of small GCP Cloud Functions, each doing one step and handing off to the next through shared storage. One function fetched the package's release archive from npm and dropped it in a bucket. The bucket firing a "new file" event triggered the next function, which unpacked it and wrote the results somewhere else, triggering the next, and so on. Storage was doing double duty as a message queue, with no dead-letter queue, no backlog visibility, and no clean replay when a step failed.
  4. 26 functions for 26 letters
    Just checking npm for updates required 26 Cloud Functions, one per letter of the alphabet. Each shard had its own deployment and its own logs, and the only way to know if the fleet was healthy was to check all 26.
  5. The GitHub repo GitHub couldn't serve
    A separate VM ran git-sync, mirroring every processed file into cdnjs/cdnjs. Years of releases pushed it past 1.1TB of packed storage, large enough that GitHub's own archive service refused to generate tarballs or zip downloads for it. Forking became impractical, clones were slow, and the .gitignore had grown to 274 hand-curated entries blocking broken or weirdly-versioned releases. It was a documented graveyard of everything the pipeline couldn't reasonably reject upstream.

    A genuine thank you to the GitHub team for hosting this giant for over a decade. They bore with us through years of storage growth, and the project wouldn't have survived without them.

    A quieter benefit that came with the migration is having fewer moving parts to secure. Cloud Functions, a git-sync VM, container images, GCS buckets, service-account keys — every one of those was a thing to secure, patch, and audit. Retiring the pipeline closed all of the recently opened cdnjs vulnerabilities.

How we re-built it

The new cdnjs architecture runs entirely on Cloudflare’s Developer Platform.

R2 is the single source of truth for file content. It has no practical size limit, so the files that couldn't fit in KV before, like source maps, big bundles, and font packs, now live alongside everything else. As a bonus, the S3 API makes the entire cdnjs catalog accessible to any S3 client. Maintain a mirror? Open an issue on the cdnjs repository and we'll set you up with read-only credentials.

KV stores only metadata now: package info, version lists, SRI hashes. KV is built for high read volume with infrequent writes, which is exactly the shape of metadata access.

In front of the Worker sits Workers Cache, a tiered cache Cloudflare launched this year. Before, we relied on a separate internal caching layer between the edge and the Worker. That layer is gone now, replaced by one owned by the Developer Platform, the same platform that runs the rest of cdnjs. One less moving part!

The new architecture also extends a long-standing partnership. DigitalOcean has hosted the cdnjs website for years as a sponsor; now it hosts the storage too. Every file published to R2 is mirrored to DigitalOcean Spaces: architecturally a disaster-recovery copy, operationally also a live fallback. The serving worker reads through to it whenever R2 can’t return a file. The chain is cache → R2 → DigitalOcean, so R2 having a bad day doesn't take cdnjs down. A Cloudflare-hosted origin still sits in the chain during the transition, but it will retire once the GitHub backfill lands in R2.

The ingestion pipeline is built on Cloudflare Workflows. Every ten minutes, a cron job triggers PackageUpdatesWorkflow, which checks npm and GitHub for new versions. For each new version found, it spawns a DownloadPackageWorkflow that fetches the tarball into R2, then a ProcessingWorkflow per file that extracts, minifies, and compresses. Finally, PublishingWorkflow writes the results to R2 and KV and updates the Algolia search index.

Because Workflows provides durable execution, the state of each step is preserved. If anything fails — a network timeout, a compression error — the workflow resumes from the last successful step.

The trickier piece is how we glue Workflows to the external compression container. We pre-compress text-based files to streamline the delivery process. But compression is too CPU-intensive for a Worker, so we hand it off to Cloudflare Containers, wait for compression to complete, and then pick up where we left off.

The pipeline has two kinds of waiting:

Per file: Each ProcessingWorkflow writes the uncompressed file to an R2 bucket, sends a job to a Queue, and hibernates. A Rust compression service running in the container picks it up, compresses it, and writes the result to another bucket. An R2 event notification wakes the workflow up so it can continue.

Per package: The parent workflow needs to wait for all its file children before moving on to publish. A package with thousands of files means thousands of children running in parallel. We use a small Durable Object as a counter: a parent increments on each child it spawns, children decrement when they finish. The parent wakes up when the counter reaches zero.

An overview of the new architecture, with R2 as the source of truth and Workflows running the pipeline:

Pushing the limits

Designing the new architecture was one challenge. Migrating the existing catalog into it, without disturbing a single file already in the wild, was another.

We'd actually tried this once before and had to roll back. The plan, back then, was to re-process old packages and write the results directly to R2, but the regenerated files didn't byte-match what KV had been serving. Minifiers and compressors aren't fully deterministic across versions, so the new outputs were correct but had different SRI hashes. For a CDN where users pin those hashes in their HTML, that's a serving break. So we rolled back, and now, we migrated the existing content from KV to R2 as-is instead of regenerating it.

That decision shifted the problem from "re-process millions of files" to "copy millions of files between accounts, without missing any." And that's where we ran into the Workers subrequest limit, capped at 1,000 per invocation on paid plans. A package with thousands of files would burn through it in one go. Parallelizing didn't help, since every Worker hits the same ceiling. So we sharded the migration by package name and fanned the work out across many invocations via Queues, whose at-least-once delivery guarantee meant no package could silently fall out of the migration.

We hit two platform limits during the migration: 1,000 subrequests per Worker invocation and 1,024 steps per Workflow. Instead of just working around them, we asked the Workers and Workflows teams to raise them — which they did. Subrequests now go up to 10 million on paid plans; Workflows now default to 10,000 steps, configurable to 25,000.

The cdnjs pipeline runs on the same building blocks anyone can use: Workers, Workflows, R2, KV, Queues, Containers, and Durable Objects. The limits we hit are limits we lifted for everyone. If the Cloudflare Developer Platform can serve 9 billion requests a day and publish packages with hundreds of thousands of compressed, minified files, it can probably run whatever you're building.

What’s next

There's an obvious next question hiding in all of this: could cdnjs also serve modern, browser-native ES modules? The same packages, transformed on publish, ready to import without a bundler. The architecture doesn't rule it out. The Workflows-plus-Containers pattern that pre-compresses files today would work just as well for transforming them. We're not committing to it, but it's the kind of thing that's now possible to consider, which wasn't true a year ago.

git commit -m "with love" --author="cdnjs team"

We follow every open issue on GitHub and we want your feedback. Don't hesitate to contribute and help make the Internet better for everyone.

R2 is now Generally Available

Post Syndicated from Aly Cabral original https://blog.cloudflare.com/r2-ga/

R2 gives developers object storage, without the egress fees. Before R2, cloud providers taught us to expect a data transfer tax every time we actually used the data we stored with them. Who stores data with the goal of never reading it? No one. Yet, every time you read data, the egress tax is applied. R2 gives developers the ability to access data freely, breaking the ecosystem lock-in that has long tied the hands of application builders.

In May 2022, we launched R2 into open beta. In just four short months we’ve been overwhelmed with over 12k developers (and rapidly growing) getting started with R2. Those developers came to us with a wide range of use cases from podcast applications to video platforms to ecommerce websites, and users like Vecteezy who was spending six figures in egress fees. We’ve learned quickly, gotten great feedback, and today we’re excited to announce R2 is now generally available.

We wouldn’t ask you to bet on tech we weren’t willing to bet on ourselves. While in open beta, we spent time moving our own products to R2. One such example, Cloudflare Images, proudly serving thousands of customers in production, is now powered by R2.

What can you expect from R2?

S3 Compatibility

R2 gives developers a familiar interface for object storage, the S3 API. With S3 Compatibility, you can easily migrate your applications and start taking advantage of what R2 has to offer right out of the gate.

Let’s take a look at some basic data operations in javascript. To try this out on your own, you’ll need to generate an Access Key.

Regardless of the language, the S3 API offers familiarity. We have examples in Go, Java, PHP, and Ruby.

Region: Automatic

We don’t want to live in a world where developers are spending time looking into a crystal ball and predicting where application traffic might come from. Choosing a region as the first step in application development forces optimization decisions long before the first users show up.

While S3 compatibility requires you to specify a region, the only region we support is ‘auto’. Today, R2 automatically selects a bucket location in the closest available region to the create bucket request. If I create a bucket from my home in Austin, that bucket will live in the closest available R2 region to Austin.

In the future, R2 will use data access patterns to automatically optimize where data is stored for the best user experience.

Cloudflare Workers Integration

The Workers platform offers developers powerful compute across Cloudflare’s network. When you deploy on Workers, your code is deployed to Cloudflare’s more than 275 locations across the globe, automatically. When paired with R2, Workers allows developers to add custom logic around their data without any performance overhead. Workers is built on isolates and not containers, and as a result you don’t have to deal with lengthy cold starts.

Let’s try creating a simple REST API for an R2 bucket! First, create your bucket and then add an R2 binding to your worker.

Through this Workers API, we can add all sorts of useful logic to the hot path of a R2 request.

Presigned URLs

Sometimes you’ll want to give your users permissions to specific objects in R2 without requiring them to jump through hoops. Through pre-signed URLs you can delegate your permissions to your users for any unique combination of object and action. Mint a pre-signed URL to let a user upload a file or share a file without giving access to the entire bucket.

Presigned URLs make it easy for developers to build applications that let end users safely access R2 directly.

Public buckets

Enabling public access for a R2 bucket allows you to expose that bucket to unauthenticated requests. While doing so on its own is of limited use, when those buckets are linked to a domain under your account on Cloudflare you can enable other Cloudflare features such as Access, Cache and bot management seamlessly on top of your data in R2.

Bottom line: public buckets help to bridge the gap between domain oriented Cloudflare features and the buckets you have in R2.

Transparent Pricing

R2 will never charge for egress. The pricing model depends on three factors alone: storage volume, Class A operations (writes, lists) and Class B operations (reads).

  • Storage is priced at $0.015 / GB, per month.
  • Class A operations cost $4.50 / million.
  • Class B operations cost $0.36 / million.

But before you’re ready to start paying for R2, we allow you to get up and running at absolutely no cost. The included usage is as follows:

  • 10 GB-months of stored data
  • 1,000,000 Class A operations, per month
  • 10,000,000 Class B operations, per month

What’s next?

Making R2 generally available is just the beginning of our object storage journey. We’re excited to share what we plan to build next.

Object Lifecycles

In the future R2 will allow developers to set policies on objects. For example, setting a policy that deletes an object 60 days after it was last accessed. Object Lifecycles pushes object management down to the object store.

Jurisdictional Restrictions

While we don’t have plans to support regions explicitly, we know that data locality is important for a good deal of compliance use cases. Jurisdictional restrictions will allow developers to set a jurisdiction like the ‘EU’ that would prevent data from leaving the jurisdiction.

Live Migration without Downtime

For large datasets, migrations are live and ongoing, as it takes time to move data over. Cache reserve is an easy way to quickly migrate your assets into a managed R2 instance to reduce your egress costs at the touch of a button. In the future, we'll be extending this mechanism so that you can migrate any of your existing S3 object storage buckets to R2.

We invite everyone to sign up and get started with R2 today. Join the growing community of developers building on Cloudflare. If you have any feedback or questions, find us on our Discord server here! We can’t wait to see what you build.

Watch on Cloudflare TV