Your Coding Agent Is 6 Months Out of Date — Jakub Hojsan, Exa
Jakub Hojsan, a forward deployed engineer at Exa, explains how search built for coding and code-review agents closes the gap left by model knowledge cutoffs. He covers why agents need explicit rules for when to search, how query-dependent highlights cut a 100,000-character page to about 500 characters without added latency, and how Exa compares with native web search on transparency, cost, and model-provider independence, with a preview of Exa Agent.
Coding and code-review agents run into a basic problem: every model is frozen at a knowledge cutoff, and in practice that cutoff trails the release date by roughly six months. Any repository change made in that window is invisible to the model, even though it still has to be reviewed. Jakub Hojsan, a forward deployed engineer at Exa, explains how Exa built search for these agents, why adding a web search tool to an agent is not sufficient, and how query-dependent highlights keep the context small enough to be useful.
The knowledge-cutoff gap in code review
Models typically ship about six months after their knowledge cutoff, which leaves a window of changelogs, dependency bumps, and pull requests that land in repositories the model has never seen. An agent reviewing those changes is working blind. In one example, a pull request to a vector store integration made a few months earlier falls after the cutoff of GPT-5.5. The diff looks like a harmless cleanup: a parameter is removed and the surrounding code is consistent. Without outside information, a model would approve it. The actual reason for the removal is a dependency bump that requires a migration, and the breaking changes are documented in the upstream repository’s changelog.
A human reviewer would handle this the way they handle any unfamiliar error. They search for the failing symbol, read the Stack Overflow answer or the project’s documentation, and only then write the fix. The model needs the same ability.
Web search alone is not enough
Giving an agent a search tool does not mean it will use that tool well. Even Claude Code, which has a built-in web search, will tell users that a model version such as Sonnet 4.6 or 4.7 does not exist, because the model does not know that newer versions have been released. The tool is present, but the model has no signal for when to reach for it.
Making search work takes two steps: instructing the agent when to search, and then executing the search well. For a code review agent, the rule might read: when a diff bumps a dependency or version, verify the change against the upstream source and ground the review in what you find there. Teams that add a search tool to their harness often discover that writing these rules is the part that actually matters.
Query-dependent highlights instead of full pages
Exa does not return whole pages. A query-dependent highlight extracts only the snippet relevant to the question. For a migration question, the response is the section of the repository page that explains the breaking change, not the entire GitHub page. The model receives roughly 500 characters where a naive approach would pass 100,000.
The extraction does not involve an LLM. It selects lines from the page at runtime, which adds no latency to the search call. The same page can yield different highlights for different queries: a biography page returns hobbies for one question and a phone number for another. The technique is not specific to code. It works the same way for pulling the latest news about a company that mentions a particular executive, or for finding one function inside a repository with millions of lines.
Transparency, cost, and provider independence
Native web search from OpenAI or Anthropic works as a black box. The provider runs the search, synthesizes results over as long as ten seconds, and returns some sources but not the content it actually used. Exa exposes the full trace: the queries issued, the sources visited, and the highlights passed to the model. That trace can be fed into telemetry when something goes wrong.
On cost, native search charges are often buried inside model bills. At sufficiently large volumes, Exa is priced more effectively, and in most cases the quality is better, according to Hojsan. Finally, a third-party search API stays constant while model providers change. The same API and parameters work whether the agent runs on a new Anthropic, OpenAI, or GLM model, so switching models does not require rebuilding the search layer.
Exa Agent and broader use cases
Exa already powers coding and developer tools, including Cursor, Cognition, Warp, and CodeRabbit. Exa Agent extends the same approach to teams that do not want to orchestrate their own search but still need strong results. It combines web search with data partners: SimilarWeb for web analytics, Particle for podcast intelligence, and Crunchbase for private-market data. Large financial firms and hedge funds use it for this kind of information.
In a demo, a query for people attending the AI Engineer conference returned posts from people who had mentioned the event at that location, including many of the speakers. The same pattern applies to finding a company’s employees along with their emails and LinkedIn profiles for outbound work.
Getting started
Exa is available through its MCP server, which is supported by most major clients, so an agent can start calling it without a custom integration.
Ranking at scale
Asked how ranking works across billions of documents, Hojsan described a multi-stage pipeline. The query is converted into an embedding, keyword filtering runs alongside semantic search, and rerankers order the candidates while irrelevant results are dropped. The index is highly curated, so it holds far fewer documents than Google’s but aims for very high quality across tens of billions of documents.
Structured output schemas
Exa can generate an output schema from natural-language instructions. Deep search supports up to 10 fields and agent workflows up to 100. Users describe the fields they want, confirm the generated schema, and the output adheres to it. Additional properties can be enabled when the schema should allow open-ended fields. Hojsan’s favorite example is extracting hobbies from a profile.