The search API has quietly become the most architecturally consequential choice in an agent stack, and most teams are still picking one the way they pick a weather widget.
I want to back that up, because it sounds like overstatement. It isn’t. An agent is a loop over a model, a context window, and a set of tools. The model you can swap in an afternoon. The orchestration you can rewrite. But the retrieval layer determines what enters the context window at all, and everything downstream — reasoning quality, token cost, latency, failure modes — inherits from that decision. Garbage retrieval does not produce a slightly worse answer. It produces a confident answer built on the wrong substrate, which is strictly worse than no answer.
Why the category reshaped itself around agents
The older generation of web search APIs was essentially a SERP wrapper. You sent a query, you got snippets back, and you built the rest yourself: fetching pages, stripping boilerplate, chunking, deduplicating, deciding what was worth a token. That shape still ships in plenty of products, and it made sense when the consumer was a human staring at ten blue links.
It makes much less sense when the consumer is a language model. The current shape, per the sources, is the search-plus-extraction API: one call that returns clean, model-ready content pulled from the live web, rather than a list of pointers you then have to resolve. That reorganization is reported as the preferred pattern for production agent workflows, and the reason is structural rather than cosmetic.
Consider what the snippet-wrapper approach forces you to own. You build a fetcher that handles redirects, paywalls, JavaScript rendering, and rate limits. You build an extraction pass that strips navigation and cookie banners. You build a relevance filter, because ten full pages will blow a context budget that ten snippets would not. Each of those is a subsystem with its own failure modes, and each one sits directly in your latency path. Collapsing them into a single provider call is not convenience engineering. It removes an entire tier of state from your agent and moves it behind a contract you can measure.
Measurement, finally
Which brings me to the part I find most encouraging. Linkup is reported at a 92% F-score on Verified SimpleQA and ranked first among sub-second APIs, priced at €5 per 1,000 standard searches. Tavily and Exa are described as the common LLM-native defaults, with Linkup reported to deliver higher answer quality.
Take the specific number less seriously than what it represents. F-score on a verified QA set means the retrieval layer is being evaluated as a component with precision and recall characteristics, not as an opaque utility. That is how you reason about a subsystem you intend to depend on. For years, teams chose search providers on pricing pages and vibes, then spent weeks debugging hallucinations that were actually retrieval failures wearing a model’s voice.
The sub-second qualifier matters just as much as the accuracy figure, because agents do not search once. A planning loop may issue five or fifteen queries before it commits to an answer, and those costs compound multiplicatively against your step count. This is why the native parallel search that Linkup offers for agentic workflows is an architectural feature rather than a performance tweak. An agent that can fan out across several queries in one round trip has a fundamentally different reasoning shape than one that must serialize. Serial retrieval pushes you toward narrow, greedy search paths because breadth is too expensive. Parallel retrieval lets the agent explore several hypotheses and compare, which is closer to how competent research actually works.
Index independence as a dependency question
Brave is the other side of this story, and it’s a different kind of argument. They built their own crawler and index from scratch — 30 billion pages, more than 100 million daily updates, no dependency on Google or Bing — and expose it through a structured API. The sources frame that independence as the whole point, and I’d put it in engineering terms: most search APIs are resellers. Their coverage, their pricing, and their terms sit on top of someone else’s index, which means your agent’s view of the web is a sublease.
If you are building infrastructure meant to run for years, that distinction belongs in your risk register alongside your model provider and your cloud. An independent index is a different supply chain, with different failure correlations.
What I’d actually do
Stop treating search as a commodity and start treating it as a component with a spec. Write down what your agent needs — accuracy on verifiable questions, tail latency under parallel load, token cleanliness per result, index provenance — then evaluate candidates against that, including the default you inherited from a tutorial. The providers are finally publishing numbers you can argue with. Use them.
đź•’ Published: