Exa's pitch: agent search is an API problem, and discovery is not proof

Nitya Sridhar, who leads product and marketing at Exa, used a talk at localhost to argue that when the thing typing the query is software rather than a person, search stops being ten links and human judgment and becomes a crawling, embedding, and API packaging problem ^[1][2][4]. That matters because the requirements it implies do not sit neatly on top of a stack built for people skimming a results page ^[4].

Her framing starts with where search now lives. It is not a destination you visit; it is embedded in whatever product someone already has open, so asking Cursor about a research paper means that product has to reach the web, and Slack, coding agents, and anything else with AI attached now carry search as a core component ^[3]. Exa was roughly 25 people when she joined about a year ago, on the bet that agents become a growing share of who is actually searching ^[5].

Four differences follow. Latency spreads out rather than tightening: a voice agent needs an answer inside 200 to 300 milliseconds, while a research job building a large list or enriching a CRM can trade speed for comprehensiveness and quality ^[6]. Token efficiency becomes a real line item, because a documentation site is mostly content that does not answer the question, and returning only the relevant segment avoids bloating the agent's context and paying for tokens it does not need ^[7]. Comprehensiveness changes meaning, since a model cannot memorize the web and a request like every engineering professor at Berkeley is answered by the complete list, not the top ten results ^[8]. Exa hit this internally trying to find everyone in a newly opened Singapore office working on AI search, where a typical search returns things generally helpful around the topic rather than the specific list of people to contact ^[9]. The conclusion she draws is to treat the web as a database, where semantic search and structured extraction from each page matter more than keyword matching ^[10].

The load-bearing engineering claim is about one sentence containing two jobs. Take "find every Exa employee who went to Harvard": most capable models attempt it as a single search for the combined phrase, which fails because employer and education usually live on different pages under different names, and no page contains the phrase ^[12]. Doing it well means separating discovery, an open-ended hunt that benefits from trying alternate queries and deciding where else to look, from verification, a bounded check of one candidate against one criterion ^[13]. Agent, which Exa launched earlier that week, implements that: a coordinator generates candidates, retrieval pulls evidence, independent sub-agents verify each candidate against the criteria, and a final step assembles the supported results with sources attached ^[11][14].

The cost consequence is the interesting part. Candidate generation runs on the more capable, more expensive model because an omission there cannot be recovered later, which means the recall of the whole system is capped by that first step ^[15][2]. Verification runs on a cheaper model returning a bounded yes or no with evidence, at a fraction of the reasoning cost, and since each check needs no working memory from any other, they all run at once ^[16][17]. A list of 200 candidates against three criteria is 600 independent calls, which is the shape sub-agents are actually good at ^[1][18].

Worth watching: whether the coordinator's recall holds up on queries where the population itself is disputed, and whether teams like HubSpot, cited as relying on this for go-to-market and finance work, end up paying more for the discovery half than the verification savings recover ^[11][15][16].