𝗩𝗲𝗰𝘁𝗼𝗿 𝗥𝗔𝗚 𝘃𝘀 𝗩𝗲𝗰𝘁𝗼𝗿𝗹𝗲𝘀𝘀 𝗥𝗔𝗚 𝘃𝘀 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚 RAG tutorials teach you one pattern: chunk the document, embed it, store the vectors, search by similarity. It works. Until someone asks a question where the answer depends on where something sits in the document, not just what it says. Here’s how three approaches handle the same problem, and why the field is slowly moving from searching text to navigating structure. 𝗩𝗲𝗰𝘁𝗼𝗿 𝗥𝗔𝗚: find what looks similar. You take a long document, split it into fixed-size chunks, turn each chunk into a vector with an embedding model and store them in a vector database. When a question comes in, it gets embedded with the same model, and the system pulls back the top-k chunks that sit closest to it in vector space. The LLM writes an answer from those chunks. 𝗩𝗲𝗰𝘁𝗼𝗿𝗹𝗲𝘀𝘀 𝗥𝗔𝗚: navigate the document like a person would. Vectorless RAG does exactly that. Instead of chunks and embeddings, it builds a hierarchical index of the document: root, chapters, sections, pages. When a question arrives, the LLM reads that tree, works out what’s being asked and walks down the branches to the most relevant section. 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚: reason your way to the answer. Agentic RAG keeps the tree index and puts an agent in charge of it. The question is usually complex or multi-step, the kind a single lookup can’t resolve. The agent first plans how to approach it. Then it explores the tree level by level: → Understand the intent behind the question → Explore the chapters that might be relevant → Evaluate the context at each level before going deeper → Follow the right branch down to the exact node → Check cross-references to other sections before committing to an answer The result is grounded evidence: a specific page and section, verified against the rest of the document, and an answer that cites it. The trade-off: it’s the slowest and most expensive of the three, and it needs good guardrails so the agent knows when to stop exploring. So which one should you use?

Making an Action-Taking AI Agent Production-Ready Imagine you are working at a food delivery company. A customer receives cold biryani and requests a refund. Your payment API times out, so your code retries the request, assuming the first attempt failed. But the first request actually succeeded. The retry triggers another refund. And another. One cold biryani. One API timeout. Three refunds to the same customer. Now multiply this by thousands of orders. The model didn’t fail. The system around it did. I wrote a full breakdown of making an action-taking AI agent production-ready. Check it out here: growtechie.substack.com/p/ma…

I keep seeing the same pattern with RAG projects. Someone builds a prototype over a weekend. They connect a vector database, add a few PDFs, write a prompt, and ask it ten questions. Every answer looks right, the demo goes well, and everyone is happy. Then it goes to real users, and within a week the complaints start. “It gave me the old refund policy.” “It couldn’t find the error code I searched for.” “It answered confidently, but the answer was completely made up.” The first reaction is usually to blame the model and switch to a bigger LLM. Most of the time that changes nothing, because the model was never the problem. The real issue sits before the model ever sees the question. The right chunk was never retrieved, or it was cut in half during chunking, or it was buried under four passages that only looked relevant. The LLM did exactly what it was told and answered from bad context. Reliable RAG is not about a smarter model. It’s about giving the model the right information and keeping it honest about what that information says. Here’s the pipeline I’d build today: Chunk by structure : Split on headings, not token counts, and add the section heading to every chunk so it keeps its context. Use hybrid retrieval : Vector search understands meaning but misses exact terms like product codes. BM25 catches those. Run both and merge the results with RRF. Rerank 50 down to 5 : Retrieve wide for recall, then use a cross-encoder to keep only the best matches. If nothing passes the threshold, don’t force an answer. Ground every answer : Tell the model to answer only from the sources, cite each claim, and clearly say when the docs don’t have the answer. Evaluate both halves separately : Measure retrieval and generation on their own. Otherwise you’ll never know which part actually broke. Guard and monitor Filter chunks by user permissions, re-index when documents change, and log every request so real failures become new test cases. None of this is fancy. It’s just the steady engineering work that turns a nice demo into something people can actually trust.

This Claude Code is a skill that turns any idea into a live, interactive plate you can turn, light, and look inside. Attention, the heart, a power grid, and a hash map are some examples you can see. GitHub repo: github.com/Ramakm/folio-anat… Just install and bring your own ideas into life in just secs. - Install - Prompt: /folio explains how an electric motor turns - It will create a single-page file to view in SVG, 3D, and WebGL formats. With lots more details. - No crazy prompting - Just your ideas live in secs. Inspired by the anatomy skill of Ryan.

𝗥𝗔𝗚 𝘃𝘀 𝗢𝗞𝗙 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗲𝗱 Ask your RAG chatbot “what’s our refund policy?” & it might give you the right answer. Or it might give you last year’s version, because that chunk happened to score 0.83 instead of 0.81. That’s the quiet problem with RAG. It finds what’s similar, not necessarily what’s true. Google Cloud released something in June that takes a different approach. It’s called OKF, the 𝗢𝗽𝗲𝗻 𝗞𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 𝗙𝗼𝗿𝗺𝗮𝘁, and it’s almost boring in how simple it is. There are no embeddings and no vector database. It’s just a folder of Markdown files, one concept per file. Your refund policy lives in policies/refund. md. Your revenue definition lives in metrics/revenue. md. Each file has a small header saying what it is, and files link to each other like a wiki. When an agent needs a fact, it doesn’t search. It opens the index, goes straight to the right file and reads it. If the policy changes, you edit one file and commit it to Git. You get a version history, an owner and a date, and nothing has to be re-embedded. 𝗦𝗼 𝗶𝘀 𝗥𝗔𝗚 𝗱𝗲𝗮𝗱? No. OKF works for the small set of things that must be exactly right: definitions, rules, schemas. Nobody is hand-writing a Markdown file for 50,000 support tickets. That’s still RAG’s job. The setup that makes sense to me is both, with a router in front. Known facts go to OKF and everything messy goes to RAG. Search what you can’t curate. Curate what you can’t afford to get wrong.

𝗚𝗮𝗺𝗲 𝗧𝗵𝗲𝗼𝗿𝘆 𝗯𝘆 𝗚𝗶𝗮𝗰𝗼𝗺𝗼 𝗕𝗼𝗻𝗮𝗻𝗻𝗼 Probably one of the best book on Game Theory. Access the PDF here: arxiv.org/pdf/1512.06808

𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗚𝗿𝗮𝗱𝗲 𝗥𝗔𝗚 𝗦𝘆𝘀𝘁𝗲𝗺 what every request goes through before you see an answer: - Input guardrails block prompt injection, jailbreaks, and PII before any model runs. - A router (an LLM call) decides which tools the question needs. - Tools to fetch evidence: web search for fresh facts, hybrid search (keyword + vector) over your docs, and external APIs for live data. - A reranker scores every chunk and keeps only the top few. - Output guardrails check grounding, safety, and policy, with an LLM as the judge. The answer generator writes from the reranked context only, with citations. And the parts nobody demos, but every production system needs: → An audit trail. Every request, tool call, and answer is logged to PostgreSQL. → Observability. Trace spans stream into a pipeline so you can see exactly where a bad answer came from. → Evals. A fixed eval dataset scores faithfulness, relevance, and latency on every release. Retrieval gets you an answer. Everything around it is what makes the answer trustworthy.