Why They Abandoned RAG
The pitfalls the team hit are representative: the snippets recalled by vector retrieval lacked context, so the model pieced together answers from fragments and got them confidently wrong; no matter how the chunking strategy was tuned, there were always sacrifices; and when retrieval failed, the model didn't even know it was missing information. The new approach changed the thinking—organize the documents into a virtual filesystem and give the model tools like ls, cat, and grep, letting it decide like an engineer which directory to look in, which file to read, and what keyword to search. Retrieval shifts from "the system guessing what the model needs" to "the model going to find what it needs itself."
The General Significance of This Shift
Similar architectural migrations have appeared frequently lately, driven by the generational dividend of model capability: the previous generation of models needed the system to chew information up and spoon-feed it, and RAG was the optimal solution of that era; this generation's agentic ability is enough to navigate autonomously, and feeding it fragments actually limits it. The article is also honest about the new approach's costs: multi-turn tool calls are slower and more expensive than a single retrieval, and the quality of the file organization directly determines the ceiling—effectively trading the hard problem of retrieval engineering for the hard problem of information architecture. The real question to ask may not be "is RAG obsolete," but whether the model in your hands still needs to be fed at the mouth.
via: Hacker News