cloudflare·Apr 16, 2026·3 min readCurated summary

Cloudflare’s AI Platform: an inference layer designed for agents

Cloudflare is positioning AI Gateway as a unified inference layer for agentic applications. It provides one API for models from multiple providers, centralized cost and reliability controls, and low-latency access through Cloudflare’s global network. The platform is also expanding toward customer-hosted models and multimodal inference, reducing dependence on any single AI vendor. ### A Unified Model Catalog and Endpoint - Developers can call Cloudflare-hosted and third-party models through the same `env.AI.run()` interface. - Switching models, such as from Workers AI to Anthropic or OpenAI, requires only a one-line change. - Cloudflare plans to add REST API support for applications that do not run on Workers. - The catalog includes more than 70 models from over 12 providers, spanning: - Text and reasoning models - Image, video, and speech models - Open-source models hosted on Workers AI - Proprietary models from major providers - Users pay through one credit system rather than managing separate provider accounts. ### Centralized Cost and Usage Management - AI Gateway gives companies a consolidated view of spending across providers. - Request metadata can categorize costs by: - Team - User - Customer - Workflow - Free versus paid usage - This is particularly useful for agents, which may make many model calls for a single user request. ### Bringing Custom Models to Workers AI - Cloudflare is working on allowing customers to deploy fine-tuned or specialized models through Workers AI. - The deployment workflow uses Replicate’s Cog technology to package models and manage: - Python dependencies - CUDA requirements - Model weights - Runtime configuration - Developers define the environment in `cog.yaml` and implement model setup and inference in `predict.py`. - After building the Cog container, Cloudflare can deploy and serve it through existing Workers AI APIs. - Planned improvements include customer-facing APIs, Wrangler commands, and GPU snapshotting to reduce cold-start times. ### Optimizing Agent Responsiveness - For live agents, time to first token can matter more than total inference time. - A small reduction in startup latency can make an agent feel significantly more responsive, even if the full answer still takes several seconds. - Cloudflare’s presence in 330 cities places gateways close to users and inference endpoints, reducing network delay before streaming begins. - Workers AI is adding agent-focused open-source models, including Kimi K2.5 and real-time voice models. Cloudflare’s direction is to make model selection, deployment, monitoring, and failover easier through a single infrastructure layer. For teams building agents, the platform offers a way to mix providers and custom models while controlling cost, latency, and operational complexity.

Read original(opens in new tab)

CloudflarePythonApi IntegrationAi Gateway+4

cloudflare·Apr 16, 2026·3 min readCurated summary

Building the foundation for running extra-large language models

Cloudflare is building infrastructure for serving extra-large open-source language models efficiently, especially for agentic applications with long prompts and frequent tool calls. Its approach combines specialized hardware configurations, prefill/decode disaggregation, prompt caching, distributed KV-cache management, and speculative decoding. These optimizations substantially improve latency, throughput, and cost efficiency without requiring more GPUs. ## Hardware Configurations for Agent Workloads - Different applications stress models differently: - Content generation sends fewer input tokens but produces many output tokens. - Summarization sends very large inputs and generates relatively short outputs. - Agent workloads typically involve: - Large system prompts - Tool and MCP definitions - Accumulated conversation history - Generated code and previous interactions - Workers AI therefore prioritizes fast input processing and tool-calling performance. ## Prefill-Decode Disaggregation - LLM inference has two stages: - **Prefill:** Processes input tokens and populates the KV cache; generally compute-bound. - **Decode:** Generates output tokens; generally memory-bound. - Running both stages on one server can underutilize GPUs because they stress different resources. - Cloudflare separates them across dedicated inference servers: - A prefill server processes the request and stores its KV cache. - A decode server retrieves the cache and generates the response. - This enables independent tuning, scaling for input- or output-heavy traffic, and use of heterogeneous hardware. - The architecture requires a sophisticated load balancer that: - Transfers KV-cache metadata between stages. - Rewrites streaming SSE responses. - Handles different inference-server protocols. - Balances traffic based on estimated in-flight prefill and decode tokens. - After adopting this design, Cloudflare saw: - Lower p90 time to first token and reduced tail-latency variance. - Intertoken latency fall from roughly 100 ms to 20–30 ms. - About a threefold improvement while using the same number of GPUs. ## Prompt Caching and Session Affinity - Long agent conversations repeatedly reuse the same context, making prompt caching essential. - The `x-session-affinity` header routes requests toward regions containing previously computed input tensors. - Cloudflare added support for this header to agent harnesses such as OpenCode. - Cached prompts improve: - Overall throughput - Interactive response times - Pricing, with discounted cached tokens - GPU efficiency - Adoption by heavy internal users increased peak input-token cache hit rates from 60% to 80%. ## Distributed KV-Cache Optimization - Larger models span multiple GPUs, requiring KV caches to be shared across devices and nodes. - For Kimi, Cloudflare uses Moonshot AI’s: - **Mooncake Transfer Engine** for high-speed memory transfers using RDMA technologies such as NVLink and NVMe over Fabric. - **Mooncake Store** to extend cache storage beyond GPU VRAM onto NVMe. - Combined with LMCache or SGLang HiCache, the system can: - Reuse cached prompts from any node in a cluster. - Reduce reliance on session-aware routing. - Balance traffic more evenly. - Keep sessions cached longer. - Increase cache hit rates and supported throughput. ## Speculative Decoding - The post begins introducing speculative decoding as another optimization. - It describes the basic LLM process of predicting successive tokens, but the provided text ends before explaining the technique or its results. Cloudflare’s overall strategy is to match infrastructure to real usage patterns rather than rely on a single hardware configuration. Separating inference stages, maximizing cache reuse, and distributing KV caches are practical ways to make large-model hosting faster and more economical.

Read original(opens in new tab)

Large Language ModelsCloudflareGpu OptimizationPrompt Caching+4

cloudflare·Apr 16, 2026·3 min readCurated summary

AI Search: the search primitive for your agents

AI Search is presented as a general-purpose search primitive for AI agents, handling retrieval across code, support documentation, customer history, and agent memory. It combines semantic and keyword search while providing built-in storage, indexing, and dynamically creatable search instances. The result is less infrastructure to build and the ability to maintain separate searchable contexts for agents, customers, languages, or other tenants. ## Why Agents Need Search - Agents often need access to information too large or dynamic to fit in a context window. - Common examples include: - Coding agents searching millions of repository files. - Support agents searching product documentation and ticket history. - Memory systems retrieving relevant past interactions. - Building this independently requires: - A vector index. - Document parsing and chunking. - An indexing pipeline that stays synchronized with changing data. - A separate keyword index and result-fusion layer if lexical search is also needed. ## Hybrid Search - AI Search runs vector search and BM25 keyword search in parallel. - Results are fused into a single ranking. - This supports both: - Semantic matches based on meaning. - Exact-term matches for names, identifiers, and technical terminology. - The blog’s own search is powered by AI Search. ## Built-In Storage and Dynamic Namespaces - New AI Search instances include managed storage and a vector index. - Files can be uploaded directly through an API and indexed automatically. - Developers do not need to configure R2 buckets or external data sources for every instance. - The `ai_search_namespaces` binding allows Workers to create and delete instances at runtime. - Instances can be created per: - Agent. - Customer. - Language. - Other isolated contexts. - Documents can include metadata used to boost rankings at query time. - A single query can search across multiple instances. ## Customer Support Agent Example - The example uses the Cloudflare Agents SDK and Workers AI. - A shared `product-knowledge` instance contains product documentation backed by an R2 bucket. - Each customer receives a separate instance such as `customer-abc123`. - After an issue is resolved, the agent stores a summary of the problem and its fix. - Over time, each customer’s instance becomes a searchable history of previous resolutions. ## Agent Tools and Retrieval Flow - The support agent extends `AIChatAgent` and uses Kimi K2.5 through Workers AI. - It defines tools for: - Searching shared product documentation and the current customer’s history in one call. - Saving a resolution after an issue is resolved. - The model decides when to invoke these tools based on the conversation. - Search results can prioritize recent documents using metadata, such as a descending `timestamp` boost. - The Agents SDK persists the conversation history across reconnects, while AI Search provides retrieval over larger knowledge collections. AI Search is recommended for teams that want agent-ready retrieval without separately assembling vector databases, keyword indexes, storage, and synchronization pipelines. Its dynamically isolated instances are particularly useful for multi-tenant agents and applications that need both shared knowledge and private, continuously growing context.

Read original(opens in new tab)

Database DesignCloudflareVector DbAgents Sdk+4

cloudflare·Apr 16, 2026·2 min readCurated summary

Deploy Postgres and MySQL databases with PlanetScale + Workers

Cloudflare and PlanetScale are integrating more closely so developers can create and manage PlanetScale Postgres and MySQL databases from the Cloudflare dashboard and API. The integration connects these databases to Workers through Hyperdrive, providing connection pooling, query caching, and simplified configuration. Cloudflare billing for new PlanetScale databases is planned for next month, while existing setups remain billed through PlanetScale. ## Postgres and MySQL for Workers - Developers can use either PlanetScale Postgres or Vitess-based MySQL for Worker applications. - Postgres supports a broad ecosystem of tools and extensions such as `pgvector` for AI-oriented vector search. - After connecting a PlanetScale account, users can create databases from the Cloudflare dashboard. - A Hyperdrive binding in `wrangler.jsonc` connects a Worker to the database: ```json { "hyperdrive": [ { "binding": "DATABASE", "id": "<AUTO_CREATED_ID>" } ] } ``` - Workers can then use standard clients such as the Node.js `pg` package and access the connection string through `env.DATABASE`. ## PlanetScale’s Developer Experience - Cloudflare selected PlanetScale for its performance, reliability, and support for both Postgres and MySQL. - PlanetScale features include: - Query insights - Usage and cost breakdowns - Database branching for safer schema and code changes - Agent-assisted SQL performance improvements - Cloudflare users receive the standard PlanetScale experience and pricing, including all available features. - PlanetScale Postgres starts at $5 per month for a single node. ## Reducing Latency with Workers Placement - Workers normally execute close to the incoming user request, which can increase latency when accessing a centralized database. - Developers can configure explicit placement so the Worker runs near the database’s primary region: ```json { "placement": { "region": "aws:us-east-1" } } ``` - Cloudflare plans to automatically determine placement based on the PlanetScale database location, potentially reducing database access latency to single-digit milliseconds. ## Billing and Availability - PlanetScale databases can already be created or connected through the Cloudflare dashboard. - Until the billing integration launches, databases continue to be billed through PlanetScale. - Starting next month, new databases can be billed directly to a Cloudflare self-serve or enterprise account. - Cloudflare credits, startup-program benefits, and committed spend may also apply toward PlanetScale database costs. The integration is intended to give Workers developers a unified platform for globally deployed applications, with flexible SQL storage, optimized database connectivity, and eventually centralized Cloudflare billing.

Read original(opens in new tab)

Database DesignCloudflarePostgreSQLMysql+3

cloudflare·Apr 16, 2026·3 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Read original(opens in new tab)

Database DesignTypeScriptCloudflare WorkersGit+4

cloudflare·Apr 16, 2026·3 min readCurated summary

Cloudflare Email Service: now in public beta. Ready for your agents

Cloudflare Email Service is entering public beta as infrastructure for applications and AI agents that use email as a primary interface. It combines inbound Email Routing with outbound Email Sending, allowing agents to receive messages, perform asynchronous work, and reply without relying on separate email providers. Cloudflare argues this enables agents to move beyond instant chatbot responses and operate independently across support, billing, verification, and multi-agent workflows. ## Email as an Agent Interface - Email is universally available and requires no custom chat application or channel-specific SDK. - Developers already depend on email for: - Account signups - Notifications - Invoices - Customer support - Verification workflows - Agents increasingly need email to communicate with users and other systems. ## Cloudflare Email Service - **Email Routing** lets applications and agents receive email. - **Email Sending** enables replies and outbound notifications. - The service integrates with Workers and the Agents SDK. - The public-beta toolkit includes: - An Email Sending binding - An Email MCP server - Wrangler CLI email commands - Skills for coding agents - An open-source agentic inbox reference application ## Email Sending in Public Beta - Workers can send transactional email through a native `env.EMAIL` binding. - The binding requires no API keys or secret management inside the Worker. - Applications can also send email through a REST API or TypeScript, Python, and Go SDKs. - Cloudflare automatically configures SPF, DKIM, and DMARC when a domain is added, improving authentication and inbox delivery. - Since the service runs on Cloudflare’s global network, it is designed for low-latency delivery worldwide. - Combined with long-standing Email Routing, developers can receive, process, and send email within one platform. ## Email-Native Agents with the Agents SDK - The Agents SDK already provides an `onEmail` hook for processing inbound messages. - Previously, agents were limited to synchronous replies or messages sent to Cloudflare account members. - Email Sending removes those limitations, allowing agents to: - Process requests for extended periods - Query multiple systems - Schedule follow-ups - Escalate unusual cases - Reply asynchronously after completing work - This turns an agent from a simple chatbot into a system capable of acting independently. ## Support-Agent Workflow - The example `SupportAgent`: - Receives email through `routeAgentEmail` - Parses the raw message with `PostalMime` - Stores ticket details such as sender, subject, body, and message ID in agent state - Starts longer-running work or sends a task to a Queue - Replies using the Email Sending binding - Preserves the conversation with `inReplyTo` and a `Re:` subject - Address-based routing maps addresses such as `support@domain` or `sales@domain` to corresponding agent instances. Cloudflare’s recommendation is to use Email Service when an agent must communicate reliably with people over email, especially for workflows that require persistence, background processing, and delayed or follow-up responses.

Read original(opens in new tab)

TypeScriptPythonGoRest Api+4

cloudflare·Apr 15, 2026·2 min readCurated summary

Register domains wherever you build: Cloudflare Registrar API now in beta

Cloudflare has launched its Registrar API in beta, allowing domains to be searched, checked, and registered programmatically. The API is designed for AI agents, editors, deployment pipelines, and other automated workflows, closing the gap between developing an idea and securing its domain. Its three-step process uses cached search results, authoritative availability checks, and streamlined registration with account defaults. ## Built for Agents and Automation - Supports domain registration directly from code editors, terminals, backend services, and deployment pipelines. - Enables agents to: - Generate domain name ideas - Search candidate names - Confirm availability and pricing - Register a selected domain after user approval - Registration responses can complete immediately or provide a status endpoint for polling. - The API is available through Cloudflare’s existing API and MCP integration, so tools such as Cursor, Claude Code, and other MCP-compatible environments require no separate custom integration. ## Search, Check, and Register - **Search:** Finds candidate domains, optionally across extensions, and returns registrability, tier, currency, registration cost, and renewal cost. - **Check:** Queries the registry directly for current availability and pricing. - **Register:** Completes the purchase using a minimal request containing the domain name. Cloudflare recommends checking availability immediately before registration because search results are cached and popular names can become unavailable within seconds. ## Registration Defaults and Protection - The only required registration field is the domain name. - The account’s default registrant contact and payment method are used automatically when configured. - Contact details can instead be supplied in the request. - WHOIS privacy is enabled by default at no additional cost. - Registrations include details such as active status, expiration date, auto-renewal, privacy, and domain lock state. - Premium domains may be supported, but require explicit acknowledgement of their fees. ## Initial Availability - The beta initially supports a curated selection of popular top-level domains. - Cloudflare directs users to the Registrar API documentation for the current supported TLD list. The API makes domain acquisition a natural part of automated development workflows: search a name, verify its live price and availability, obtain approval, and register it in seconds without leaving the development environment.

Read original(opens in new tab)

AutomationCloudflare ApiApi DevelopmentDomain Registration+3

cloudflare·Apr 15, 2026·3 min readCurated summary

Project Think: building the next generation of AI agents on Cloudflare

Project Think is Cloudflare’s next-generation Agents SDK for building persistent, scalable AI agents. It combines durable execution, sub-agents, persistent sessions, sandboxed code execution, and runtime-created extensions, while allowing developers to use individual primitives or an integrated Think base class. Its central argument is that agents should run as durable, one-to-one infrastructure rather than ephemeral processes on laptops or permanently running servers. ## Why Agents Need a New Foundation - Coding agents increasingly act as general-purpose assistants by reading context, writing and executing code, observing results, and iterating. - Existing agents are limited by: - Dependence on a laptop or costly VPS - Fixed costs while idle - Manual installation, updates, identity, and secret management - Unlike traditional applications, agents are typically one-to-one: each user, task, or conversation may require a distinct agent. - Supporting millions of concurrent agents with always-on containers would be economically impractical. ## Project Think’s Core Primitives Project Think introduces: - Durable execution through fibers, including checkpointing, crash recovery, and automatic keepalive - Isolated sub-agents with independent SQLite databases and typed RPC - Persistent, searchable sessions with message trees, branching, and compaction - Sandboxed code execution using Dynamic Workers, codemode, and runtime npm resolution - An execution ladder spanning workspaces, isolates, npm packages, browsers, and sandboxes - Self-authored extensions that let agents create tools dynamically ## Long-Running Agents with Durable Objects - Each agent is implemented as a Durable Object with: - A stable identity - Persistent SQLite-backed state - Message-based wake-up - Automatic hibernation when idle - Agents can resume after HTTP requests, WebSocket messages, alarms, or inbound email. - Hibernated agents consume no compute, allowing many more agents than an always-on VM or container model. - Durable Objects provide automatic routing, recovery, and per-agent state without separately managed load balancers, databases, or process supervisors. - For example, 10,000 agents active only 1% of the time require capacity for roughly 100 active agents rather than 10,000 continuously running instances. ## Durable Execution with Fibers - Long LLM calls and multi-step workflows can be interrupted by deployments, restarts, or resource limits. - `runFiber()` makes a function invocation durable by: - Registering it in SQLite before execution - Allowing progress to be checkpointed with `stash()` - Recovering interrupted work through `onFiberRecovered` - Agents can save intermediate findings, resume from the latest checkpoint, and broadcast progress to clients. - The SDK automatically keeps the agent alive while a fiber runs. - `keepAlive()` and `keepAliveWhile()` support active work lasting minutes or longer, such as CI pipelines, design reviews, and video generation. Project Think’s recommendation is to treat agents as persistent, addressable infrastructure: use the low-level primitives for customization, or adopt the Think base class for a faster, integrated starting point.

Read original(opens in new tab)

Database DesignDurable ObjectsSqliteAgents Sdk+4

cloudflare·Apr 15, 2026·3 min readCurated summary

Browser Run: give your agents a browser

Cloudflare is renaming Browser Rendering to Browser Run and positioning it as a full browser platform for AI agents. It provides remotely hosted Chrome sessions that agents can control, observe, debug, record, and scale globally, while allowing humans to intervene when necessary. The update expands access through CDP and MCP, making existing automation tools and AI coding assistants compatible with Cloudflare’s browser infrastructure. ## Browser Run for AI Agents - Agents can navigate websites, read content, fill out forms, extract data, take screenshots, and verify results. - Browser sessions run on Cloudflare’s global network, reducing infrastructure and browser-maintenance requirements. - Sessions can scale dynamically and open near users for lower latency. - The platform now supports up to 120 concurrent browsers, up from 30. ## Observability and Human Intervention - **Live View** shows an agent’s browser session in real time, making it easier to confirm success or diagnose failures. - **Human in the Loop** allows agents to transfer control when they encounter login screens or unusual edge cases. - A human can resolve the issue and return control to the agent. - **Session Recordings** capture DOM changes, interactions, and navigation for debugging and postmortem analysis. ## Browser Control Options Browser Run supports several levels of automation: - Low-level control through the Chrome DevTools Protocol (CDP). - Higher-level automation with Puppeteer and Playwright. - Quick Actions for simpler tasks. - WebMCP for websites that expose agent-discoverable actions. ### Chrome DevTools Protocol - Browser Run now exposes CDP directly through a WebSocket endpoint. - Existing CDP-based frameworks, scripts, and agent tools can connect with minimal changes. - CDP provides capabilities beyond Puppeteer and Playwright, including JavaScript debugging. - Raw protocol messages can be sent directly to models, potentially reducing token usage. - Developers can connect from any language or environment without creating a Cloudflare Worker. - Self-hosted Chrome scripts can be migrated by changing the browser WebSocket URL and adding Cloudflare authentication headers. ### MCP Client Support - MCP clients such as Claude Desktop, Cursor, Codex, and OpenCode can use Browser Run as a remote browser. - Cloudflare supports the `chrome-devtools-mcp` package, which provides browser automation, debugging, and performance-analysis capabilities. - Configuration requires pointing the MCP server to Browser Run’s CDP endpoint and supplying an API token. ### WebMCP - WebMCP is intended to make websites more reliable for AI agents. - Websites can declare actions that agents can discover and call directly. - This addresses the limitations of a web originally designed primarily for human navigation. ## Overall Direction Cloudflare’s update combines hosted browser infrastructure, multiple automation interfaces, real-time visibility, replayable sessions, and human fallback. The goal is to make browser-based agents more dependable in production while avoiding the operational burden of managing Chrome infrastructure themselves. For teams building web-using agents, Browser Run offers a practical path from self-hosted or local browser automation to scalable, observable remote sessions, especially when existing CDP, Puppeteer, Playwright, or MCP tooling is already in use.

Read original(opens in new tab)

AI AgentsCloudflareHuman In The LoopPuppeteer+4

cloudflare·Apr 15, 2026·3 min readCurated summary

Introducing Agent Lee - a new interface to the Cloudflare stack

Agent Lee is Cloudflare’s new in-dashboard AI assistant, designed to replace complex navigation with natural-language interaction across the Cloudflare platform. It can inspect account data, troubleshoot issues, and—when explicitly approved—make changes or deploy resources. Built on Cloudflare’s own infrastructure, it combines sandboxed code execution, permission controls, and generative UI to provide an interactive way to manage real accounts. ## A Natural-Language Interface to Cloudflare - Agent Lee understands account resources such as Workers, zones, DNS settings, and error rates. - Users can ask it to: - Identify the top error messages for a Worker. - Diagnose access problems involving a `www` prefix. - Enable Cloudflare Access for a domain. - Create an R2 bucket and connect it to a Worker. - It can retrieve account-specific context, use the appropriate tools, and present results through charts and other visualizations. - The beta reportedly serves about 18,000 daily users and performs nearly 250,000 tool calls per day across services including DNS, Workers, SSL/TLS, R2, Registrar, Cache, Cloudflare Tunnel, and API Shield. ## Codemode and Sandboxed Execution - Instead of exposing raw MCP tool definitions to the model, Agent Lee uses Codemode. - The model writes TypeScript that calls a generated API, which is intended to improve accuracy and support multi-step operations in a single script. - Generated code runs through a Cloudflare MCP server and a Durable Object acting as a credentialed proxy. - The Durable Object: - Classifies operations as reads or writes by inspecting the method and request body. - Proxies read operations directly. - Blocks write operations until the user explicitly approves them. - Keeps API keys out of generated code and injects credentials server-side. ## MCP Permissions and User Approval - Agent Lee connects to Cloudflare’s MCP server through: - A search tool for querying API endpoints. - An execute tool for running code that performs API requests. - Any operation that changes the account must pass through an elicitation step. - Approval is an enforced permission boundary rather than merely a confirmation-oriented interface feature. - Agent Lee cannot bypass the approval gate before executing writes. ## Built on Cloudflare’s Public Stack - Agent Lee uses the same building blocks available to Cloudflare customers: - Agents SDK - Workers AI - Durable Objects - Cloudflare’s MCP infrastructure - Cloudflare developed and tested the system in production against real accounts. - The company positions this approach as a way to identify platform limitations and validate patterns that other developers can reuse. ## Generative UI - Agent Lee supplements text responses with dynamically generated interface components. - Questions about traffic can produce interactive line charts rather than plain numerical summaries. - An adaptive grid lets users reserve space for new UI blocks by dragging across the interface and describing what they want. - Supported components include: - Tables - Interactive charts - Architecture maps - Other dynamic visual blocks - The result is intended to turn conversation history into an evolving operational dashboard. ## Quality and Safety - Elicitations are used whenever Agent Lee needs to perform a non-read action, requiring explicit approval in the interface. - Cloudflare also evaluates the system’s: - Conversation success rate - Information accuracy - Because the product remains in beta, users may encounter limitations or edge cases as its reliability and performance continue to improve. Agent Lee’s central promise is to make Cloudflare operations conversational without removing control. Its most important design choice is the combination of broad account awareness with a structural approval gate for changes, while its generative UI makes the resulting information and workflows more actionable.

Read original(opens in new tab)

Database DesignCloudflareUser InterfaceTypeScript+4

cloudflare·Apr 15, 2026·3 min readCurated summary

Add voice to your agent

Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems. ## Voice Support for Existing Agents - `withVoice(Agent)` enables full conversational voice agents. - `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search. - React applications can use `useVoiceAgent` and `useVoiceInput`. - Framework-independent clients can use `VoiceClient`. - Built-in Workers AI providers include: - Deepgram Flux for continuous speech-to-text - Deepgram Nova 3 for speech-to-text - Deepgram Aura for text-to-speech - Developers can get started without external API keys. ## Minimal Server and Client Setup - A voice agent extends a class created with `withVoice(Agent)`. - The server configures a transcriber and TTS provider, then implements `onTurn()`. - `onTurn()` receives the user’s transcript and returns the agent’s response. - React clients can display: - Connection status - Interim and finalized transcripts - Conversation messages - Start, end, and mute controls - Non-React applications can connect through `@cloudflare/voice/client`. ## How the Voice Pipeline Works - The browser captures 16 kHz mono PCM microphone audio. - Audio streams over the agent’s existing WebSocket connection. - A continuous STT session remains active for the duration of the call. - The speech-to-text model detects completed utterances and produces stable transcripts. - Each transcript is passed to `onTurn()` for application or LLM logic. - The response is synthesized into audio and streamed back to the client. - Streamed responses can be sentence-chunked so audio begins playing before the full response is complete. - User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments. ## Extensible Provider Architecture - The package is designed not to lock developers into one fixed voice stack. - Small provider interfaces allow speech, telephony, and transport providers to build integrations. - Developers can mix and match components based on their application’s requirements. - Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture. Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.

Read original(opens in new tab)

Database DesignReactSqliteSpeech To Text+3

cloudflare·Apr 15, 2026·3 min readCurated summary

Rearchitecting the Workflows control plane for the agentic era

Workflows was originally designed for human-paced events, but autonomous agents now create and manage workflow instances at machine speed. To support this shift, the platform increased its limits substantially and redesigned its control plane for horizontal scalability. The new architecture replaces V1’s account-level bottleneck with distributed components while preserving durable execution, retries, and human-in-the-loop pauses. ## The Shift to Agent-Driven Workloads - Workflows initially handled events such as sign-ups and purchases, typically requiring only one instance per person. - Persistent agents can operate for hours or days and launch dozens of workflows from a single session. - Concurrent agents can create thousands of workflow instances within seconds. - Workflows also serve as durable execution harnesses for agent loops, maintaining progress across failures and supporting asynchronous work. ## Higher Workflows Capacity The platform now supports: - **50,000 concurrent instances**, up from 4,500. - **300 instance creations per second per account**, up from 100. - **2 million queued instances per workflow**, up from 1 million. These increases were driven by observed usage patterns and a redesign of the control plane. ## V1: A Single Account-Level Bottleneck - Each workflow consists of durable, independently retryable steps that can run tasks, wait for events, or sleep until a scheduled time. - SQLite-backed Durable Objects provide execution, coordination, and storage. - An **Engine Durable Object** is created for each workflow instance and handles execution, retries, and sleeping. - A single **Account Durable Object** manages account-wide workflow and instance metadata. - All create, update, and list operations passed through the Account object. - High-volume customers could generate thousands of requests per second as instances started and completed, overwhelming the singleton. - The original rate limits were therefore hard architectural limits rather than adjustable product settings. ## V2: Horizontal Scaling Principles The redesigned control plane is based on several architectural changes: - The instance’s **Engine is now the sole source of truth** for whether that instance exists. - The system verifies that an Engine exists before queuing an instance, avoiding queued instances with no running execution object. - Instance lifecycle and liveness operations are distributed across workflows and regions so they can scale horizontally. - The Account singleton stores only essential metadata and has a bounded maximum number of concurrent requests. - Limits are designed to be flexible and increaseable rather than constrained by one central bottleneck. ## SousChef and Gatekeeper - V2 introduces two central components: **SousChef** and **Gatekeeper**. - SousChef acts as a “second in command” to the Account, taking over work that previously concentrated all workflow and instance management in one Durable Object. - Together, these components are intended to distribute control-plane responsibilities and enable higher creation rates and concurrency. - The migration was performed with live traffic, allowing customers to move to the new architecture without interruption. The redesign aligns Workflows with agentic workloads by moving coordination away from a single account-level Durable Object. Developers running high-volume or highly concurrent agents should benefit from the new limits and a control plane that can continue scaling independently.

Read original(opens in new tab)

Database DesignDurable ObjectsSqliteScalability+3

cloudflare·Apr 14, 2026·3 min readCurated summary

Securing non-human identities: automated revocation, OAuth, and scoped permissions

Cloudflare argues that securing modern infrastructure requires managing non-human identities—agents, scripts, and third-party applications—as carefully as human users. The core model combines principals, credentials, and policies, with protections covering token leakage, OAuth access visibility, and narrowly scoped permissions. The post focuses especially on automated token detection and revocation, designed to limit damage when credentials are exposed. ## Identity as Three Connected Components - **Principal:** The identity acting on a system’s behalf, such as a developer, AI agent, background service, or OAuth application. - **Credential:** The proof of identity, typically an API token. Anyone who obtains it may impersonate the principal. - **Policy:** The permissions assigned to the identity, determining which resources and actions it can access. - Security failures occur when these elements are managed separately—for example, when a valid identity uses a stolen token or has unnecessarily broad permissions. ## Automated Detection and Revocation of Leaked Tokens - API tokens are commonly exposed by accidentally committing them to public repositories. - Cloudflare cites GitGuardian’s estimate that more than 28 million secrets were published to public GitHub repositories in the previous year, with AI-driven development increasing leak rates. - Cloudflare is partnering with credential-scanning providers to detect leaked tokens and revoke them before attackers can exploit them. - New Cloudflare token formats use a recognizable `cf` prefix and a checksum, allowing scanners to identify tokens confidently and verify whether they are authentic. - Existing tokens remain valid, but newly generated tokens use the scannable format. ## GitHub Secret Scanning Integration - GitHub scans public and private repositories for the new Cloudflare token formats on every commit. - For public repository leaks: - GitHub validates the token using its checksum. - GitHub sends Cloudflare a webhook. - Cloudflare automatically revokes the token. - The user receives an email prompting them to create a replacement. - For private repositories, GitHub notifies the customer so the leaked credential can be removed and replaced. ## Protection Through Cloudflare One Cloudflare One customers can use the Credentials and Secrets DLP profile to detect and block Cloudflare tokens across multiple data paths: - **Network traffic:** Cloudflare Gateway can block tokens in uploads, downloads, and outbound requests. - **Email:** Cloudflare Email Security and the DLP Assist add-in can scan Microsoft 365 messages before external delivery. - **Stored data:** Cloudflare CASB scans connected services such as Google Drive, OneDrive, and Dropbox. - **AI traffic:** Cloudflare AI Gateway can inspect prompts and model responses in real time, addressing credential exposure through AI systems. ## Broader Scanner Ecosystem - Cloudflare is working with open-source and commercial credential-scanning tools. - The goal is to protect customers regardless of which repository or secret-scanning products they use. - Automatic revocation is presented as a critical safeguard because credential exposure is treated as inevitable rather than exceptional. Organizations should use recognizable, verifiable tokens, enable repository and DLP scanning, and ensure leaked credentials are revoked automatically. These controls reduce the window in which an exposed token can be used and should be combined with narrowly scoped permissions for agents and applications.

Read original(opens in new tab)

CloudflareOauthApi SecurityData Loss Prevention+4

cloudflare·Apr 14, 2026·3 min readCurated summary

Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP

Cloudflare argues that enterprise MCP adoption requires centralized governance rather than individually managed, locally hosted servers. Its reference architecture combines remote MCP servers, Cloudflare Access, MCP server portals, and AI security controls to improve visibility, authentication, policy enforcement, and performance. The company also introduces Code Mode with MCP server portals to reduce the token and context-window costs of exposing large APIs. ## Centralized Remote MCP Servers - MCP separates the AI application from corporate credentials and APIs: - The MCP client connects to the LLM or agent. - The MCP server mediates access to internal resources. - Cloudflare moved away from locally hosted MCP servers because they: - May use unvetted software and versions. - Increase supply-chain and tool-injection risks. - Are difficult for IT and security teams to administer. - A centralized team manages MCP infrastructure through a shared monorepo platform. - Approved teams can create governed MCP servers from templates, inheriting: - Default-deny write controls. - Audit logging. - Automated CI/CD pipelines. - Secrets management. - Servers are deployed remotely on Cloudflare’s developer platform and custom domains, providing centralized usage visibility and global low-latency access. ## Authentication with Cloudflare Access - Public MCP servers, such as documentation and Radar services, can remain openly accessible. - MCP servers connected to private corporate resources require employee authentication. - Cloudflare Access acts as the OAuth provider and identity layer. - It verifies: - Single sign-on. - Multifactor authentication. - IP address, location, and device-certificate context. - Access issues tokens that authorize users to reach protected resources. ## MCP Server Portals for Discovery and Governance - As the number of MCP servers grew, employees needed a central way to discover authorized services. - Users connect their MCP client to a portal, which exposes the internal and third-party MCP servers they are permitted to use. - Portals provide: - Centralized logging. - Consistent policy enforcement. - Data loss prevention controls. - Access policies for users and tools. - Administrators can restrict both portal access and the specific tools exposed by each server. - Finance users might receive only read-only repository tools. - Engineering users on corporate devices might receive read/write capabilities. - Portals support MCP servers hosted on Cloudflare as well as third-party servers. - Cloudflare emphasizes that the relevant security and networking components can run on the same physical machine in its global network, reducing latency and avoiding unnecessary traffic transit. ## Code Mode Reduces MCP Token Costs - The standard MCP design exposes every API operation as a separate tool. - For large platforms with thousands of endpoints, this exhaustive tool list consumes an agent’s context window and increases token costs. - Cloudflare presents Code Mode with MCP server portals as a way to address this scaling problem. - The provided article excerpt ends while introducing Cloudflare’s earlier use of server-side Code Mode for exposing large numbers of API endpoints. Cloudflare’s approach recommends treating MCP as enterprise infrastructure: centrally deployed, authenticated, discoverable, policy-controlled, and monitored. Organizations adopting MCP at scale should avoid unmanaged local servers and provide reusable platforms that make secure deployment the default.

Read original(opens in new tab)

CI/CDModel Context ProtocolCloudflareAPI Design+4

cloudflare·Apr 14, 2026·3 min readCurated summary

Managed OAuth for Access: make internal apps agent-ready in one click

Cloudflare’s managed OAuth makes internal apps behind Cloudflare Access usable by AI agents without modifying the apps themselves. By exposing standard OAuth discovery and authorization flows, agents can authenticate on behalf of the human user rather than relying on static service accounts. The result is immediate agent compatibility for legacy websites, APIs, and other internal tools. ## The Problem: Access Worked for Humans, Not Agents - Cloudflare protects thousands of internal and self-hosted applications with Cloudflare Access. - Humans can follow Access’s login-page redirect, but agents generally cannot interact with browser-based authentication flows. - Cloudflare initially addressed this internally by modifying OpenCode’s web fetch tool to use `cloudflared` to obtain a JWT and attach it to requests. ## Managed OAuth for Access Applications - Managed OAuth is now available in open beta for every Access application. - Enabling it requires one click and no application code changes. - Access acts as the OAuth authorization server and advertises authentication details through: - The `WWW-Authenticate` response header - `/.well-known/oauth-authorization-server` - OAuth-capable agents can then: - Dynamically register as clients using RFC 7591. - Send the user through a PKCE authorization flow using RFC 7636. - Receive a token representing the user’s authorization. - The same pattern supports web pages, web applications, REST APIs, and MCP servers. ## Making Legacy Internal Apps Agent-Ready - Retrofitting every internal application with APIs, CLIs, MCP servers, and new agent standards is impractical. - Many applications can already provide useful value when agents treat them as ordinary websites. - For example, an internal wiki may only need Markdown-for-Agents support and managed OAuth. - Putting Cloudflare Access in front of existing applications provides immediate agent compatibility without rebuilding them. ## User-Based Authorization Instead of Service Accounts - Static service accounts and tokens can be useful for simple integrations, but they weaken attribution and fine-grained access control. - Actions performed through shared credentials may appear in audit logs as originating from the agent or service account rather than the responsible human. - They can also create confused-deputy risks, where an agent gains authority beyond what its user should have. - OAuth preserves the user–agent relationship: - Tokens are scoped to the user’s identity and permissions. - Existing access policies continue to apply. - Audit logs can attribute actions to the initiating user. ## RFC 9728 and Agent Web Fetching - RFC 9728 standardizes how clients discover OAuth authentication requirements. - MCP has adopted the standard, but Cloudflare argues that general-purpose agents should use it for protected websites and REST APIs as well. - Most agent web-fetch tools currently ignore `WWW-Authenticate` headers and do not automatically: - Locate the OAuth authorization-server metadata. - Register as an OAuth client. - Complete the authorization flow. - Cloudflare has drafted changes to OpenCode’s web-fetch tool demonstrating how tools could check for existing credentials and initiate OAuth when necessary. Cloudflare’s recommendation is to enable managed OAuth for Access-protected applications and encourage agent developers to implement RFC 9728. This offers a practical path to agent adoption while retaining user-level permissions, accountability, and compatibility with existing internal software.

Read original(opens in new tab)

Model Context ProtocolCloudflare AccessJwtOauth 2.0+4