An agent that can search the web is more useful than one that cannot, and also more likely to be confidently wrong. The difference is rarely the model. It is what the search call returns: snippets that fit in context, pages that need parsing, or a synthesised answer with no traceable source.
That makes the choice of search backend a design decision, not a vendor preference. This page compares five options we have used — Exa, Tavily, Brave Search API, SerpAPI, and Kagi — by what comes back and what it costs to use.
The short answer
If the agent needs to find pages by meaning, use Exa. If it needs a small, citation-ready payload per call, use Tavily. If you need a general web index you can depend on, use Brave. If you need engine-shaped results without scrapers, use SerpAPI — after reading its terms. If result quality matters more than volume, Kagi is the research option.
Exa: retrieval by meaning
Exa embeds the query and the pages, so a search can succeed even when the words do not match. That is the case that matters for an agent: the user asks "how do I stop an agent from redeploying broken configs", and the page that answers it is titled "guarding autonomous deployments".
The API returns extracted contents with results, which removes a fetch round trip. The trade-off is index shape: it is not a news engine and not a keyword-exact engine. If your task is "find the page that means this", it is strong. If your task is "find this exact error string", a conventional engine is better.
Tavily: shaped for tool calls
Tavily's output is deliberately small: a handful of ranked results with content, and an optional synthesised answer. For an agent with a limited context window, that is the right size, and the citation fields make the answer checkable.
The limit is depth. It is built for "answer this question with a few sources", not for "read twenty pages and reconcile them". Reach for it when the tool call is one step in a loop, not when the loop is the point.
Brave: an independent index
Brave runs its own index rather than reselling another engine, which matters when a product cannot afford to depend on a single upstream provider. The API is conventional: query in, ranked results with snippets out.
Independent does not mean equivalent. Coverage of long-tail pages differs from the major engines, and that shows up in evaluation rather than in documentation. Test it against your own query set before standardising on it.
SerpAPI: the engine page as JSON
SerpAPI returns result pages as structured JSON, including the features around the results — knowledge panels, related questions, shopping blocks. It exists because scraping result pages is fragile, and the service absorbs that operational cost.
The important caveat is not technical. Whether you may build on engine results at all is a terms question, and it differs by provider and jurisdiction. Read those terms before you write code, not after.
Kagi: quality at a per-query price
Kagi is a paid search engine with no advertising, and its API charges per query on top of the subscription. The controls are unusual: lenses, domain filters, and ranking preferences you set deliberately.
That makes it a research tool rather than a bulk retrieval layer. If a human is going to read the results, the quality is worth the price. If a machine is going to call it ten thousand times a day, the arithmetic changes quickly.
What to compare
| Question | Exa | Tavily | Brave | SerpAPI | Kagi |
|---|---|---|---|---|---|
| Semantic matching | Strong | Partial | No | No | Partial |
| Returns page content | Yes | Yes | Snippets | Snippets | Snippets |
| Own index | Yes | Aggregated | Yes | Upstream engines | Yes |
| Synthesised answer | No | Optional | No | No | No |
| Best for | Meaning | Agent tools | General index | Result features | Human research |
The row that decides most implementations is the second one. If your agent has to fetch every URL to read it, you have added a failure mode and a round trip to every search.
The part nobody benchmarks
Search quality on a demo query is easy to compare and mostly meaningless. What breaks agents in production is the tail: the query where the top result is a forum thread with no answer, the query where the snippet contradicts the page, the query that returns nothing and gets summarised as a definitive negative.
Two mitigations apply to every backend. First, require the model to quote or cite the result it used; a claim without a URL is a bug. Second, treat zero results as an error, not as evidence that the answer does not exist.
Cost shape
All five price per query, which makes the cost model simpler than seat-based pricing but easy to underestimate: an agent that retries a failed search three times pays four times. Cache aggressively within a session — the same query rarely needs a second paid call.
The other cost is latency. A search call that takes 800ms is fine in a batch workflow and painful in a chat turn. If a tool call is on the critical path, measure it before choosing on result quality alone.
Frequently asked questions
Can I use one backend for everything? Yes, and most teams should start that way. Adding a second backend doubles the failure modes before it improves the answers.
Which one is best for an MCP server? Any of them can be wrapped as a tool. Tavily and Exa ship content with results, which makes the wrapper narrower and the context smaller.
Do I need a search API if I have a model with web access? If you need citations you can verify, yes. A model with browsing is convenient; an API with returned content is auditable. See giving an agent web search for the workflow around it.
Last checked: 9 November 2026. Pricing and index coverage change; the table is about shape, which changes more slowly.
Related: answer engines vs search engines, Firecrawl, and search tools.