Cloudflare AI Search 2026: Three Agent Framework Integrations, Side by Side

On 2026-07-30, Cloudflare published three integration guides for AI Search: one for the Vercel AI SDK, one for LangChain, and one for the Cloudflare Agents SDK. Together they turn a managed retrieval product into a drop-in retriever or model for the three agent frameworks most teams already use. The 2026-07-30 changelog post itself is short, but the substance lands a question apirank readers have been asking for months: "if I want retrieval-augmented generation without standing up Elasticsearch + Weaviate + a re-ranker myself, where do I plug in?"

What Cloudflare AI Search is, in 90 seconds

AI Search is a managed retrieval service on the Workers stack. You create an instance, push data into it (Workers storage, R2 bucket, public website, or a manual REST API push), and the service handles chunking, embedding, indexing, hybrid query (semantic + keyword), reranking, and result formatting. There is no model weight to deploy, no embedding dimension to choose, no vector DB to version-bump. You ship a JSON document in, you get a JSON list of relevant chunks out.

Three primitives matter:

• Namespaces — a logical partition per tenant / agent / project. Each namespace is its own searchable corpus.
• Search modes — vector, keyword, or hybrid (default; combines both with reciprocal-rank fusion).
• MCP endpoint — every instance exposes a built-in Model Context Protocol server, so any MCP-speaking agent (Claude Desktop, Cursor, the SDK tool-calling loop in this article) can search it without writing glue code.

That's the shape of the product. What changed on 2026-07-30 is that you no longer have to write the glue yourself — for three frameworks, the glue ships as a package.

The three framework integrations: what each one actually does

Reading the changelog and the three dedicated guides, you can tell each framework integration matches the framework's idiomatic usage. None of them is a thin HTTP wrapper.

Vercel AI SDK — ai-search-provider package

Cloudflare shipped a dedicated npm package called ai-search-provider. It targets AI SDK v6 (ai@^6) and exposes an AI Search instance as a language model so the existing generateText / streamText / tool primitives work unchanged. The key call is:

import { createAISearchNamespace } from "ai-search-provider";
import { generateText } from "ai";

const aiSearch = createAISearchNamespace({ binding: env.AI_SEARCH });
const { text, sources } = await generateText({
  model: aiSearch.get("knowledge-base").chat(),
  messages: [{ role: "user", content: "How does caching work?" }],
});

Three things to notice:

1. The binding accepts a Workers binding, not REST credentials. The integration is built to run inside a Worker, where env.AI_SEARCH is the way Cloudflare exposes the instance to your code. Calling this from a Node script outside Workers is possible but requires manual REST plumbing.
2. sources comes back as a top-level return field — every retrieved chunk is structured with its source URL, namespace, and relevance score, ready to feed a "view sources" UI or to log for analytics.
3. You can also expose instance.search() as a tool for agent loops, so the model can decide when to look something up rather than always retrieving.

If you are already using the AI SDK for chat completions and you want the minimum-diff path to grounded answers, this is it. The package is new, but it follows the v5 → v6 migration pattern many other providers shipped in 2026.

LangChain — CloudflareAISearchRetriever

The LangChain integration lands in the existing langchain-cloudflare package (PyPI and GitHub, both maintained by Cloudflare) as a new retriever class. It does not implement BaseChatModel; it implements BaseRetriever. That placement matters:

• You can use it standalone (a thin RAG over a Python service).
• You can wrap it with create_retriever_tool to give a LangChain agent a search tool.
• You can drop it into a pre-built RAG chain (RetrievalQA, ConversationalRetrievalChain) and the rest of the chain is unchanged.

It supports two auth models: REST credentials (ACCOUNT_ID + API_TOKEN) for normal Python processes, and a Workers binding for Python that runs inside Cloudflare Workers (Pyodide + Workers). Calling pattern:

from langchain_cloudflare import CloudflareAISearchRetriever

retriever = CloudflareAISearchRetriever(
    account_id=ACCOUNT_ID,
    api_token=API_TOKEN,
    instance_name="knowledge-base",
    retrieval_type="hybrid",
)
docs = retriever.invoke("How do I configure Workers AI?")

For teams that standardized on LangChain in 2024 and have not migrated, this is the lowest-cost on-ramp. The retriever respects the standard .invoke() / .batch() LangChain API, so downstream code keeps working.

Cloudflare Agents SDK — the stateful agent pattern

The Agents SDK guide does something different from the other two. It assumes you are building a stateful agent on Cloudflare — Durable Object-backed, persistent across turns — and shows how to provision its own AI Search instance, index content into it, and let the agent's tool loop call search. The recipe:

import { tool } from "ai";
import { z } from "zod";

const instance = env.AI_SEARCH.get("knowledge-base");

// Expose AI Search to the agent's model as a tool it can call.
const searchKnowledgeBase = tool({
  description: "Search the knowledge base for relevant content.",
  inputSchema: z.object({ query: z.string() }),
  execute: ({ query }) => instance.search({ query }),
});

Where AI SDK and LangChain each treat AI Search as a retrieval primitive inside an existing app, the Agents SDK guide treats it as a persistent memory layer for a long-running agent. The combination of Durable Object state + AI Search is what enables the agent to accumulate a session's worth of questions and answers against a per-tenant knowledge base without rebuilding an index every turn.

Side-by-side comparison

Why hybrid retrieval matters in 2026

All three integrations default to hybrid mode — the combination of vector similarity (semantic) and keyword matching (BM25-style), with reciprocal-rank fusion at the end. Pure vector search still has a well-known failure mode: highly specific terms — exact product names, codes, IDs, error messages — get averaged into noise. Pure keyword search has the opposite failure: paraphrase-friendly queries like "how do I make it faster" miss the right page because the words don't match.

Cloudflare's hybrid mode ships a re-ranker as part of retrieval, so you don't need a Cohere / Voyage cross-encoder in your stack. For teams that ran pure vector retrieval in 2024 and got bitten by the "why won't it find the exact error code" complaint, hybrid is the default that fixes it.

The surrounding stack: R2, Workers, AI Gateway, Vectorize

AI Search is not a standalone — it sits inside a quartet:

• Workers hosts the indexer and the runtime. You push content from a Worker, the indexer ingests it, and Workers KV writes handle chunk metadata.
• R2 stores large / raw documents (PDFs, HTML crawls). AI Search reads from R2 directly when your data source is a bucket.
• Vectorize is Cloudflare's standalone vector database. AI Search uses Vectorize under the hood for the vector half of hybrid mode, but exposes a much higher-level API.
• AI Gateway is the LLM layer. AI Search returns documents; AI Gateway routes the LLM call that synthesizes the answer. Putting the two together gives you a complete retrieval-generation loop without leaving the Workers platform.

This is also why the three integrations read so cleanly: none of them owns the storage, the indexing, or the generation. They each own a seam. The seam between managed retrieval and your framework's tool/retriever/model abstraction.

Pricing, free tier, and limits

Cloudflare AI Search is listed as available on all plans (Free, Paid Workers). Storage, queries, and indexing have tier-bounded limits. The exact public numbers move — the official Limits & pricing page under /ai-search/ is the source of truth — but the rough shape in mid-2026:

• Free plan: tens of thousands of vector records and a monthly query allowance — enough for prototyping and a single-tenant knowledge base.
• Paid Workers plan: scales into the millions of records, with the same per-request pricing as other Cloudflare primitives (a few tenths of a cent per 1K retrieval calls).

For a fair comparison against vector DBs in this catalog, AI Search is priced like Cloudflare storage and Workers compute, not like a managed vector DB. Pinecone / Weaviate / Qdrant / Chroma all publish priced plans in the same range when you scale; the AI Search differentiator is that you do not pay separately for embeddings or for re-ranking because they are part of the retrieval call.

When AI Search is the right answer — and when it isn't

Use AI Search when:

• You already run on Workers / Pages / R2 and want zero new infra.
• You need hybrid retrieval (semantic + keyword) out of the box without configuring a re-ranker.
• Your content fit is RAG-shaped: one to a few hundred namespaces, each in the thousands to low-millions of records.
• You want an MCP endpoint for free, so Claude Desktop / Cursor / any MCP agent can search without integration work.

Stay on Pinecone / Weaviate / Qdrant / Chroma when:

• You have tens of millions of vectors per namespace or need sharding at a scale Cloudflare has not publicly benchmarked.
• You need custom embedding models, metadata filtering at arbitrary cardinality (e.g. SQL-style joins), or hard multi-region replication contracts.
• Your retrieval latency budget is below 50 ms p99 from outside the Cloudflare network — there are better paths on a dedicated vector DB.
• You have an existing Pinecone / Weaviate / Qdrant / Chroma deployment you cannot migrate off.

Verdict

The 2026-07-30 changelog is small in volume but large in implication: AI Search becomes the default retrieval layer for any app already running on Workers. The three framework integrations are not three ways to do the same thing — they are three distinct shapes (model / retriever / tool) for three distinct framework idioms. Cloudflare is signaling that future framework releases will keep treating AI Search as a first-class primitive, not a REST endpoint to wrap.

If you have been on the fence about managed retrieval because no single package fit your framework — LangChain for one app, AI SDK for another, Agents SDK for a third — that excuse is now closed. Pick the integration that matches the framework you are already in.

Working with AI Search across multiple providers? If you also route your LLM calls through OpenAI, Anthropic, Gemini, and Workers AI and want a single dashboard for cost-per-search and cost-per-generation, FreeModel exposes them all through one API key with usage breakdowns that surface when AI Search retrieval cost dominates an agent's per-request budget — useful when you decide whether to keep hybrid retrieval on for a query or fall back to keyword-only.