Every agentic RAG tutorial ends the same way. Pick a search API, wire it into your LangGraph node, ship it. But which API? The docs all claim the same three virtues (accurate, fast, AI-native), and you find out which one is lying only after you have already built around it.
So I stopped reading landing pages and ran the same 100 queries through Tavily, Exa, and Brave Search.
The 100 were not synthetic. They came from four buckets I actually hit in my day job with an agentic RAG harness: 25 fresh-news queries (what shipped this week), 25 long-tail lookups (things Google buries), 25 code-context searches (API-name grep across the web), and 25 named-entity lookups (person / product / paper). Each API got the same query strings, the same 10-result cap, and the same downstream synthesis step. The only thing that changed was the search backend.
Here is what fell out.
Why these three and not the other twelve
The 2026 search-API market is crowded. Perplexity, You.com, Firecrawl, Linkup, Parallel, Serper, Kagi, plus five or six niche indexes I keep hearing about at conferences. I picked Tavily, Exa, and Brave because they map cleanly onto three different theories of what "agentic search" should be:
- Tavily ships an AI-first ranker. Their pitch: the API already knows you are an agent, so results are summarized and score-tagged and safe to hand straight to an LLM.
- Exa ships neural vector search across a proprietary index. The pitch: semantic similarity beats keyword matching once your query is fuzzier than "site:github.com login bug".
- Brave Search ships an independent web index that answers in the shape of a normal SERP. The pitch: no third-party dependency, no re-ranking layer, just the web.
Three theories, three APIs, one Python harness. Whichever theory won on my 100 queries would tell me something about which theory should win on yours.
The setup, in fewer lines than you would expect
The whole benchmark harness is under 200 lines. It wraps each API in a search(query: str) -> list[dict] function that returns {title, url, snippet, score, latency_ms}, logs raw JSON to disk, and then hands the top-10 results to an LLM synthesizer that produces a one-paragraph answer. Ground truth for grading was hand-labeled: for each query I wrote down what the correct answer looked like before I ran any of the APIs.
def bench(query: str, api: str) -> Result:
t0 = time.perf_counter()
hits = SEARCH[api](query, k=10)
dt = (time.perf_counter() - t0) * 1000
answer = llm_synthesize(query, hits)
return Result(
api=api, query=query, hits=hits,
answer=answer, latency_ms=dt,
)
RESULTS = [
bench(q, api)
for q in QUERIES
for api in ("tavily", "exa", "brave")
]
I ran everything twice, on two different mornings, to smooth over transient outages and index freshness. The two runs matched within 5% on every metric, and the numbers below are the average of both.
The scoreboard
| Bucket (25 queries each) | Tavily correct | Exa correct | Brave correct |
|---|---|---|---|
| Fresh news (this week) | 18 | 12 | 21 |
| Long-tail lookup | 15 | 20 | 14 |
| Code-context search | 13 | 19 | 16 |
| Named-entity lookup | 22 | 21 | 20 |
| Total | 68 | 72 | 71 |
The totals are within a hair of each other. That is the first surprising finding: at the aggregate level, all three APIs are competent. If you stop reading here and roll a die, you will not embarrass yourself.
But the per-bucket splits are where the decision actually lives.
Where each one won
Brave took fresh news. 21 of 25 on this-week queries, the top of any pack. Brave's independent crawl re-indexes news domains aggressively, and I hit day-of citations that Tavily and Exa were still missing 6 to 24 hours later. The Nebius acquisition of Tavily (announced 2026-02-10) is a good example. I ran the query "who acquired Tavily 2026" the same afternoon it broke, and only Brave surfaced the press release in the top 10. Tavily and Exa were still returning generic company pages.
Exa took long-tail lookups and code context. 20 and 19: clear wins where the query stops looking like a keyword search and starts looking like a paragraph. My favorite example: I asked "python library for streaming JSON parsing without loading full document in memory" and Exa's neural index surfaced ijson in the top 3. Brave surfaced generic "JSON parsing tutorial" pages. Tavily surfaced Stack Overflow threads that mentioned ijson only in a comment on the fourth reply. Semantic search works.
Tavily took named entities. 22 of 25 on person/product/paper lookups. This is where the "AI-native ranker" pitch pays out. The summarizer up-weights authoritative pages (Wikipedia, arxiv, official docs) in a way that makes named-entity queries land on the canonical source almost every time.
Nobody dominated overall. If your agentic RAG workload is 60% one bucket and 40% another, the winner changes.
The latency and cost story
Latency is where the marketing pages start to lie hardest. Here are the p50 and p95 numbers from my run:
| API | p50 latency | p95 latency | Notes |
|---|---|---|---|
| Brave | 640 ms | 980 ms | Consistent; independent crawl reflected in speed |
| Exa | 780 ms | 1,420 ms | Neural search takes longer to score |
| Tavily (basic) | 900 ms | 1,600 ms | Standard tier |
| Tavily (advanced) | 3,100 ms | 6,200 ms | The "research" depth setting is a real bottleneck |
If you plug Tavily's advanced search depth into a real-time agent, users will feel it. That 5+ second p95 showed up in my logs on 3 of every 10 queries. For a chat-style agent, that is disqualifying. For a batch pipeline, it is fine. I know this because I shipped one demo with advanced-tier on, watched the spinner spin for six seconds, and had to explain to the stakeholder that no, the page had not crashed.
Cost is the other axis. Round numbers as of my benchmark run:
- Brave: $5.00 per 1,000 requests. Simple.
- Tavily: about $0.0075 per credit on the Researcher plan ($30/mo for 4,000 credits), or $0.008 per credit pay-as-you-go. Basic search is 1 credit, advanced search 2. Slightly cheaper than Brave per basic request; adds up fast if you hit advanced tier volume.
- Exa: usage-based pricing that varies with query type; my 100-query bench came in near $0.35 all-in, which is competitive with Tavily.
None of these will bankrupt a hobby project. They will show up in a bill if your agent takes 15 search steps per user turn, and serious agentic RAG will hit that number more often than you expect.
The one thing the benchmarks do not show
There is a quality axis nobody puts in a benchmark table: how much does the API want to help you look at the raw web versus how much does it want to summarize the web for you?
Tavily and Exa both bias toward pre-digested answers. Their "advanced" or "content" fields want to give the LLM chewed food. Brave's response is closer to what you would get from a real SERP: titles, snippets, URLs, and nothing else. For an agent that already has its own synthesis step, the Brave shape is easier to reason about; there is no double-summarization to fight.
I have started defaulting to Brave for anything my agent will need to cite, and Exa for anything my agent needs to find before it cites. Tavily has become the specialist for named-entity resolution. Small share of my traffic, but the wins are big enough to justify keeping it in the harness.
What I would do differently if starting today
Three practical rules from the 100 queries:
- Do not pick a single search API. The bucket splits are too sharp. My production harness now routes queries to different backends based on a lightweight classifier: fresh-news to Brave, long-tail/code to Exa, named-entities to Tavily.
- Never turn Tavily's advanced depth on for interactive agents. The p95 will kill your UX. Reserve it for background batch jobs.
- Log ground truth before you run the benchmark. I nearly graded on "did the LLM's synthesized answer sound plausible", which is a way to accidentally reward whichever API was best at BS. Writing down the correct answer first saved me from that trap on 4 or 5 queries.
None of these APIs won outright. "Agentic search" is not one problem, and picking one API means silently accepting the buckets where that API is mediocre. Route your queries. The routing layer is 30 lines of code.
The framework I used to design this bench — Search API selection for Agentic RAG, when to route to which backend, and how the whole thing plugs into a LangGraph-style harness — is one of the chapters in my Zenn book on Context Engineering. If you want the chapter-by-chapter deep dive on how each of these pieces fits into a working agentic RAG harness, here is the LP.
Context Engineering Book — RAG, MCP & CLAUDE.md in Practice — Ken Imoto
Why does the same question give wildly different answers? Not your prompt — your context. Original benchmarks show up to 4.6x quality gain. The complete Context Engineering system: 5-stage strategy, RAG, MCP, CLAUDE.md, Agentic RAG.
kenimoto.dev
Happy routing.
Top comments (0)