The LLM Wiki Method: A Second Brain Claude Can Query

A dental practice with three chairs was drowning in its own knowledge. Insurance summaries lived in one folder, treatment protocols in another, post-procedure care instructions in a third, supplier contacts in someone's inbox, and the front-desk scripts in a laminated binder that only the veteran receptionist fully understood. None of it talked to each other, and every new hire meant re-teaching the same scattered facts. I am Madhuranjan Kumar, and I want to walk through how this one practice turned that mess into a single linked knowledge base that Claude Code could query in seconds, using a method that costs nothing but a folder of markdown files. The numbers here are illustrative, but the journey is exactly how I would run it.

The starting point: knowledge that existed but could not be found

Before any tooling, the real problem was retrieval. The knowledge was not missing, it was unreachable. When a new front-desk hire asked which plans cover a night guard, the answer required interrupting the office manager, who kept most of it in her head. When a patient asked about post-extraction care, someone hunted through a shared drive for the right document. The practice was paying for the same lookups over and over in interrupted time.

The team had tried the obvious fix of dumping everything into an AI chat and asking questions. It sort of worked, but the chats forgot everything the moment they ended, so every session started from zero, and feeding the whole pile of documents into the model each time was slow and expensive. The knowledge was ephemeral, and that was the core frustration we set out to fix.

The method chosen: a markdown wiki, not a vector database

Rather than reach for a heavy retrieval pipeline with embeddings and infrastructure, we used the LLM wiki method, an approach that recently went viral precisely because it is so simple. The entire system is a folder of plain markdown files, a vault, with two subfolders. A raw folder is where you drop source material, and a wiki folder is what the model builds from it. Inside the wiki, Claude maintains an index of every page, a log of operations, and the pages themselves, usually grouped into folders like sources, people, organizations, concepts, and protocols.

The reason this beats the chat-dump approach is that a wiki makes knowledge compound like interest in a bank instead of vanishing at the end of a conversation. The reason it beats a vector database, for a practice this size, is that there is nothing to stand up and nothing to maintain. It is literally files. We optionally installed the free Obsidian app so the team could see the pages and their links visually, but that was a convenience, not a requirement. The wiki works as plain files on its own.

Building the vault: raw documents in, linked pages out

The build itself took an afternoon. We created a vault and dropped everything into the raw folder: insurance policy summaries, treatment protocols, post-procedure care instructions, supplier contacts, staff training notes, and front-desk scripts. Then we told Claude to ingest each source and act as the wiki agent.

What the model did next is the heart of the method. It read each document and decided how to chunk it, not into one page but often into many. It created a separate page for each insurance plan, each procedure, each supplier, and each protocol, then linked them with backlinks on its own. The page for a crown procedure connected to its care instructions, its materials supplier, and the insurance codes that apply. It updated the index so anyone could click straight to a topic, and it appended to a log so there was a history of every change. Nobody had to design the structure by hand. We gave it the raw material and the context that this was a business vault, and it built the relationships.

The payoff: questions answered by following links, not reloading files

Once the vault existed, the daily experience changed. The office manager and the front desk could ask plain questions, what is our post-extraction care script, or which plans cover a night guard, and get an answer in seconds. Crucially, the model answered by reading the index and following links rather than doing similarity search over chunks, which gives a deeper understanding of how things relate, because the links are real connections, not just text that happens to look alike.

The cost side is where the numbers get striking. When you query a well-indexed wiki, the model only pulls the specific pages it needs by following links from the index, instead of loading every scattered file into context each time. In this practice, querying went from effectively loading everything, call it one hundred percent of the old token cost, down to around thirty percent by week four as the index matured, and to roughly five percent by week twelve once the structure was clean and the assistant learned to navigate it tightly. Those figures are illustrative, but the mechanism is real, and one publicized case reported cutting token usage by about ninety-five percent after turning hundreds of scattered files into a compact wiki. Lower token use means lower cost and faster answers, both of which the practice felt immediately.

Wiring it into the front desk assistant

The next chapter was connecting the vault to the tools the practice already used. We pointed the front-desk assistant's configuration at the vault path so it could read the index and the relevant pages only when a specific question needed them, keeping token use low. Now the assistant answered patient and scheduling questions with the practice's own real policies and scripts behind it, not generic guesses.

This is one of the quiet strengths of the wiki approach. You can keep separate vaults for separate purposes, one for clinical and operational knowledge and another for, say, a marketing research topic, and point any agent at whichever vault is relevant. The same clean knowledge base that answers a patient question can inform the content behind your SEO and organic search, because the questions patients actually ask, captured as wiki pages, are exactly the questions your website should answer to rank. And when a lead comes in from a campaign, the assistant reading that vault gives consistent answers that support your Facebook and Instagram ad campaigns instead of contradicting them.

Why following links beats matching similar text

It is worth pausing on the reason this simple approach often answers better than the more sophisticated-sounding alternative. The common way to give an AI a pile of documents is a vector database, which chops everything into chunks and, when you ask a question, finds the chunks whose text looks statistically similar to your query. That works, but it retrieves things that resemble each other rather than things that are genuinely related. Two passages can share vocabulary and have nothing to do with each other, and two deeply connected facts can use completely different words and never get matched.

The wiki method navigates by real relationships instead. When Claude built the practice's vault, the link from a crown procedure to its care instructions is a deliberate connection, not a coincidence of shared words. So when the model answers a question, it walks those links the way a person would flip from one cross-referenced page to the next, arriving at genuinely relevant material even when the wording differs. For the dental practice this showed up as answers that pulled the right insurance code alongside the right procedure, because the two pages were actually linked, not because they happened to sound alike. The structure encodes understanding, and that understanding is what makes the answers trustworthy enough to put in front of staff and patients.

Why the knowledge compounds instead of evaporating

The other quiet advantage is time. A normal AI chat is a sandcastle. You explain your business, get useful answers for an hour, and then the session ends and every bit of that context washes away. The next morning you start over, re-explaining the same policies and protocols, paying again in time and tokens for ground you already covered. For a busy practice, that amnesia is a real tax that nobody puts on the invoice.

A wiki flips the direction. Every source you ingest and every link the model draws stays in the vault permanently, so the knowledge stacks up like interest in an account rather than resetting to zero. The practice that spent an afternoon building the vault did not have to spend another afternoon next month. It simply dropped new documents into the raw folder as they arrived, a new insurance plan here, an updated protocol there, and the wiki grew richer and more connected each time. Six months in, the vault is not a static reference, it is an increasingly capable second brain that reflects the whole history of the practice, and it belongs to the business rather than living in the head of one long-tenured employee. That durability is the entire reason this method is worth the small effort of setting it up.

Keeping it clean: the weekly lint

A knowledge base is only useful if it stays accurate, so the final habit we built in was a periodic lint. A lint is a health check you run on the wiki that finds inconsistent data, fills gaps with web research, and surfaces new connections between pages. For the practice, a weekly lint caught an outdated insurance note and a protocol that had quietly changed, and flagged both for the team to update.

That maintenance step is what makes the system durable rather than a one-time cleanup that rots over the next quarter. A knowledge base that is never checked slowly fills with stale facts until people stop trusting it, and a tool nobody trusts is worse than no tool at all, because it gives confident wrong answers. The weekly lint is cheap insurance against exactly that decay, and for a practice it takes minutes to review the handful of items it flags. It is also honest about the method's limits. A wiki of hundreds of pages with good indexes works beautifully, but at the scale of millions of documents you would still reach for a traditional retrieval pipeline. For a dental practice, or almost any small and mid-sized business, you are nowhere near that ceiling, so the simple approach is not a compromise, it is the right call.

What this practice proves for any business sitting on scattered knowledge

The lesson generalizes cleanly. Nearly every business sits on knowledge spread across a dozen disconnected places: meeting notes, standard operating procedures, client histories, research, and internal documents. A wiki pulls them into one linked system an assistant can actually read, cheaply and quickly. The token savings matter for cost, and the linked structure matters for quality, because the assistant understands relationships instead of guessing from similar-looking snippets. That reliability is also what you want before you plug the knowledge base into your CRM and website stack, where consistent, correct answers turn into faster, more confident follow-up.

If you want to try it yourself, the path is short. Optionally download the free Obsidian app and create a vault, open that folder in Claude Code, and tell the model to act as your wiki agent and set up the schema, the index, the log, and the raw and wiki folders. Drop your first source into the raw folder, give the model context about whether this is a personal, research, or business vault, and tell it to ingest. Keep adding sources, run a lint now and then, and point your other agents at the vault path when they need that context. You can absolutely set this up in an afternoon yourself, or you can bring in an expert to design the vault structure and wire it into your assistants so your whole team queries one clean, compounding brain from day one.