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_namespacesbinding 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-knowledgeinstance 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
AIChatAgentand 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
timestampboost. - 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.