Building a Smarter AI Agent with Neural RAG

What should a search engine return for a request as simple as “shirts without stripes”? The difficulty becomes clearer by tracing how search acquired its strengths. In Will Bryk’s 1998 Google example, a search for Australia finds documents containing that word, while PageRank ranks authority using the web’s link graph. Matching words finds candidates; the structure of the web helps order them.

By 2021, GPT-3 offered a different interaction: a user could describe what they wanted in a paragraph, including linguistic subtleties, and receive a fitting response. Against that experience, Bryk’s Google example looked strange. A search for shirts without stripes returned images of striped shirts. The word without changed the intended result, but the results still matched the conspicuous nouns.

Bryk attributed the failure to keyword comparison. His goal for Exa was to combine transformer language understanding with search: understand both the request and the documents well enough to return what the user meant. He describes committing at least ten years to the problem and having spent four years on it by the time of the talk.

The initial investment went into research. Bryk recounts joining YC’s Summer 2021 batch, raising a couple of million dollars, and spending half on a GPU cluster. The team then spent a year and a half researching without talking to customers. He presents both choices with a warning against treating them as startup advice: founders should talk to users, even though this particular effort began with a difficult technical redesign.

The research question was whether GPT-3’s underlying approach—transformers and next-token prediction—could be applied to search. Bryk shows a W&B training plot and recalls a purple run as a breakthrough, one of several improvements emerging from experiments with datasets and transformer architectures. The plot marks a moment when the approach began to work; the talk does not specify the training objective or provide enough detail to reproduce that run.

Consider an illustrative corpus of a trillion web documents. An inverted index maps words to the documents containing them: the entry for brown, for example, points to documents where that word occurs. At query time, a traditional retrieval system can use those mappings to find and rank candidates. Bryk explicitly calls this a simplification of Google’s operation, rather than a complete description of its architecture.

The alternative is to represent each document with an embedding, a list of numbers learned by a model. The intended representation captures more than vocabulary: it can encode ideas, meaning, and how people elsewhere on the web refer to the document. Bryk’s scaling argument is that these representations can become larger and more expressive. Invoking the bitter lesson, he proposes training transformers on increasing amounts of high-quality data to produce better document embeddings. This is a direction for scaling the system, not a measured guarantee that a larger vector always retrieves better results.

At search time, the same distinction appears on the query side:

For shirts without stripes, embedding the whole request gives the representation a way to retain the relationship expressed by without. Bryk describes comparing that query embedding against the document embeddings; he does not specify the index structure or serving algorithm used to make that operation practical at web scale.

After a year and a half, Bryk reports that the resulting search engine returned shirts without stripes for that request. The example is deliberately simple, but the intended capability extends to paragraph-long queries whose constraints cannot be reduced cleanly to a few words.

Bryk dates the search engine’s launch to November 2022 and recalls an enthusiastic response on Twitter. The company was then called Metaphor; the Exa rename followed in January 2024. In his account, ChatGPT arrived two weeks after the launch and immediately changed the question facing the team. If people could ask a language model for information directly, where would search fit?

Try asking GPT-4, using only its stored knowledge, for cool personal sites belonging to engineers in San Francisco. Bryk’s point is that the requested collection may simply not exist in the model’s weights. Fluent language generation does not make those weights a complete directory of the web.

Bryk estimates GPT-4 at a couple of trillion parameters and less than ten terabytes of weights, versus over a million terabytes of web documents. Those are his rough capacity estimates: the GPT-4 Technical Report withholds model size. He adds that images and video increase the total further, describes the web as exabyte-scale, and connects that scale to the name Exa.

Freshness is a separate reason to retrieve. Even a model with enough capacity to retain a much larger collection would still face a web that changes continuously. The resulting retrieval-augmented generation loop is straightforward: the language model searches Exa for the personal sites, receives external results, and uses those results to compose its answer. Search supplies the information that generation alone cannot reliably supply.

Adding search to a language model leaves another design question: was that search engine built for the caller now using it? Bryk contrasts a human typing short queries, reading a few links, and caring about the results page with an AI system capable of issuing complex requests and rapidly analyzing much more information.

His criticism of simply attaching traditional search to AI is about the objective being optimized. A result that attracts a human click is not necessarily the most useful input to the next computational step. Here, AI means an AI product—the assistant and its surrounding workflow—not just a model considered in isolation. That product needs explicit control over what information comes back.

The first requirement is precision about the requested entities. Imagine a venture capitalist asking an assistant for startups working on something ambitious that feels like Bell Labs. The requested output is a list of startups. Pages that are interesting to click but do not identify matching companies create extra work for the agent. As the user refines the task, the agent might add New York City as a location constraint and then add further company qualities. Each search needs to preserve those constraints rather than loosely gesture at the topic.

The second requirement is searching with accumulated context. An assistant that has talked with someone all day may know enough to personalize restaurant or apartment recommendations. Its query could contain several paragraphs describing a software engineer’s preferences and asking for places that fit them. Compressing that context into a few keywords can throw away the information that makes the recommendation useful. Bryk contrasts Exa’s support for multiple paragraphs with what he tentatively describes as a few-dozen-keyword limit in Google; he does not establish an exact limit.

The third requirement is comprehensive retrieval. Bryk illustrates the difference with 10,000 pages: ten days of patient human processing versus three seconds for AI if parallelized. The comparison is illustrative, with no specified workload, hardware, or quality measurement. For investment research, the substantive requirement is finding all the companies in a space, rather than the 10 or 20 results he associates with ordinary search. He calls for APIs that can expose 1,000 or 10,000 results and apply semantic constraints such as every YC-funded startup working on AI. Large result counts make broader analysis possible, but the talk supplies no recall measurement establishing that every matching company was found.

Bryk maps these demands as subsets inside a larger circle of possible queries. Familiar keyword lookups occupy one region: Stripe pricing, someone’s GitHub page, or Taylor Swift’s boyfriend. After 2022, conversational models made another region commonplace: explain a concept to a five-year-old, or debug the code supplied in the prompt. Those requests can be useful without requiring web search at all.

Semantic retrieval adds requests such as finding people in San Francisco who know Assembly. Bryk credits Exa with helping introduce this style of query, qualifying that claim with his own awareness of the field. A further region contains requests such as finding every article that argues X and not Y, written by an author like Z. He describes Exa’s Websets product as beginning to handle such combinations.

That last region suggests treating the web as a database that can be filtered according to the user’s intent. The ambition is broader than any one search mode, and Bryk acknowledges that new kinds of requests still arrive that no available search engine can handle. The destination is one API capable of supplying an agent with keyword results, semantic matches, and increasingly complex collections of knowledge. Supporting every possible query remains the eventual goal.

The live demonstration begins in Exa’s search dashboard. A query produces both a list of results and code showing how to make the request. Controls expose result counts, date ranges, and domain restrictions. Bryk describes counts of ten, a hundred, or a thousand: many toggles may look excessive for a human interface, but they give a calling agent ways to express the actual retrieval task.

The dashboard also exposes neural and keyword search. These are the historical controls used in the demonstration. For implementation today, the Search API reference, checked in August 2026, documents a default of 10 results, a public maximum of 100, and higher limits by arrangement. Its current contract should not be inferred from the older dashboard.

Bryk then opens agent.py, containing an agent called Mark that formats information as Markdown. The first request asks for a personal site belonging to an engineer in San Francisco who likes information retrieval. He selects neural search because the task describes a combination of attributes rather than naming a known destination. After a save and wrong-agent execution interruption, he describes the intended run: retrieve matching personal sites, then have Mark turn the results into Markdown.

The next request is Will Bryk GitHub. This time, Bryk explicitly switches to keyword search. The person and destination are already named, so the retrieval task is closer to a conventional lookup. The two demonstrations separate finding an unknown person who meets a description from finding a known person’s page.

The keyword demonstration returns information about Will Bryk’s GitHub. From there, the useful unit of design becomes a sequence of searches, rather than a single mode chosen for the entire agent. A system could use neural search to discover a list of entities and then use keyword search to resolve a particular page for each entity. The user’s request determines which retrieval operation is needed at each step.

Bryk demonstrates that composition with a GitHub agent he says he generated in one shot using o3. Its task is to find GitHub information for engineers in San Francisco who like information retrieval:

1. Run a neural search for the matching personal sites.
2. Extract people’s names from the results.
3. Run a keyword search for each name and GitHub.

The first step discovers the cohort; the later lookups resolve a destination for each discovered person.

In Python, that orchestration can be expressed with separate search and name-extraction operations. Keeping the operations separate makes the change in query type explicit:

from collections.abc import Callable
from dataclasses import dataclass


@dataclass(frozen=True)
class SearchResult:
    title: str
    url: str
    text: str


Search = Callable[[str, int], list[SearchResult]]
ExtractNames = Callable[[list[SearchResult]], list[str]]


def find_github_profiles(
    neural_search: Search,
    extract_names: ExtractNames,
    keyword_search: Search,
    people_limit: int = 10,
) -> str:
    query = (
        "personal sites of engineers in San Francisco "
        "who like information retrieval"
    )
    personal_sites = neural_search(query, people_limit)
    names = extract_names(personal_sites)

    markdown = ["# GitHub search results"]
    for name in names:
        matches = keyword_search(f"{name} GitHub", 1)
        markdown.append(f"\n## {name}")
        if matches:
            match = matches[0]
            markdown.append(f"[{match.title}]({match.url})")
        else:
            markdown.append("No result returned.")

    return "\n".join(markdown)

The supplied operations handle retrieval and extraction; the function carries names from semantic discovery into explicit keyword requests and formats the returned links. A returned link is still a search result: this sequence contains no additional identity-verification step.

The live GitHub-agent run requests ten results; Bryk says a hundred or a thousand are available on an enterprise plan. He then shows the agent gathering GitHub information. The demonstration establishes the composed workflow, rather than an exhaustive enumeration of every engineer who fits the description.

The closing announcement moves that orchestration one level higher. Bryk says Exa launched a Research endpoint that day: instead of asking the caller to coordinate each individual retrieval, the service would perform searches and language-model calls in the background to produce a report or structured output. He describes it as a deep research API and calls it state of the art, without presenting an evaluation. The architectural shift is from an agent requesting individual pieces of evidence to an agent requesting a research result, with the search-and-synthesis loop running behind the API.