Agentic search: building search tools for AI agents with Meilisearch and the Vercel AI SDK

As large language models’ reasoning capabilities increase, one thing does not change: AI agents are only as good as the context they have access to.

RAG (Retrieval-Augmented Generation) is the standard recipe for giving AI models access to custom data. We chunk documents, compute dense vector embeddings, and run semantic search on the user query, and call it a day. While this works for basic Q&A, this approach hits a ceiling with more complex queries when multi-intent questions, domain-specific vocabularies, or multi-step logic need to be extracted from the user question.

That’s because traditional RAG is a rigid, one-shot pipeline. The developer decides upfront what to retrieve, how to retrieve it, and when to stop. The model is merely a passive summarizer at the end of the assembly line.

Agentic search flips this paradigm on its head. Instead of forcing queries through an inflexible retrieval script, you equip the model with search tools and let it decide what to search, how to construct filters, when to drill deeper, and when it has gathered enough evidence to answer.

We are bringing this capability to the TypeScript ecosystem with @meilisearch/ai-sdk, a suite of search tools for the Vercel AI SDK.

In this article, we’ll explain why agentic search matters, how it beats bespoke search workflows, and how to build production-grade search tools for your agents.

What is agentic search?

Agentic search is an architecture where a Large Language Model (LLM) is equipped with search tools and given the agency to query, inspect, and filter data iteratively.

In a traditional “one-shot” RAG setup, retrieval is an engineering pipeline:

1. User submits a query.
2. An embedding is generated.
3. A retrieval step fetches top-k chunks.
4. Chunks are injected into the prompt.
5. The LLM generates a response.

If the user query is ambiguous or requires data across multiple searches to answer, the one-shot retrieval step fails. You either retrieve irrelevant noise or miss critical context entirely.

Agentic search replaces that brittle pipeline with an autonomous feedback loop. A simple search agent can be built around three steps:

• Plan: deciding how to solve the user query
• Search: using tools to solve the query, or identified subqueries
• Evaluate: assess if tool results progressed the plan, or if we should revisit our approach

This is a naive, high-level approach that enables building an autonomous search agent.

An agent session looks like:

1. User submits a query.
2. The LLM reason and make a plan to answer it.
3. The LLM calls a search tool.
4. The LLM judges the quality of results; if it needs more context, loop to step 2.
5. The LLM has enough context to generate a response.

Rather than building a brittle state machine in your application code to handle edge cases, agentic search lets the model plan and orchestrate the search. Your job is to provide the tools to retrieve relevant data and define the guardrails for the model's behavior.

Agentic search is not web search

When developers hear “search tools for LLMs”, they often think of web search APIs like Perplexity, Exa, or Parallel. Web search is indispensable for searching public knowledge, but AI products often run on proprietary, structured, and domain-specific data. This accrued context is your moat over competitors, and what enables building experiences tailored to your users.

Your internal product catalog, documentation, or knowledge base does not live in Google search results. They live in your databases. Using a search engine like Meilisearch, you can give your agents deep, fast, and structured access to your privately indexed data.

Agentic search vs traditional RAG

Retrieval-Augmented Generation is a pattern to improve context provided to an AI model by enriching the user query with context-relevant data. Agentic search does not oppose that principle; on the contrary, it builds upon it: think of agentic search as multi-turn RAG, or agentic RAG. When people ask the question of “agentic search vs RAG”, they often want to compare agentic search versus deterministic search workflows.

An application is agentic when it puts the LLM in the driver’s seat; the model decides the course of action. Conversely, AI-powered search workflows use LLMs for specific steps in an algorithm (query expansion, semantic search, summarization…). While advanced workflows may include multiple steps leveraging LLMs (retrieval, reranking), they still run deterministically.

Not every search problem needs an autonomous agent. Workflows come with predictable latency and costs. An open agent loop is more powerful, but you want to reach for it when the search path (“how” you solve queries) varies from one request to another.

Agentic search trade-offs

In deterministic search workflows, every step is hardcoded. It is fast, reproducible, and bounded. But if a user asks a nuanced question that falls outside the workflow’s designed scope, the retrieval pipeline breaks.

Agentic search trades that deterministic latency (and cost!) for reasoning power: the retrieval quality can scale with the model capability instead of being limited by your pipeline design. When the model controls the tool calls, it can self-correct when a query yields zero hits, rephrase keywords, or apply tighter filters. It iterates until it finds evidence to answer the request.

Here is a summary of the comparison between agentic systems and deterministic workflows for AI-powered search:

Building agentic search

We built the Meilisearch AI SDK to make agentic search simple to integrate for TypeScript developers. Through the @meilisearch/ai-sdk package, we provides search tools compatible with the Vercel AI SDK. This section explains how to build a search agent using these packages.

In this guide, we’ll use OpenAI models, but the AI SDK is compatible with any models, and so is Meilisearch. For optimizing your agent retrieval in production, read our guide on choosing an embedder.

Installation and setup

This section assumes you have a working directory with Node.js installed.

Install the core dependencies:

Then, set up your environment variables:

If this is your first time using Meilisearch, you can create a project on Meilisearch Cloud or self-host it. Navigate to your chosen LLM provider to get an API token.

Basic agentic search

To give an agent the ability to query a Meilisearch index, use meilisearchSearch. The description parameter is the most critical piece: it tells the model what data lives in the index and when it should decide to call the tool.

Under the hood, generateText handles the function-calling handshake. When the model determines it needs movie data, it generates tool arguments, @meilisearch/ai-sdk executes the search against your Meilisearch instance, and the structured search hits are returned into the model's context for synthesis.

We can improve the agent by tweaking the relevancy of its search tool. For example, we can update the searchParams to sort popular movies first, or we can allow filtering by author, genre, actors, or any facet that would make the search more relevant for end users.

Additionally, we can provide the agent with more tools. Providing simple, composable tools allows the agent to engineer its own path to answering a query. By adding a findSimilarMovie tool that builds upon meilisearchFindSimilar, the agent can recommend movies similar to one referenced in the conversation. Recommendations become even more effective when paired with personalization.

Agentic search example

To understand why agentic search with domain-specific tools beats generic RAG, let's look at a concrete domain: building a chatbot to answer questions about Magic: The Gathering, a trading card game. In practice, this is similar to any chatbot that sits on top of a knowledge base, but the game's complexity makes it a perfect use case.

Magic has one of the most complex rule systems in gaming. It consists of:

• A Comprehensive Rules document with numbered cross-references (e.g., Rule 702.48a).
• A specialized glossary where common words (e.g., "Target", "Dies", "Stack") have precise, legalistic game mechanics.
• Over 25,000 unique cards with distinct effects, using vocabulary from the rules and glossary.

Whenever a large language model relies on its training knowledge, or uses naive web search to research missing information, it will frequently hallucinate rulings. Often, it confuses the colloquial meaning of a term with the technical game rule, and “interprets” the rules based on its own reasoning instead of referencing the rules.

Let’s see how we can build an agent to tackle such a problem.

Build agent search tools

Instead of a generic “web search” tool that the agent should use to get a rough understanding of rules, we want to equip it with all the primitives required to build the full context related to a question.

Based on the rules and card information at our disposal, we break the domain down into three purpose-built Meilisearch indexes: glossary, rules, and cards.

The composability of the tools is essential. This is why agents perform well with code and bash scripting: because they can use simple building blocks to create algorithms to answer complex questions. You’re not providing a tailor-made workflow for the agent; you’re giving it the tools to build its own solution to the problem.

Multi-hop agentic execution in action

Consider a user asking:

“How can a player lose in Magic?”

This simple question can easily trick the model into believing its training knowledge is sufficient to answer it. Let’s see how our purpose-built agent might answer it.

1. Search the glossary

Using its searchGlossary tool, the agent finds this document, which partially answers the question:

It identifies that many rules are referenced, and thus decides to search for their definition.

2. Search rules

This time, it now uses the searchRules tool to learn more about rules 104, 810.8, 809.5, and 903.10.

While doing so, it should realize that 104 is actually an entire rule section dedicated to “Ending the Game”, which includes 27 sub-rules. Several of these rules also reference other rules. The agent can repeat this step to research them until it has full context of rules pertaining to losing the game.

This is where building context-efficient tools becomes critical. As the number of tool calls can grow, we want to minimize context rot to preserve enough of the context window for the model to reason. In this example, a getRule tool retrieving a single rule’s text would be a useful addition. Irrelevant results would not reach the model’s context, and we could skip additional follow-up steps; for example, if pagination does not include all the sub-rules. A purpose-built tool could return the full rule and its child rules in a markdown response.

3. Formulate an answer

After collecting all context, the agent can answer the initial question. Thanks to navigating the glossary and rules, it now understands that there are different ways to play Magic: The Gathering, called “variants”. In each of these variants, an additional set of rules apply.

Our agent can now report on these subtleties, or ask clarifying questions before formulating an answer, based on its system prompt.

Optimizing for retrieval

Even with publicly available datasets like Magic rules, specialized search tools consistently outperform naive web search and vanilla RAG setups. The reason comes down to how data is indexed and retrieved to serve the model's reasoning loop.

Full-text precision for domain vocabularies

In domains with specialized lexicons, lexical match is non-negotiable. A generic web search engine or a vector-only index will blur terms like "dies" (which means something specific in Magic: The Gathering) with colloquial death or discard. By powering a dedicated searchGlossary tool with full-text search, the agent gets deterministic, verbatim definitions without semantic drift.

Relationship modeling and structured metadata in documents

Rules in complex domains rarely exist in isolation—they form an interconnected graph with explicit and implicit cross-references. In a naive chunk-based RAG pipeline, arbitrary splitting cuts across rule boundaries and severs these dependencies.

How you construct your index documents directly dictates retrieval quality:

• Document structure: Indexing each rule along with its hierarchical path (e.g., section, parent rule, sub-rules) and relationships ensures that when the agent pulls a rule, it retrieves the entire relational context rather than an orphaned fragment.
• Filterable metadata: Exposing structured fields like section, rule_number, or category allows the agent to filter and sort results and build targeted searches (e.g., scoping queries strictly to section = 104 or format = "Commander"), eliminating noise before it hits the prompt.

Embedding configuration as business logic

For multi-faceted data like cards, retrieval needs vary drastically depending on the user's intent. Sometimes a player asks for cards with a similar mechanical effect; other times, they want characters connected by lore, artists, or specific mana profiles.

With Meilisearch's embedder configuration and dedicated APIs like documentTemplate, you can externalize this domain logic directly into the search engine:

• You control exactly which fields (oracle text, flavor text, creature types, card mechanics) are formatted into the text string before generating embeddings.
• By defining separate embedders or template profiles (e.g., one optimized for mechanical rulings vs. one tuned for lore and character associations), your agent can leverage specialized semantic tools (searchCardMechanics vs. searchCardLore) without bloating application-level glue code.

When you tailor your indexing strategy to how the agent reasons, each tool call returns compact, highly relevant evidence: this maximizes reasoning accuracy while minimizing context rot.

Monitoring agentic search

When building agentic search, search is no longer a one-off query triggered by a human. It becomes an internal dependency of an LLM reasoning loop. A single agent response can fan out into sequential or parallel tool calls. Latency and errors compound directly into user-perceived turnaround time.

Search engine observability

Meilisearch monitoring provides engine-level visibility across three critical dimensions:

• Search performance & latency budgets: If an agent executes four sequential searches to answer a multi-hop question, a 150ms search latency adds 600ms of waiting time before the model even begins token generation. Use the Performance trace chart to break down per-step timing (lexical matching, vector search, filter evaluation, ranking rules) and verify that semantic embedders or unindexed filters are not starving the agent loop.
• Indexing performance & knowledge freshness: When agents answer questions over dynamic catalogs, documentation, or operational data, the time-to-search (TTS) metric tracks the lag from document ingestion to search availability. TTS defines your agent's real-time staleness window.
• Operations & API responses: Monitor spikes in HTTP 4xx errors to make sure your agent tools are consistently available. When tools return errors, LLMs search for other ways to answer the request and may produce hallucinated answers. Bandwidth metrics help detect whether tools are returning oversized payloads, which can cause context bloat.

Additionally, Meilisearch exposes an experimental Prometheus endpoint to correlate search engine metrics alongside your broader application telemetry for teams managing unified observability stacks (e.g., Datadog, Grafana).

LLM tracing

Monitoring your search engines tells you if the retrieval is fast and reliable, but it cannot tell you whether your agent is making good decisions. To obtain complete observability, instrument an application-level tracing layer (e.g., OpenTelemetry) to track what happens above the search engine boundary:

Search analytics for agentic workflows

Traditionally, search analytics measure human interaction: click-through rates (CTR) and conversion funnels. In agentic systems, search analytics help inspect how the model uses its tools:

• Tool parameter compliance: Is the model passing valid filter strings (e.g., genres = "Sci-Fi" AND year >= 2020), or is it attempting to filter on unindexed properties?
• Zero-result queries: When an agent query returns 0 hits, analytics reveal whether documents are missing from your index or if the model generated overly restrictive queries.
• Query refinement loops: If an agent queries the same index multiple times in a single turn, this may mean the initial queries lacked relevancy—signaling that your document templates, ranking rules, or tool descriptions need adjustment.

Scaling agentic search

Scaling search for AI agents differs fundamentally from scaling human-facing search. While a human may send one query every few seconds at best, an agent is a programmatic consumer that multiplies query volume across concurrent sessions.

High availability and read throughput

Autonomous agents can generate bursty search traffic across concurrent sessions. In this context, a single node can become saturated quickly. Meilisearch allows you to set up replicated shards to ensure high availability and distribute search load.

How replication works:

• Read replicas: Distributing index workloads across replica instances allows read traffic to scale horizontally, keeping p99 response times flat during peak agent activity.
• Geographic distribution: Placing replicas in cloud regions closest to your LLM orchestration layer (e.g., edge runtimes or inference clusters) eliminates cross-region network latency on every hop of the agent loop.
• Resilience: If a replica instance drops, network search routes queries to another replica without interrupting active agent sessions.

Sharding and remote federation

When an agent needs to reason across multi-gigabyte document catalogs, enterprise wikis, or millions of structured items that outgrow a single machine, index sharding distributes your documents across multiple Meilisearch instances, named shards.

By configuring a sharded cluster, you get:

• Document distribution: Documents from a single index are transparently partitioned across multiple instances (remotes), with a cluster leader handling ingestion and routing.
• Remote federation: When an agent invokes a tool, the receiving node fans out the query across remote shards, merges ranked hits, and returns a unified, deduplicated response. The agent interacts with a single coherent endpoint, abstracted from the underlying cluster topology.

Scoping agent permissions

Giving an autonomous model access to overly permissive API keys is a critical security vulnerability. Agents construct queries dynamically, which means access control must be strictly enforced at the search engine boundary.

Meilisearch comes with baked-in security with tenant tokens to scope the agent’s permissions.

With Meilisearch, your agent search permission can be configured as follows:

• Tenant tokens: Instead of sharing global search keys, generate time-bounded, cryptographic tenant tokens on your backend before passing them to @meilisearch/ai-sdk tools.
• Embedded filter rules: Tenant tokens bake search rules and tenant boundaries directly into the token signature (e.g., tenant_id = "org_123" AND is_archived = false). Even if an LLM hallucinates query arguments or attempts prompt injection to bypass application guardrails, Meilisearch enforces tenant isolation at the engine level.
• Index-level scoping: Restrict each tool's credentials to the exact indexUid it is designed to query, preventing the model from traversing unrelated data stores.

Optimizing agentic search

Optimizing an agentic search system comes mainly from optimizing the key components of the agent: the relevancy of its search tools and its model’s context window. These improvements to the agent harness can then be tested and benchmarked through evals.

Search relevancy

The best agent prompt cannot rescue a poorly configured search index. Your search agent can only be as useful as the quality of the search engine it uses.

To that extent, make sure to read Meilisearch documentation on indexing best practices, fine-tuning the full-text search relevancy, and how to leverage semantic vs hybrid search.

Here are the key features to leverage for an efficient starting point for agentic search:

• Hybrid search: Combine BM25 full-text keyword matching with semantic vector search. Full-text search guarantees exact matches for product SKUs, proper nouns, and card names; semantic search covers intent, paraphrasing, and natural language concepts.
• Document templates: When using Meilisearch's integrated vectorizer, use document templates (documentTemplate) to format how fields are stringified before embedding. Make sure metadata like categories and tags are included in the vectorized text.
• Searchable attributes: Expose structured filterable attributes to the tool definition so the model can use deterministic SQL-like filters alongside natural language queries.

Context engineering

As large language models suffer from context rot: this means their performance degrades as the context window fills with irrelevant information.

As a result, an important part of optimizing an agentic system’s performance is managing the model’s context window:

• Pruning unnecessary data: Do not dump entire raw JSON documents back into the model's context. Strip internal IDs, system timestamps, and large unneeded arrays.
• Search with snippets: Show users exactly where their query matched in a document, using attributesToCrop and attributesToHighlight to include only the matching passages.
• Preserve failure context: When a tool call returns zero results or errors, keeping the results and error messages in the context window allows the agent to observe the failure and reevaluate its approach.

Writing evals for agentic retrieval

Because the retrieval path for agent systems is non-deterministic, scoring only the final answer turns your agent into an untestable black box. To make the system resilient, you want to break that down into testable components. When the agent's answer is wrong, you need to know if the engine returned irrelevant results, the model reasoned incorrectly, or the synthesis step hallucinated.

A production eval harness isolates these failure modes and scores key actions at each stage against a golden dataset:

• Tool selection accuracy:
  • Score whether the model correctly maps user intent to the appropriate tool boundary (e.g. routing rule questions to searchRules versus definition requests to searchGlossary).
  • Track intent classification accuracy and monitor fallback frequency to verify that tool descriptions provide distinct, non-overlapping trigger boundaries.
• Query & filter quality:
  • Evaluate how effectively the model leverages your search engine’s query and filtering capabilities. Test parameter compliance against your schema, flag zero-result queries caused by overly restrictive syntax, and measure query reformulations during refinement loops.
  • Decouple engine retrieval from model prompting by scoring your search tools directly with traditional information retrieval metrics: run Recall@K (e.g. Recall@10 or Recall@15) to guarantee the required evidence exists in the candidate pool, MRR (mean reciprocal rank) to track the position of the first relevant hit, and NDCG@K to evaluate multi-faceted, graded relevance.
• Grounded answer synthesis:
  • Verify that the generated response faithfully reflects the retrieved search hits rather than parametric model memory. Pair LLM-as-a-judge evaluators with source attribution checks to measure claim verifiability, citation precision, and hallucination rates.
  • For open-ended queries where a single gold answer does not exist, evaluate semantic recall across the multi-hop trajectory along with reference-free metrics like query coverage.

Running this harness on every schema change, prompt edit, or ranking rule update ensures that tuning an index configuration or sharpening one tool’s description does not silently degrade retrieval across the rest of the agent’s execution path.

Conclusion

The era of designing rigid, hardcoded search pipelines for every user workflow is coming to an end. By giving AI models direct access to fast, structured, and relevant search tools, you leverage their reasoning capabilities where it matters most: understanding messy user intents, exploring multiple paths, and retrieving exact answers.

Using Meilisearch and the AI SDK, you build the tools, set the boundaries, and let the model do the thinking. You can turn your Meilisearch indexes into production-ready agent tools in fewer than twenty lines of TypeScript. Read our guide to get started with agentic search.