At localhost, Nitya Sridhar, who leads product and marketing at Exa, talked about what changes when search is not just something a human types in a box.
The old pattern was simple: go to Google, type in a query, get ten links, click the one that looks right based on human judgment. That pattern is breaking down because search is no longer a destination, it's embedded inside whatever product someone is already using. Ask Cursor a question about a research paper and it has to reach the web to answer. Slack, coding agents, anything with AI built in now carries search as a core component, because the AI is everywhere the human used to be. Building for that shift means building a search engine for an audience that isn't human: crawling the web, fine-tuning query embedding models, running custom vector databases, and packaging retrieved content into an API rather than a page of links. Exa was about 25 people when Nitya joined roughly a year ago, betting on agents becoming a growing share of who's actually doing the searching.
How search differs for agents
Four things separate search built for agents from search built for people. Latency spans a much wider range: a voice agent needs an answer in under 200 to 300 milliseconds, while a research task building a large list or enriching a CRM can trade speed for comprehensiveness and quality. Token efficiency matters in a way it doesn't for a person skimming a page: a site full of documentation has plenty of irrelevant content around the part that answers a given question, and pulling only the relevant segment avoids bloating an agent's context and paying for tokens it doesn't need. Comprehensiveness matters differently too, since a model can't memorize the web: a query like find every engineering professor at Berkeley isn't answered by the top ten links, it's answered by the complete list.
Exa ran into this directly while looking for everyone in a newly opened Singapore office who worked on AI search: a typical search surfaces results that are generally helpful around the topic, not the specific, complete list of people to reach out to. That's the fourth shift: treating the web less like a ranked list of pages and more like a database, where semantic search and structured extraction from each page matter more than keyword matching.
One sentence hides two jobs
Agent, a product Exa launched earlier that week, takes a query, runs autonomous web searches through a sub-agent harness, and synthesizes the results. It's built for large lists and CRM enrichment, the kind of comprehensive, monitored retrieval that go-to-market and finance teams (HubSpot among them) rely on.
Take a request like find every Exa employee who went to Harvard. Most capable models try to answer it as one search, effectively looking for "Harvard Exa employee" as a combined phrase. That doesn't work well, not because either half is hard for the model, but because a person's employer and their education often live on different pages under different names, with no single page containing the exact combined phrase. Answering it well means recognizing that the sentence is two separate jobs: discovery, an open-ended search for every Exa employee that benefits from exploring alternate queries and deciding where else to look, and verification, a narrow, bounded check of one candidate against one criterion.
Exa's architecture splits the two: a coordinator generates candidates, retrieval pulls evidence from the web, independent sub-agents verify each candidate against the criteria, and a final step assembles the supported results, with sources attached.
The biggest unlock for us in ensuring retrieval quality was the separation of the generator and verifier steps within our agent architecture.
Parallelize the checklist, not the thought
Splitting discovery from verification also splits where quality and cost get spent. Candidate generation is the exploratory half, so it runs on a more capable, more expensive model, since an omission here can't be fixed downstream. Verification is narrow by comparison: given one candidate and one criterion, a cheaper model can search for supporting evidence and return a bounded yes-or-no with that evidence attached, at a fraction of the reasoning cost.
That narrower step is where sub-agents earn their keep. Each candidate check runs independently, with no need for the working memory of any other check, which means all of them can run at once. The output shape is always the same: criterion met or not, plus evidence. The rule that falls out of that: use sub-agents for independent outputs running at scale, not for a single sequential chain of reasoning. The verifier step qualifies because no single candidate's check depends on another candidate's result; that lack of interdependence is what makes running them in parallel safe.
In practice, arriving at this design took real experimentation: swapping models in and out, testing different combinations, treating model selection as an ongoing decision rather than a fixed choice, since a cheaper or better model can show up at any time and change what the right split looks like.
The result reframes what a search is for. A user asks for a structured set defined by criteria, and the system decides how to generate candidates and prove which ones qualify. Ranked links become an input to that process, not the final product. As Nitya put it, "We're building for an audience of agents, not humans."
Exa frames itself as a Render enthusiast. And the shape of Agent's workload fits that well: an unpredictable number of independent verifier jobs fan out from a single query, each requiring its own compute, potential retries on failure, and a final aggregation step once everything resolves. That's the kind of pattern a workflow engine like Render Workflows is designed to handle: orchestrating parallel, fault-tolerant jobs that converge into one result. A name remains just a candidate until a verifier surfaces evidence for it, evidence the next step can then examine and build on.