cloudflareApr 16, 2026

AI Search: the search primitive for your agents (opens in new tab)

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.

agents-sdkdatabase-designcloudflarevector-db+4

cloudflareApr 16, 2026

Cloudflare Email Service: now in public beta. Ready for your agents (opens in new tab)

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.

agents-sdktypescriptpythongo+4

cloudflareApr 15, 2026

Project Think: building the next generation of AI agents on Cloudflare (opens in new tab)

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.

agents-sdkdatabase-designdurable-objectssqlite+4

cloudflareApr 15, 2026

Add voice to your agent (opens in new tab)

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.

agents-sdkdatabase-designreactsqlite+3

cloudflareApr 14, 2026

Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh (opens in new tab)

Cloudflare introduces Mesh as a private networking layer designed for humans, services, and autonomous AI agents. It connects devices, servers, cloud VPCs, Workers, Durable Objects, and Agents SDK applications without exposing private services publicly or relying on manual VPN and SSH workflows. Mesh builds on Cloudflare One, so existing Gateway policies, Access rules, device posture checks, and other Zero Trust controls apply automatically. ## Why Agent Workloads Need Private Networking - AI agents increasingly need access to private databases, APIs, repositories, MCP servers, object stores, and home infrastructure. - Traditional solutions are poorly suited to autonomous software: - VPNs often require interactive login. - SSH tunnels require manual setup. - Public exposure increases the risk of unauthorized access. - Basic connectivity does not provide sufficient visibility into agent activity. - Agents may have powerful permissions, including shell, filesystem, and network access, making misconfiguration especially dangerous. ## New Agentic Workflows - **Accessing personal agents remotely** - A user can run an agent such as OpenClaw on a home Mac mini. - Phones, laptops, and work devices can connect securely without exposing the agent directly to the public Internet. - **Letting coding agents access staging systems** - Agents such as Claude Code, Cursor, or Codex can reach private staging databases, analytics systems, APIs, and object stores. - Developers avoid exposing those systems or tunneling an entire laptop into a cloud VPC. - **Connecting deployed agents to private services** - Agents running on Cloudflare Workers can call internal APIs and databases. - Mesh is intended to provide scoped access, auditability, and reduced credential exposure. ## How Cloudflare Mesh Works - Mesh uses a lightweight connector and a single binary to connect: - Personal devices - Remote servers - User endpoints - Private cloud networks - Connected devices communicate over private IPs through Cloudflare’s global network, which spans more than 330 cities. - Cloudflare’s existing terminology is simplified: - WARP Connector becomes a **Cloudflare Mesh node**. - WARP Client becomes the **Cloudflare One Client**. - Example deployments include: - Connecting an iPhone to a home Mac mini running an agent. - Connecting a developer laptop to staging databases and internal APIs. - Connecting Linux servers and external cloud VPCs so agents can reach private resources and MCP servers. ## Security and Cloudflare One Integration - Mesh traffic automatically inherits Cloudflare One protections, including: - Gateway network, DNS, and HTTP policies - Device posture checks - DNS filtering - Access rules - Existing Cloudflare One customers can use Mesh without adopting a separate security platform. - Organizations can later expand into: - Access for Infrastructure for SSH and RDP management - Browser Isolation - Data Loss Prevention - Cloud Access Security Broker capabilities - The goal is to protect agent traffic with the same controls already used for human users and services. Cloudflare Mesh is positioned as a practical starting point for securely connecting agents to private infrastructure. Teams can begin with simple private networking and later add more advanced Zero Trust controls without migrating to a different platform.

agents-sdkpostgresqlsasessh+4