RAG is dead, right?? — Kuba Rogut,

If agentic file search makes RAG obsolete, what exactly has it replaced? Kuba Rogut approaches that question as a deployed engineer at turbopuffer, a full-text and vector search database built on object storage. His starting point is the growing role of hybrid retrieval tools in agentic search.

The opening contrast is familiar: social-media posts declare that RAG is dead and agentic file search is all anyone needs. Yet the Google search-interest chart Rogut presents rises in 2023, levels off through 2024, and accelerates around the middle of 2025. That chart establishes continuing interest, not retrieval quality or adoption. The more useful question is whether the debate has confused RAG with one particular implementation.

The narrow version of RAG embeds a corpus, searches it with a query embedding, and passes the returned content to an LLM. But retrieval-augmented generation does not prescribe vector search. Retrieval can use semantic similarity, BM25 full-text search, grep, glob patterns, regular expressions, or ordinary filters. The generation step receives whatever relevant context those methods find.

Agentic search has a similar naming problem. Claude Code and Codex make filesystem search a visible part of an agent’s work, so the term often becomes shorthand for grepping files. Rogut’s broader definition is an agent using tools to progressively find and reason over external context.

These definitions can coexist: an agent can retrieve semantic matches as one step in a larger investigation.

The loop is straightforward:

1. Search for potentially relevant material.
2. Read what the search found.
3. Assess whether it answers the question or leaves a gap.
4. Search again if necessary, then continue the task when the context is sufficient.

The distinguishing feature is the feedback between reading and searching. A result changes what the agent knows, which changes what it should look for next.

Cursor, which Rogut identifies as one of turbopuffer’s earliest customers, provides a concrete example. Its Securely indexing large codebases article describes how opening a codebase or branch prepares that code for semantic search: parse the files, split them into chunks, and compute embeddings.

Doing all that work independently for every developer would repeat much of the same computation. Imagine a team of a hundred engineers working across a few repositories. Their checkouts overlap substantially, even when their branches differ. Re-chunking, re-embedding, and uploading every shared file each time wastes that overlap.

The reuse mechanism separates detecting changes from finding an existing index worth reusing. Rogut summarizes this through Merkle trees, hash trees that expose differences in file contents. Cursor’s published implementation distinguishes Merkle-tree change detection from a derived simhash used to select a similar existing index. Once an index is reused, changed content is updated and unchanged chunks can retain their cached embeddings.

Security matters because a reusable team index may contain files a particular client does not possess. Rogut credits turbopuffer’s role in secure reuse; Cursor’s account explains the access boundary more specifically through content proofs that exclude results for files the client cannot prove it possesses. Reuse therefore avoids repeated work without making every indexed file available to every client.

Why maintain this infrastructure? Cursor’s Improving agent with semantic search evaluates what happens when semantic search is available alongside traditional search tools. On its internal Cursor Context Benchmark, Cursor reports 12.5% higher answer accuracy on average across models when semantic search is available. The published figure resolves Rogut’s spoken uncertainty between 12.5% and 13.5%. This is a vendor-reported internal evaluation, not a public benchmark.

Rogut highlights an almost 24% answer-accuracy improvement for the earlier Composer model, before Composer 2. That model-specific attribution comes from his presentation; the accessible article text reports a maximum of 23.5% without identifying the model. These are reported percentage improvements, not percentage-point changes.

The online A/B test measures different outcomes. Both groups used the same model, and the published report gives the following results:

The dissatisfaction result uses the group with semantic search as its baseline. It should not be restated as an identically sized decrease when the tool is enabled.

The smaller online effects do not contradict the larger codebase-question gains. Giving an agent a semantic search tool does not mean every request uses it, or that every request benefits from it. An aggregate test includes requests for which the added tool makes little difference, diluting the effect across the whole population.

Claude Code supplies a different design choice. In the historical account Rogut presents, Boris Cherny says early versions tried RAG with a local vector database and did not retain that approach. The displayed exchange describes agentic search as working better for Claude Code. It does not establish that semantic retrieval is unsuitable for every coding agent, nor does Rogut provide a detailed technical explanation for the decision.

The comparison becomes more useful when embeddings are understood as cached compute. Some work that an agent would otherwise perform while discovering a codebase can be moved into reusable preprocessing. Rogut illustrates this with Claude Code-like and Cursor-like traces: repeated runtime discovery on one side, upfront indexing followed by retrieval on the other. These are illustrative traces, not a controlled benchmark of the two products.

Consider the question: how does metadata filtering work in this codebase? A filesystem-based agent starts by finding candidate files, reading them, and deciding whether it has enough information. In a TypeScript repository, a first search might look like this:

grep -Rni --include='*.ts' -- 'metadata' src/

The output locates occurrences of a word; the agent still has to read the surrounding implementation and determine which matches explain filtering. It may need another search before it can answer.

That discovery repeats across sessions. Different developers can ask the same question on different days, and each agent may perform much the same search, read, and assessment cycle. Rogut describes roughly 6,000 tokens for the discovery sub-step in his illustration, not for an entire task or as a universal cost.

The indexed path moves some of that work earlier. Parsing, chunking, and embedding prepare the codebase for a lightweight runtime query such as How is metadata filtered?. The query returns relevant chunks for the agent to inspect, reducing the amount of discovery it must do from scratch.

The initial index is reusable, not maintenance-free. Its potential payoff is less repeated discovery, with corresponding token, latency, and cost savings; the example supplies no universal speedup or break-even threshold.

Rogut also reports that some turbopuffer teammates had started switching from Claude Code to Cursor because it felt faster, associating that experience with Composer 2 and semantic search. That is a team anecdote, separate from both the illustrative traces and Cursor’s reported evaluations.

The pattern being displaced is the simplest early RAG pipeline: perform one vector search, put its results in the context window, and generate an answer. Rogut associates that pattern with 2023 and early 2024. Among more sophisticated customers, he now sees agents making many retrieval calls across several reasoning steps, with performance gains and new product possibilities that he describes qualitatively.

In this design, semantic search and full-text search are tools the agent chooses as needed. It fetches context for the current question, reasons over the results, and uses what it learns to guide subsequent searches. Retrieval becomes part of reasoning rather than a fixed prelude to it. The system can therefore narrow or redirect its investigation instead of assuming that its first lookup found everything required.

Large context windows do not remove the selection problem. Rogut closes by recalling Jeff Dean’s discussion of long-context models: even an enormous context capacity leaves a need for staged retrieval, using lightweight mechanisms to narrow a much larger collection to the relevant material.

Rogut’s formulation of Dean’s point is that the goal is the right million tokens, not a trillion tokens at once. He reports customers with trillions of tokens represented in turbopuffer, while the useful subset for a particular task might be ten thousand, a hundred thousand, or a million tokens. Those are different quantities: the corpus available to search and the context worth supplying to the model. As context windows grow, the retrieval system still has to decide what belongs in them.