{"id":"2079523981363692005","url":"https://x.com/beamnxw/status/2079523981363692005","text":"","author":{"name":"beamnxw ./","username":"beamnxw","avatarUrl":"https://pbs.twimg.com/profile_images/2074793345314861056/3FE1i0oW_200x200.jpg"},"createdAt":"Tue Jul 21 11:08:47 +0000 2026","engagement":{"replies":22,"retweets":3,"likes":98,"views":62223},"article":{"title":"AgenticRAG: Letting LLMs Hunt for Evidence. Here's the Full Agentic Upgrade","previewText":"I think you know that most RAG systems still work like this: ask a question, grab some chunks, stuff them into a prompt, and pray\nOne shot. No second chances\nFine for easy stuff. Falls apart the","coverImageUrl":"https://pbs.twimg.com/media/HNtCPqWWcAA4CBZ.jpg","content":"I think you know that most RAG systems still work like this: ask a question, grab some chunks, stuff them into a prompt, and pray\n\nOne shot. No second chances\n\nFine for easy stuff. Falls apart the second your question gets messy, the kind where you'd open five tabs and rethink your search terms twice\n\nI dug into how the newer agentic RAG systems actually work under the hood, then built the whole thing as real, runnable code. An actual harness with a retrieval backend, a tool-using agent loop, and a token budget that forces itself to summarize before it blows up. Copy the whole thing\n\n# The Problem In One Line\n\n![](https://pbs.twimg.com/media/HNtAQv9XYAA0bRD.png)\n\nClassic RAG finishes searching before it starts thinking. The model never gets a say in its own search. It just reacts to whatever got handed to it\n\nAgentic RAG flips that. The model runs the search itself, in a loop, deciding when it has enough\n\nThe 4 Piece Architecture:\n1\\ Loop – model decides each round: search more or answer now\n2\\ Search – broad, multiple rewritten queries at once\n3\\ Find + Open – targeted digging inside specific documents\n4\\ Summarize – forced checkpoint before context blows up\n\nBelow is the full build. Two files. Runs locally against a sample corpus, swap the corpus for your real index and you're production ready\n\nOne honest note before you copy anything: treat every number here as a dial, not a rule\n\n# File 1: the retrieval backend\n\nThis is the \"dumb\" part your agent controls\n\nIn production you'd swap this for Elasticsearch, a vector DB, whatever you already run. The interface matters. Every result gets a stable reference ID the moment it's first seen, and find/open only ever take that ID, never a raw file path\n\nThat's what keeps citations traceable across a long run\n\nI tested this before writing a single line of the agent on top of it. Ran it against a sample revenue doc and an unrelated OCR runbook. Search correctly ranked the revenue doc first with a score of 1.87 versus 0.06 for the unrelated doc. find pulled every line mentioning \"annual\" with exact line numbers. open returned a clean numbered window. If your retrieval layer can't do this much on its own, fix that before you touch the agent loop\n\n## File 2: the agent harness\n\nThis is the part that actually decides when to search, what to open, and when it has enough. It runs on Claude's tool use, tracks its own token spend, and forces itself to checkpoint before it blows the context window\n\n# How to actually run this\n\nYou'll see live cycle-by-cycle output showing token spend and which tool the model reached for. That visibility alone is worth building this even if you never ship it, watching an agent choose search versus find versus open on a real question teaches you more about your own document structure than any dashboard will\n\n# The 6 box checklist for adapting this to your own stack\n\n## The one test that exposes a fake \"agentic RAG\"\n\nAsk it: \"Give me the exact reference_id and location for that last claim.\"\n\nCan't produce one? It's not doing agentic retrieval, it's just pattern matching on whatever got stuffed in the prompt.\n\n> Before you build any of this, run the gut check\n\nOnly worth the extra complexity if all of these are true:\n\nIf you're running a simple FAQ bot for \"what are your business hours,\" skip all of this. You'd be burning tokens on a Ferrari to buy milk..\n\n# The Real Takeaway\n\nIt's a systems decision: split the model's job (deciding what to search and when to stop) from the search stack's job (actually running the query). Once separated, you can upgrade either one on its own, swap the backend, tune the cycle cap, change the summarization trigger, without touching the other half.\n\nOpen question worth sitting with: how much of the gain here is the model being smart, versus just giving it more time, more tool calls, and a better policy for using them?\n\nWorth testing before you assume you need the biggest model on the market\n\nSave this so you don't lose it\n\nFollow @beamnxw for more technical posts :)\n\n[my telegram channel](https://t.me/beamnxw11)"}}