Agentic Information Retrieval

Welcome to a deep dive on agentic information retrieval. This is the reading path behind a collection I’ve been building: nineteen papers that trace a single idea from its roots to its frontier. The idea is this. For most of the last decade, retrieval meant similarity. You turned a query into a vector, you turned every document into a vector, and you found the documents that sat closest in space. Fast, cheap, and for a huge class of questions, good enough. But there’s a different bet being made right now, and it’s the reason this collection exists. The bet is that the best way to find the right document is not to embed harder. It’s to think. To spend real computation at the moment of the search, reasoning about what the query actually means and whether a candidate truly answers it. That’s the thesis behind SID’s recent technical report, which they title, plainly, test-time compute for retrieval. And what’s striking is that this isn’t one company’s pitch. It’s the convergence point of a whole line of research. So let’s walk that line, from the foundations to the open edge.

Start with the foundations, because you can’t appreciate where this is going without seeing what it’s replacing. In 2020, a paper called Dense Passage Retrieval did something that sounds obvious now and was contested then. It trained two neural encoders, one for questions and one for passages, so that a question and its answer would land near each other in vector space. And it beat BM25, the venerable keyword-matching baseline, on open-domain question answering by a wide margin. That’s the moment dense retrieval stopped being a research curiosity and became the default. Every retriever we’ll talk about descends from it.

The same year, another paper gave the architecture its name: Retrieval-Augmented Generation. The move was to take a language model that generates text and bolt onto it a retriever that fetches passages from a big external index. The model no longer had to memorize all the world’s facts in its weights. It could look them up. That’s RAG, and if you’ve touched anything in applied AI in the last few years, you’ve touched RAG. It’s the scaffolding the entire field now builds on. There’s a survey in the collection, from late 2023, that maps the whole RAG design space, naive to advanced to modular, and it’s the reference I’d point anyone to for where a given technique fits.

But I want to flag one more foundational paper, because it’s the first crack of light for everything that follows. It’s called HyDE, hypothetical document embeddings. The problem it tackled was zero-shot retrieval, retrieval with no labeled training data for your domain. And the trick was beautiful. Instead of embedding the user’s query directly, you ask a language model to hallucinate a fake answer. A made-up document that would, if it were real, answer the question. Then you embed that fake document and use it to find real ones nearby. Think about what that means. The language model’s generation, its reasoning about what a good answer looks like, is being injected into the retrieval step itself. The query is no longer a static string. It’s the product of a model thinking. HyDE was 2022, and in hindsight it’s the hinge. It’s the first place where generation and retrieval stopped being separate stages and started to blur.

That blurring is the whole second act, which I think of as agentic search loops. Here retrieval stops being a thing you do once, up front, before the model runs. It becomes an action the model chooses to take, in the middle of its reasoning, as many times as it needs.

The paper that crystallized this is ReAct, reasoning and acting. The insight was to interleave chain-of-thought reasoning with tool use, in a loop. The model thinks a little, decides to take an action like a search, reads the result, thinks again, and continues until it’s done. Once you’ve seen that pattern you see it everywhere, because it’s the pattern under basically every search agent shipping today. Retrieval is an action the model decides to take, conditioned on what it’s figured out so far. That’s a profound shift from the RAG default, where you retrieve once with the raw question and hope the top results are enough.

A companion paper, IRCoT, made the same point specifically for multi-hop questions, the ones where you have to chain several facts together. It interleaved retrieval with each step of the chain of thought, using the partial reasoning to write the next query. And the lesson was clear: hard, multi-step retrieval has to be guided by reasoning and done iteratively. One shot won’t cut it. You can already feel reasoning-intensive retrieval being born here.

Then two papers pushed on the control question, the question of when to retrieve at all. FLARE, active retrieval-augmented generation, had the model watch its own confidence as it generated. When it was about to say something it wasn’t sure about, it paused and retrieved, using the sentence it was trying to write as the query. Retrieval on demand, triggered by doubt. And Self-RAG went further: it trained the model to emit special reflection tokens, little control signals that decide when to go retrieve, and then critique whether the passages it got back are actually relevant and actually support the claim. That’s retrieval control and self-criticism folded directly into the model’s own decoding. And notice, that’s the model spending extra computation, at inference time, to manage its own retrieval. We’re inching toward the thesis.

The most recent papers in this act make the loop the explicit training target. Search-R1 uses reinforcement learning to teach a model to interleave reasoning with live calls to a real search engine, learning, end to end, when to search and what to ask for, optimized directly against getting the final answer right. It’s the o1 and R1 reasoning-RL recipe, the same family of methods behind the reasoning models everyone’s talking about, pointed straight at search. And MCTS-RAG brings in Monte Carlo Tree Search: it explores a tree of interleaved reasoning and retrieval steps, and by doing that search over paths, it lets a small model punch up to the level of a frontier model on knowledge-heavy tasks. That phrase, scaling inference-time compute, is exactly the lever we care about. Spend more compute when you search, get better answers. Even from a small model.

Which brings us to the third act, and the part of the collection I find most clarifying: reasoning-intensive retrieval. Because there’s a category of query where the old similarity bet just breaks. Not because the embeddings are bad, but because relevance itself isn’t about surface similarity. The connection between the question and the right document runs through a chain of inference. Think of a coding error whose fix lives in documentation that never mentions the error. Or a math problem whose solution depends on a theorem stated in completely different words. The right document and the query barely share any vocabulary. Their relationship is logical, not lexical.

The paper that nailed this down is BRIGHT, a benchmark released in 2024 built entirely from these reasoning-intensive queries. And the headline result is brutal for the old paradigm: standard retrievers, even strong dense ones, score poorly. The thing that made retrieval work for a decade, semantic similarity, is precisely the thing that fails here. BRIGHT is the yardstick that made the rest of this act necessary, because once you can measure the gap, you can try to close it.

And researchers did. ReasonIR, from 2025, is the first retriever trained specifically for reasoning tasks. They built a synthetic data pipeline that generates genuinely hard queries paired with hard negatives, documents that look related but don’t actually help, and trained on those. It set a new state of the art on BRIGHT. But here’s the detail that ties it back to the thesis: ReasonIR uses test-time compute more effectively. Give it a longer, richer, rewritten query, the product of more reasoning, and its performance keeps climbing. The retriever itself rewards thinking harder at search time. RankRAG, meanwhile, came at it from another angle, instruction-tuning a single model to both rank the contexts and generate the answer, collapsing two stages that used to be separate components into one. And there’s a 2026 survey in the collection that systematizes this entire subfield, reasoning-intensive retrieval, organizing the benchmarks and laying out a taxonomy of where, exactly, reasoning can enter the retrieval pipeline. It’s the roadmap for the territory SID-1 is staking out.

So now we arrive at the fourth act, the destination: test-time compute for ranking. This is the thesis stated outright, as a body of work.

The keystone paper is Rank1, from early 2025. And the title is almost the whole story: test-time compute for reranking in information retrieval. What they did was train a reranker, the component that takes a handful of candidate documents and decides their order, to actually reason before it scores. They distilled hundreds of thousands of reasoning traces from frontier reasoning models, the o1s and R1s, so that a much smaller reranker learns to think step by step about whether a document is relevant, and only then assigns its score. Three things came out of that. It hit state of the art on the hard reasoning and instruction-following retrieval benchmarks. It generalized remarkably well to data it had never seen, because it could respond to instructions in the prompt rather than relying on a fixed notion of relevance baked into an embedding. And, crucially, it produced an explainable reasoning chain for every ranking decision, something you can show a user, or hand to a downstream RAG system as evidence. Rank1 is the clearest academic statement of the idea SID-1 is productizing: a fundamentally new kind of reranker, one whose quality scales with the compute you let it spend at the moment of the search.

If you’re skeptical, the natural worry is cost. Reasoning is expensive. Does this only work with a giant model? The answer, from a paper sometimes called InteRank, is no. They distilled and then reinforcement-tuned reasoning into a three-billion-parameter reranker, tiny by today’s standards, that generates a relevance explanation at inference time. And it placed third on the BRIGHT leaderboard, beating models more than twenty times its size. The win survives compression. You can have a small, cheap, fast reranker that still reasons, and still explains itself. That’s what makes the whole approach practical rather than a luxury.

The newest papers in the collection sketch where this goes next. Verbal-R3 frames a verbal reranker, one that reasons in natural language, as the missing bridge between retrieval and generation, instead of just dumping raw passages into the model’s context and hoping. GRC goes for the most ambitious unification: one model that handles reasoning-driven generation, retrieval, and compression together, sharing its training across what used to be separate embedding and generation tasks. It points at a future where the retriever and the generator aren’t even different things. And RICE-PO takes on what I think is the deepest unsolved problem here. When you have an agent that reasons, queries, reads, reasons again, and re-queries, you can measure whether the queries were good, but how do you assign credit to the reasoning steps in between, the latent thinking that shaped which queries got asked? RICE-PO turns the retrieval interactions themselves into localized learning signals for those hidden reasoning steps. It’s an opening move on the training problem that, frankly, the whole agentic-retrieval program is going to live or die on.

So let me pull the arc together, because that’s the point of reading these in sequence. We went from dense retrieval, similarity in vector space, to RAG, looking things up instead of memorizing them. Then HyDE slipped generation into the query, and the agentic loop papers, ReAct, IRCoT, FLARE, Self-RAG, Search-R1, MCTS-RAG, turned retrieval into a repeated action the model reasons its way through. Then BRIGHT proved that for a whole class of queries, similarity simply isn’t enough, and ReasonIR and the reasoning-intensive crowd built retrievers that think. And finally Rank1 and InteRank made it concrete and cheap: rerankers that spend test-time compute, reason explicitly about relevance, and explain themselves. That’s the through-line. Retrieval is becoming a reasoning problem, and reasoning costs compute, and the field is deciding that the compute is worth it.

I’ll leave you with the open problems, because that’s where the collection actually points. First, nobody yet routes test-time compute by how hard the query is. We spend reasoning uniformly, when we should detect when relevance is genuinely inferential and only pay the reasoning cost then. Second, credit assignment for the latent reasoning inside a retrieve-reason agent is barely solved; RICE-PO is a first step, not a finish. Third, almost all of this is English and text-only, while the queries that most need reasoning, code, mathematics, scientific literature, multimodal data, are exactly the ones we have the fewest trained retrievers and benchmarks for. Fourth, the boundary between retriever and generator is dissolving, and nobody has measured the real cost and latency tradeoffs of erasing it versus keeping a clean separate index. And fifth, these systems now produce a reasoning chain for every decision, and we mostly throw it away, instead of showing it to the user or feeding it forward as grounded evidence.

That’s the map. Dense retrieval got us here. Test-time compute is what’s taking us forward. And the most interesting question in retrieval right now isn’t how to embed better. It’s how much thinking a search is worth. Thanks for listening.

Welcome back to the agentic information retrieval reading path. This is episode two, and if episode one was the theory, this one is the field test. Last time we walked a single idea from its roots to its frontier: the bet that the best way to find the right document is not to embed harder but to think. We traced it from dense passage retrieval, where you turn a query into a vector and find its neighbors, through retrieval-augmented generation, where you bolt that index onto a language model, through HyDE, where the model hallucinates a fake answer and retrieves real documents near it. Then we watched retrieval stop being a thing you do once, up front, and become an action the model chooses in the middle of its reasoning: ReAct, IRCoT, FLARE, Self-RAG, Search-R1, MCTS-RAG. And we ended on the hard cases, the reasoning-intensive queries where surface similarity simply breaks, and on the rerankers that spend real test-time compute to judge relevance: BRIGHT as the yardstick, ReasonIR as the retriever that rewards thinking, Rank1 and InteRank as the rerankers that reason before they score. The through-line was simple to say and expensive to do. Retrieval is becoming a reasoning problem, and reasoning costs compute, and the field is deciding the compute is worth it.

That was the lab. Today we go to work. Because none of that thesis matters until it lands in a product that someone depends on, and the moment it lands, the domain pushes back. Each domain has its own physics. The thing that makes retrieval hard in a codebase is not the thing that makes it hard in a support queue, and neither is the thing that makes it hard for an agent that knows you personally. So the plan for the next forty-odd minutes is to take the advances from episode one and run them through three real worlds, in order. First, coding agents, which is the deepest movement, the place the most money and the most measurement are pointed right now. Then support and customer-service agents, where the cost of being confidently wrong is a refund or a lawsuit. And finally personal agents, where the retriever and the memory start to become the same thing. For each, I want the same three questions: what does this domain actually demand, what is genuinely new in the last year, and where does it break. Let’s start in the codebase, because that is where the thesis is being stress-tested hardest.

Here is the first thing to understand about code retrieval, and it is the load-bearing fact for everything that follows: code is not text with a different vocabulary. The CodeSearchNet benchmark named the core problem back in 2019, and it never went away. A developer’s query and the snippet that answers it often share almost no words. You search for “retry with backoff” and the function is called scheduleAttempt, with a loop and a sleep and an exponent, and the word “backoff” appears nowhere. Worse, code has an open vocabulary; programmers coin new identifiers endlessly, so the off-the-shelf text embedding chokes on the very tokens that matter most, the rare ones. And the meaning you actually want lives in structure that text retrieval throws away: who calls this function, where does this value come from, what breaks if I change this signature. That is data flow and control flow and the call graph, and a cosine distance between two vectors cannot see any of it. So from the very beginning, code retrieval has been a different animal. The lineage that tried to tame it ran from CodeBERT, the bimodal encoder trained on comment-and-code pairs, through GraphCodeBERT, which injected data flow and got the first clean win for structure over tokens, through CodeT5 and UniXcoder. That is the embedding lane. Hold it in mind, because it is exactly the lane that a surprising number of frontier coding tools just walked away from.

Let me tell you the most striking thing that happened in this space in the last year, because it cuts directly against the embedding-everything instinct. In May of 2025, Anthropic took vector search out of Claude Code. They removed the embedding pipeline, the local vector database, the chunking heuristics, all of it, and replaced it with grep. The agent gets filesystem tools, glob to match file patterns, grep to search contents, read to load a specific file, and it explores the codebase on demand, the way a human engineer would, opening things, reading them, searching again. The reason was not ideology. It was measurement. The engineers said, plainly, that agentic search outperformed the RAG version by a lot, and that the margin surprised them. And it was not one team’s quirk. Over the following months, Windsurf, Cline, Devin, and Sourcegraph’s Amp all dropped vector search for tool-driven search. Sourcegraph specifically retired Cody’s embeddings in favor of an adapted keyword index over their code graph, citing the operational pain of shipping a customer’s proprietary code off to an embedding service, the cost of maintaining a vector database, and the way embeddings scale badly past a hundred thousand repositories. And in February of 2026, a team at Amazon Science put a number on the intuition: across a battery of retrieval tasks, agentic keyword search hit over ninety percent of full RAG performance with no vector database at all.

Now, why would that be true? Why would letting a model drive ripgrep in a loop beat a carefully trained embedding index? This is where episode one pays off, because the answer is the agentic-loop thesis applied to code. The embedding index is frozen. It was computed at some point in the past, on some snapshot of the repo, with some chunking strategy, and it gives you a fixed similarity ranking no matter what the question is. The agent, by contrast, reasons. It reads the error message, forms a hypothesis, greps for a specific symbol, reads what it finds, realizes it’s in the wrong module, and greps again with a better term. That is ReAct in a codebase. Retrieval is an action it decides to take, conditioned on what it has figured out so far, against the live source rather than a stale vector. On a codebase that changes every single commit, a search that runs against ground truth and reasons its way to the answer beats a search that runs against a memorized approximation. The grep-in-a-loop crowd is not being lazy. They are spending test-time compute on navigation instead of paying it up front on indexing, and on code, where freshness is everything, that trade has been winning.

But here is where it gets genuinely interesting, because the field did not actually converge on grep. It split. While Anthropic and the agentic crowd were tearing out embeddings, Cursor went the other direction and doubled down. In November of 2025 they published their results from training their own code embedding model, and the headline is that semantic search improved their agent’s accuracy across every frontier model they tested, by an average of twelve and a half percent, ranging from six and a half up to over twenty-three percent depending on the model. And crucially, the gains were largest exactly where grep is weakest: in big codebases with inconsistent naming and legacy patterns, the places where the word you’d search for isn’t the word that’s actually in the code. The vocabulary-mismatch problem, the one CodeSearchNet named in 2019, is still there, and grep does not solve it. If the function is called scheduleAttempt and you search for “retry,” ripgrep returns nothing and the agent has to get lucky with its next guess. Semantic search returns it anyway. So Cursor’s bet is that you give the agent both, and let the embedding catch the cases where lexical search comes up empty.

And the way they trained that embedding model is itself a lovely instance of the episode-one thesis, so let me dwell on it. They used the agent’s own sessions as training data. When the agent works through a task, you can look back at the trace afterward and see what it eventually needed, what file it should have opened on turn two instead of turn nine. So they take those traces, hand them to a language model, and have it rank which content was actually helpful at each step. Then they train the embedding model to make its similarity scores agree with that LLM-generated ranking. That is the same move HyDE made, just relocated. The reasoning of a language model is being baked directly into the retriever. The embedding is no longer trained on a generic notion of “these two strings look similar.” It’s trained on a model’s judgment of “this is what a competent agent would have wanted here.” That is reasoning-intensive retrieval, in the precise sense episode one defined it, compiled down into a fast vector lookup. ReasonIR proved you could train a retriever to reason; Cursor is doing it in production, supervised by agent trajectories.

GitHub Copilot sits in roughly the same camp, and added its own wrinkle this year. Copilot’s coding agent uses semantic code search to find conceptually related code, so you can describe a login bug in plain English and it surfaces the authentication middleware without your knowing the file path. The interesting part is operational: in March of 2026, GitHub shipped pre-indexing, parallel context loading, and session-level caching that cut the agent’s initialization time roughly in half on typical enterprise codebases. That matters because it names a cost the academic papers mostly ignore. When your agent boots a fresh virtual machine, clones a giant repository, and has to build up its context before it can do anything useful, the indexing latency is a real tax on every single task. So one frontier of code retrieval right now is not “find the right file” at all, it’s “amortize the cost of being ready to find the right file” across thousands of agent runs against a repo that is also changing under you.

Step back and look at this disagreement squarely, because it is the most clarifying thing in the whole movement. You have two camps, both serious, both with numbers, reaching opposite conclusions. The agentic-grep camp says embeddings are a stale liability and a live model with search tools wins. The trained-embedding camp says grep can’t bridge the vocabulary gap and a retriever taught by agent traces wins. And the resolution, the thing almost everyone actually ships, is that they are both right and the answer is hybrid. There’s a nice line going around that the grep replacement for AI agents is three tools, not one: give the agent lexical search for exact symbols and rare identifiers, semantic search for intent and concepts, and structural or graph search for relationships, and let it choose per question. This is exactly the additive-ladder picture from the code-retrieval literature: lexical owns rare-token recall, dense embeddings own intent, graph methods own behavior, and no single mode suffices, so everyone ends up hybrid. The argument was never really grep versus vectors. It was about which tool is the default and which is the fallback, and the field is settling on: let the agent decide.

Now let me push into the part of code retrieval that I think is the most underrated, because it is where structure comes roaring back: localization. In an enterprise codebase, the hard problem is usually not generating the fix. It’s finding where the fix goes. The bug manifests in one file and the cause lives three import hops and a config file away, and flat similarity retrieval will never get you there, because the symptom and the cause don’t look alike. The reading path has a striking number on this. KGCompass, from 2025, builds a repository-aware knowledge graph linking issues and pull requests to the actual code, and then narrows a bug down to around twenty candidate functions. The number that should stop you is this: sixty-nine point seven percent of the bugs it correctly localized required multi-hop traversal of that graph to find. More than two thirds of real fix sites are not reachable by looking at what resembles the symptom. They’re reachable only by walking the structure, call edge by call edge. And it did this at about twenty cents a repair, hitting roughly forty-six percent on SWE-bench Lite. LocAgent makes the same case from a different angle: parse the codebase into a heterogeneous graph, do multi-hop reasoning over it, and you get ninety-two point seven percent file-level localization and a double-digit lift in issue resolution, about eighty-six percent cheaper with a fine-tuned thirty-two-billion-parameter model. The lesson generalizes. The agentic-grep crowd is right that a model with search tools beats a frozen index, but the model navigates faster and cheaper when the thing it’s navigating is a structured world rather than a flat pile of files.

That insight is now turning into benchmarks, which is how you know a field is getting serious, and two from 2026 are worth naming because they reframe the whole problem. The first is SWE-Explore, which isolates repository exploration as its own task. Forget writing the patch; just measure whether an agent, given an issue and a repo snapshot, can return a ranked list of the line-level code regions that matter, under a fixed budget. It spans eight hundred and forty-eight issues across ten programming languages and two hundred and three repositories, and the ground truth is clever: they distilled it from independent successful agent trajectories, keeping a region only when at least two separate runs that actually resolved the issue both touched it. That sidesteps the contamination problem that haunts code benchmarks. And the headline finding maps directly onto the camps we just discussed: agentic explorers form a clear tier above classical lexical and dense retrieval. File-level localization is basically a solved problem for modern methods. The remaining headroom is line-level precision and efficient ranking. Knowing the file is easy now; knowing the exact lines, cheaply, is the frontier.

And once you grant that agentic exploration beats the frozen index, a new cost shows up that the embedding world never had to pay: the agent wanders. Every grep that comes back empty, every file opened and discarded, every wrong hypothesis is real compute and real latency, spent on navigation rather than on the actual task. A 2026 field study put numbers on it by analyzing seven thousand and twelve Claude Code sessions, and the finding is that giving the agent a formal architecture descriptor, a compact map of how the codebase is laid out, cut navigation by thirty-three to forty-four percent, with a large effect size and a fifty-two percent drop in the variance of how many steps a task took. The variance number is the one that matters operationally, because unpredictable agents are hard to budget for. And there’s a counterintuitive design lesson buried in it: the best format for that map is the one that fails safely when the agent misreads it, not the one the language model says it prefers. Undirected exploration is a measurable tax, and the fix is to hand the agent a cheap structural prior before it starts thrashing. That is the same insight as the localization work, one level up: structure doesn’t just help you find the fix site, it stops the agent from getting lost on the way there.

The second benchmark goes even harder at the assumption that code retrieval is query-to-snippet matching, and it’s the one I’d point a skeptic to. CORE-Bench, also 2026, reframes retrieval for agentic coding as requirement-driven repository search. A real development request, “add rate limiting to the upload endpoint,” carries an enormous gap between the intent and the implementation, and the evidence you need is scattered, some in code, some in configuration, some in a dependency, some in the docs. It is never sitting in one tidy function. So they ground every query in a repository snapshot checked out to the commit right before the relevant pull request, score you on retrieving all the chunks an edit touches plus the surrounding context an agent would browse, and they do it at scale: six hundred and thirty-two repositories, nine point three eight million chunks at their hardest level. And here is the result that should reorder your priors. Embedding retrievers that look excellent on traditional code search collapse on the agentic levels. One strong open model, Qwen3-Embedding-8B, scores seventy-one point seven on the easy level and falls to twenty point three and thirty-four point four on the harder, agentic ones. In-domain fine-tuning on pull-request supervision helps at every difficulty, but recall still degrades as the corpus grows larger and denser. The takeaway is blunt: the code-search scores everyone has been quoting for years overstate how useful a retriever actually is to a working coding agent. We have been measuring the wrong thing, and the new benchmarks are built to stop us.

Now layer in enterprise scale, because that’s where my own day job lives, and scale doesn’t just make these problems bigger, it changes which problems exist. Google’s monorepo is something like two billion lines of code, nine million files, forty thousand commits a day. You cannot do a linear search at query time, and you cannot fully re-index per change. The real production systems are an escalation ladder: grep at the bottom, then a trigram index like Zoekt, then a semantic index like Kythe, then incremental build-integrated indexing like Glean, then cross-repository precise navigation like SCIP. And the single most important property at that scale is one the academic benchmarks almost never test: freshness. There’s a 2026 diagnostic in the reading path, from Weng and colleagues, that nails this. They ran a controlled experiment where they hid commit timestamps so the system would retrieve from stale context, and the result is that stale retrieval is actively net-negative. It injected obsolete API references in fifteen of seventeen samples in one condition, thirteen of seventeen in another, with double-digit-percentage-point drops in correctness. Serving stale context was worse than serving no context at all. That reframes retrieval as a two-variable problem. It’s not just “is this relevant,” it’s “is this still true.” A companion line of work, DocSync, names the same hazard in documentation: drift that is, in their words, functionally lethal yet passes the linter, where the code changed and the doc didn’t, and a retriever that faithfully serves the doc faithfully serves a lie. Temporal validity is its own retrieval dimension, and almost nobody outside industry is gating on it.

And then there is the kind of context that isn’t in the repository at all, which is, I think, the deepest enterprise problem in the whole movement. The reading path has a result that crystallizes it. A 2026 paper measured what happens when you give a coding agent a dedicated product-context retrieval system, separate from the code, that holds decisions, specs, the reasoning behind why something is the way it is. On decisions that were visible in the codebase, the agent was already at a hundred percent. On decisions that depended on product context, the tribal knowledge that lives in a person’s head or a Slack thread or a design doc, the agent scored between zero and thirty-three percent without that system, and forty-six to ninety-five percent with it. The “why” of a decision is never in the source. It’s in people. And it turns out that “why” is retrievable, if you build a separate substrate for it, and retrieving it measurably changes how the agent behaves. This is the part of code retrieval that has nothing to do with code, and it’s where I think the real enterprise value is going to accrue, because every company’s hardest context is the context it never wrote down as code.

There’s a tempting shortcut lurking under all of this that I should address head-on, because the long-context crowd keeps proposing it: if the models can read a million tokens now, why retrieve at all? Just dump the whole repository into the context window and let the model sort it out. The reading path has the receipts on why that doesn’t work, and they’re worth carrying into the other domains too. The first is RepoQA, which runs a searching-needle-function task over long code context across fifty repositories and five languages, and its lesson is that capacity is not comprehension. Models that can technically ingest the whole repo still fail to find and use the one function that matters, and in a result that should give the dump-everything camp pause, they often understood the code better with the comments stripped out, which is the opposite of what more context is supposed to buy you. The second is MutaGReP, which shows the other side: a grounded plan that uses less than five percent of a hundred-and-twenty-eight-thousand-token window can rival GPT-4o working with the full repository in context. Retrieving a small, structured, relevant slice beats stuffing the window, on both cost and quality. The genuinely open question is where the crossover sits, at what repository size and task type the full-context dump finally wins, and nobody has mapped that curve. But the default assumption that bigger context windows make retrieval obsolete is, on the evidence, backwards.

There’s one more enterprise wrinkle I can’t skip, because it’s the thinnest topic academically and the one that bites hardest in practice: access control. In a big company, “find all references to this function” is not a neutral search. If it returns code the person asking isn’t allowed to read, that’s a data leak, full stop. And almost all the academic retrieval work treats permission as a post-hoc filter you slap on after ranking, which is both slow and wrong, because the ranking itself can leak information about what exists. A survey of eight hundred and sixty Microsoft developers this year found that what they actually want is what the authors call bounded delegation: agents that operate with explicitly scoped authority, with provenance on every answer, with a clear sense of their own uncertainty, and with least-privilege access by default. That’s a design language for retrieval, not a feature request. Permission has to be a first-class retrieval input, baked into what the index will even consider, and the field has barely started. So that’s the coding movement: the embedding-versus-grep war that resolved into hybrid, structure and graphs winning at localization, new benchmarks proving the old scores lied, and freshness, tribal knowledge, and permission as the enterprise problems that change the game. Hold the freshness-and-permission theme especially, because it comes straight back in the next two domains.

Let’s change worlds. Support and customer-service agents. On the surface this looks like the easy case, the one RAG was born for: you have a knowledge base of help articles, a history of resolved tickets, a user asks a question, you retrieve the right article and ground your answer in it. And in fact this is the most deployed form of agentic retrieval on earth right now. The current numbers are real and worth saying out loud: a well-built RAG support deployment deflects something like forty to fifty percent of routine tickets, with the 2026 enterprise median around forty-one percent and the top quartile reaching nearly fifty-nine percent. Deflection is the word for a ticket the AI handled so the human never had to, and at the volume of a large support organization, a forty-percent deflection rate is an enormous amount of money. So this domain has the clearest business case of the three. But the apparent simplicity is a trap, and the ways it’s a trap are exactly the ways episode one’s thesis matters here too.

The first hard thing is that the cost of being wrong is asymmetric and high. In a coding agent, a bad retrieval wastes a few tokens and the agent recovers on the next loop. In support, a confidently wrong answer goes to a customer, and it can mean a botched refund, a security misstep, a regulatory violation, a screenshot on social media. So this domain is far less tolerant of hallucination than consumer chat, and that intolerance is structural, not a nice-to-have. It’s why grounding and citation are not garnish here, they’re the product. The discipline that’s emerged is that every answer must be traceable to a specific retrieved source, and increasingly the answer carries the citation back to the article it came from, both so the customer can verify it and so the company has an audit trail when something goes wrong. This is the most successful real-world deployment of one of episode one’s open problems. Remember the last open question I left you with: that test-time-compute systems produce a reasoning chain or an evidence trail for every decision, and we mostly throw it away. Support is the one domain that learned not to throw it away, because the regulator and the angry customer both demand to see the receipt.

The second hard thing is freshness, and notice it’s the same villain as in code. A support knowledge base is a living thing. The refund policy changed last week, the product shipped a new version yesterday, the workaround for that bug is now obsolete because the bug is fixed. If your retriever faithfully serves the old article, it faithfully gives the wrong answer with full confidence and a citation, which is worse than a hedge. The 2026 practitioner consensus is blunt that hallucinations scale with article volume, and that the failure mode isn’t the model making things up out of nothing, it’s the model grounding perfectly on a stale or low-quality document. Garbage knowledge base, confident garbage answer. This is the support-domain version of the Weng staleness result. The retrieval problem is not “find a relevant article,” it’s “find a relevant article that is still true,” and the second clause is the hard one, because relevance is a property of the query-document pair and truth is a property of the world, and embeddings only know about the first.

The third hard thing, and this is where reasoning-intensive retrieval genuinely earns its place, is that real support conversations are multi-turn, and retrieval over a conversation is a different beast than retrieval over a single query. There’s a benchmark that makes this concrete, mtRAG, a multi-turn conversational RAG benchmark with a hundred and ten human-written conversations averaging almost eight turns each across four domains, more than eight hundred tasks total. And what it forces systems to handle is the stuff that breaks naive RAG: questions that only make sense in the context of earlier turns, what they call non-standalone questions, where “does that work on the enterprise plan too?” has no retrievable meaning without the previous three turns; questions that are genuinely unanswerable, where the right move is to say so rather than to retrieve the nearest-looking thing and bluff; and the requirement that the answer be faithful not just to the retrieved passages but to what was already said in the conversation. That “does that work on the enterprise plan too” example is the whole problem in one line. You cannot embed that query and search, because on its own it’s nearly contentless. You have to reason over the conversation to reconstruct what “that” refers to, rewrite it into a standalone query, and then retrieve. That’s HyDE-style query reformulation and IRCoT-style reasoning-before-retrieval, applied to a dialogue. The query is, again, no longer a static string. It’s the product of the model thinking about the conversation so far. Episode one told us retrieval was becoming a reasoning problem; multi-turn support is where ordinary companies are paying for that reasoning whether they call it that or not.

The fourth hard thing is the decision that wraps all of this: deflect or escalate. The single most important judgment a support agent makes is not what to answer, it’s whether it should answer at all, or hand off to a human. And this is precisely the FLARE and Self-RAG move from episode one, relocated into a business workflow with real stakes. FLARE had the model watch its own confidence and retrieve when it was uncertain; Self-RAG trained the model to critique whether its retrieved passages actually supported the claim. In support, that self-assessment becomes the escalation gate: if the retrieved evidence is thin, if the confidence is low, if the question is in a high-risk category, the right behavior is to escalate to a human, with the full conversation context carried along so the customer doesn’t have to repeat themselves. The practitioners have a sharp warning here that the deflection number alone hides: high demand plus low confidence in the underlying content is exactly where deflection quietly fails, and a deflection rate above eighty percent should make you suspicious rather than proud, because it usually means the system is answering things it should have escalated. So the mature support agent is running a self-critique loop on its own retrieval and treating “I don’t have grounded evidence for this” as a first-class, valuable output, not a failure. That is retrieval control and self-criticism, the Self-RAG idea, turned into a customer-safety mechanism.

Notice the symmetry with the coding world. There, retrieval failure is cheap and recoverable, so the agent can afford to explore aggressively and grep its way around. Here, retrieval failure is expensive and customer-facing, so the agent has to be conservative, has to ground every claim, has to know when to stop and call a human. Same underlying machinery, retrieve, reason, critique, decide, but the domain’s cost structure flips the disposition from bold to careful. And the enterprise themes carry straight over from the coding section: permission-aware retrieval matters just as much here, because a support agent pulling from internal systems must respect what this customer, and this agent, are allowed to see; and Glean-style enterprise search is essentially the support problem generalized across every internal tool, indexing files, tickets, messages, code, and docs across a hundred-plus applications, with permission-aware access and source citations as non-negotiable, because, as the vendors put it, a knowledge tool that surfaces the wrong file creates legal and cultural risk. Support and internal enterprise search are the same animal: grounded, cited, permissioned retrieval where being confidently wrong is the thing you’re most afraid of.

Now to the third world, and the one I find most conceptually slippery, because here the boundary we’ve been relying on, the line between the retriever and everything else, starts to dissolve. Personal agents. An agent that knows you. Your calendar, your email, your past conversations with it, your preferences, the project you’ve been grinding on for three weeks. The promise is an assistant that doesn’t make you re-explain your life every morning. And the moment you try to build it, you discover that “retrieval” and “memory” have become the same problem wearing two different names.

Consider what that means, and it connects directly to the agentic-memory reading path some of you have followed. When a support agent retrieves an article, the corpus is external, shared, and the same for everyone. When a personal agent retrieves a fact about you, the corpus is you: your history, private, unique, and constantly growing as you keep talking to it. Retrieval over that corpus is what the memory field calls, well, memory. The mechanism is identical, find the relevant items and pull them into the context window, but the framing flips. The 2026 state of the art on agent memory says the field is moving beyond pure vector similarity, and the way it retrieves a relevant memory now combines semantic similarity, keyword matching, and entity matching before injecting it into context. Read that list. That is exactly the hybrid retrieval stack we just spent the coding movement building: dense for meaning, lexical for exact terms, structural for entities. The personal-agent memory community and the code-retrieval community independently walked to the same hybrid conclusion, from opposite ends, which is a strong signal that the hybrid answer is real and not a fashion.

What makes personal retrieval genuinely different from the other two domains is a set of constraints that don’t apply when the corpus is a codebase or a help center. The first is privacy, and it’s not a checkbox, it reshapes the architecture. When the corpus is your private life, you can’t casually ship it to a cloud embedding API. So a real strand of 2026 work is on-device retrieval: running the whole embedding pipeline locally, with tools like FastEmbed, so the data never leaves the machine, and local-first agents that keep memory in on-device modules off external servers entirely. That’s a hard engineering constraint that the coding and support worlds mostly don’t face, and it pushes personal retrieval toward small, efficient, local models, which connects right back to episode one’s InteRank result: a three-billion-parameter reranker that reasons and explains itself and beats models twenty times its size. The reason that result matters so much for personal agents is that on-device is the regime where you cannot run a giant model, so a small retriever that still reasons isn’t a nice-to-have, it’s the whole ballgame. The test-time-compute-survives-distillation finding from episode one is the enabling technology for private, personal, reasoning retrieval.

The second difference is that the corpus is adversarially dynamic in a way that the others aren’t, and it raises the freshness problem to a new level. Your preferences contradict themselves over time. You liked terse answers last month; this week you’re learning something new and you want detail. You moved cities. You changed jobs. A personal memory store accumulates statements that were true when written and are false now, and unlike a support knowledge base, nobody is editing it for correctness. So personal retrieval has to do something support retrieval mostly punts on: reconcile conflicting memories and weight recency against importance. This is where you see the agentic-memory field reaching past storage and past simple reflection toward what that literature calls the experience stage, abstracting across many episodes into a stable model of the user rather than just retrieving the nearest past statement. The retrieval question isn’t “what did the user say that’s similar to this,” it’s “what is true about the user now, given everything they’ve said,” and those are very different queries. The first is a lookup. The second is an inference. Which is to say, the personal-agent retrieval problem is reasoning-intensive in exactly episode one’s sense: the relevant memory and the current query may share no surface features at all, and the connection between them runs through a chain of inference about who this person has become.

The most visible move in this space landed in January of 2026, when Google wired persistent personalization into Gemini across its whole stack, so the assistant can reference your Gmail, Calendar, Drive, Photos, Search, Maps, and YouTube history to personalize what it tells you. Set aside whether you want that, and look at it as a retrieval system: it is cross-source personal retrieval at consumer scale, pulling from seven or eight private corpora at once and fusing them into one context. That is the personal-agent thesis shipped to a billion people, and it makes the open problems urgent rather than academic. Because the contrary view in the reporting kept raising one thing: persistent memory introduces layers of latent representation, embeddings, inferred summaries, weighted retrievals, that determine what the agent tells you while remaining completely invisible to you. You can’t see why it retrieved what it retrieved, you can’t easily inspect what it thinks it knows about you, and the questions of who can read your stored memories, how long they’re kept, and how you delete them are, as of now, only half-answered. The reasoning chain that episode one said we throw away, in the personal domain, isn’t just a wasted artifact. It’s the thing that would let you understand and contest what an agent has decided about you, and right now it’s hidden.

So let me line the three worlds up against each other, because the comparison is the payoff. In all three, the episode-one machinery is the same: hybrid retrieval that fuses lexical, dense, and structural signal; retrieval as a reasoned action in a loop, not a fixed up-front step; query reformulation that injects the model’s reasoning into the search; and a self-critique gate that decides whether the retrieved evidence is good enough to act on. What changes from world to world is the physics. In coding, the dominant constraint is freshness and scale, the corpus changes every commit and runs to billions of lines, so the field tore out frozen embeddings in favor of agents that search live source, and structure won at localization. In support, the dominant constraint is the cost of being wrong, so grounding and citation and the deflect-versus-escalate decision became the whole game, and the reasoning trail got preserved as a safety receipt. In personal agents, the dominant constraint is privacy and the shifting self, so retrieval went on-device and small, and the retriever-memory boundary dissolved into a single inference problem about who you are now. Same thesis, three different masters.

Which brings us, as it should, to the open problems, because that’s where the reading path actually points, and the satisfying thing is that the cross-cutting questions from episode one show up sharper, not blurrier, once you’ve seen them land in real domains. Let me name five.

The first is routing test-time compute by query difficulty, and every domain we covered is bleeding from this wound. Right now, reasoning is spent uniformly. A coding agent reasons just as hard about “where is the config file” as about “why does this distributed lock deadlock under load.” A support agent runs the same retrieval pipeline for “what are your hours” as for a multi-turn regulatory question. A personal agent reasons the same about “what’s on my calendar” as about reconciling years of contradictory preferences. But most queries, in every domain, are easy, and the expensive reasoning is wasted on them. What’s missing is a controller that detects when relevance is genuinely inferential, when the question actually needs the chain of reasoning, and only then pays for it. Rank1 and ReasonIR proved reasoning lifts retrieval; nobody has built the dispatcher that decides which queries deserve it. Build that, and test-time-compute retrieval goes from a luxury to something you can afford at the scale of a support queue or a monorepo. This is, I think, the single most economically important open problem in the entire field.

The second is that reasoning-intensive retrieval is still mostly English and text, and the domains that most need reasoning are exactly the ones with the fewest trained retrievers and the weakest benchmarks. Code is the leading edge of fixing this, which is why the coding movement was the deepest today, but look at what 2026 actually had to do to get there: CORE-Bench and SWE-Explore had to be built from scratch because the old code-search scores were measuring the wrong thing, and even now they show retrievers collapsing on the genuinely agentic tasks. Math, scientific literature, multimodal data, the GUI-bug work like GALA that grounds a screenshot against a call graph, these are barely benchmarked. The reasoning-intensive retrieval frontier beyond English text is wide open, and code is the proof that closing it requires not just better retrievers but new benchmarks built to resist contamination, because the old ones lie.

The third is the dissolving boundary between retriever and generator, and the personal-agent world made it visceral. Episode one pointed at GRC and RankRAG, one model that retrieves, ranks, and writes. The personal domain shows why that’s not just an efficiency play: when the corpus is you and the memory is the retrieval is the context, the clean separation of index, retriever, reranker, generator stops describing anything real. But, and this is the open part, nobody has measured the actual tradeoffs. What does it cost in latency, in quality, in your ability to audit and to enforce permissions, to collapse the boundary versus keeping a clean separate index you can inspect, secure, and update? In the personal domain especially, a separate, inspectable memory store might be exactly what privacy and user control demand, even if a fused model would be faster. The boundary may be worth keeping for reasons that have nothing to do with performance, and that’s a question nobody has answered with numbers.

The fourth is the reasoning chain as a first-class evidence surface, and across the three domains you can watch it go from wasted to load-bearing. A test-time-compute reranker produces an explicit relevance rationale for every result, and episode one’s complaint was that we discard it. Support has started not discarding it, because the citation and the evidence trail are the product. Personal agents desperately need not to discard it, because the hidden rationale is exactly what would let you understand and contest what the agent believes about you. And coding agents could use it to explain why they navigated where they did, which the architecture-descriptor and exploration work suggests would cut wasted navigation dramatically. The rationale is generated, for free, by every reasoning retriever. Exposing it to the user, and feeding it forward to the downstream model as grounded evidence rather than throwing it in the trash, is a near-free win that almost no system takes.

And the fifth, the one I’ll leave you on, is the deepest and the least solved: credit assignment for the reasoning that shapes retrieval. When an agent reasons, queries, reads, reasons again, and re-queries, you can measure whether the executable actions, the actual searches, were good. But the latent reasoning steps in between, the thinking that decided which query to ask, are what actually determine whether the retrieval succeeds, and they’re nearly impossible to train, because only the actions are directly rewardable, not the thoughts behind them. Episode one named RICE-PO as an opening move, turning retrieval interactions themselves into localized learning signals for those hidden reasoning steps. And every domain today is full of agents whose retrieval quality is bottlenecked precisely there. The coding agent that greps the wrong term first, the support agent that rewrites a multi-turn query badly, the personal agent that retrieves a stale preference, all of them are failing in the reasoning that precedes the search, and we don’t yet know how to teach that reasoning directly. The whole agentic-retrieval program, in coding, in support, in personal agents, is going to live or die on whether we crack it.

So pull it all together. Episode one gave us the thesis: retrieval is becoming a reasoning problem, and the field is paying the compute. Episode two put that thesis to work, and the lesson is that the thesis survives contact with reality, but every domain bends it. Coding tore out frozen embeddings for live agentic search, then discovered structure and hybrid retrieval winning underneath, and built new benchmarks because the old numbers were a mirage. Support turned retrieve-reason-critique into a grounded, cited, escalation-aware safety system where the reasoning trail finally got kept. Personal agents collapsed retrieval and memory into one private, on-device, reasoning-intensive problem about who you are now. And the open questions didn’t dissolve under contact with the real world. They sharpened. The most interesting question in retrieval still isn’t how to embed better. It’s how much thinking a search is worth, and now we get to ask it three times over, once for the codebase, once for the customer, and once for the person. Thanks for listening. I’ll see you on the next one.