Where my knowledge lives: an LLM wiki as the source of truth for agents

An agent is only as good as what it can find and trust. Ask it about your design system, your conventions or the project you are in, and it goes looking. If it has to wander through old notes and unrelated pages to find the right one, it spends tokens on the search and hands you an answer you have to check yourself.

So my claim is this: in order for our work in agentic engineering to be as efficient as possible, we need to have an LLM wiki structured in the right way. We need to have some pipelines to lint the wiki, validate its content, and ingest the information on a daily basis from the right sources.

This is how I got there, what I run today, and what went wrong on the way. It is written for a developer working alone and for a team. Anyone who wants their knowledge grounded and within reach of their agents can use it.

The idea has a clear origin: Andrej Karpathy's LLM Wiki, an idea file you paste into your own agent so it can build the details with you.

He starts from what most of us already do with documents. You upload files, the model pulls the chunks that look relevant, and it answers. His complaint is that “the LLM is rediscovering knowledge from scratch on every question. There's no accumulation.” (Andrej Karpathy, LLM Wiki)

The wiki turns that around. The model reads each new source once, writes what it learned into a set of linked Markdown pages, and keeps those pages current. “The knowledge is compiled once and then kept current, not re-derived on every query.” (Andrej Karpathy, LLM Wiki)

It has three layers. The raw sources are the articles, papers and transcripts you collect; the model reads them and never changes them. The wiki is the set of pages the model writes and maintains. The schema is a file such as CLAUDE.md or AGENTS.md that tells the model how the wiki is organised and how to ingest, answer and clean up.

His own picture of it is the one that stuck with me: “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” (Andrej Karpathy, LLM Wiki)

To see why the structure of a wiki matters, it helps to know how an agent searches it. There are two broad ways.

Semantic search, often called RAG (retrieval-augmented generation), cuts your documents into chunks and turns each chunk into a vector, a list of numbers that stands for its meaning. A question becomes a vector too, and the system returns the chunks whose vectors sit closest to it. It needs an index built in advance and kept in sync.

Agentic search, also called vectorless search, keeps no index. The agent lists folders, searches for words with tools like grep, opens a file, reads it, and decides where to look next, the way a person would.

Coding agents have moved to the second. Cline explains why it does not index your codebase: chunking code for embeddings tears its logic apart, and an index is one more copy of your code to secure. Boris Cherny of the Claude Code team has been reported as saying that early Claude Code used a local vector database and that agentic search simply worked better.

Semantic search still has its place. For a fuzzy question over a very large body of text, where the words you need are not the words you would type, vectors can win. I compared Trove with PageIndex, another vectorless approach, on finding the exact page for a citation if you want a measured case.

Agentic search follows the routes your wiki gives it. That is its strength and its risk. If your source of truth sits in its own place, the agent goes there, reads a few pages and answers.

If it is mixed in with meeting notes, half-finished ideas and pages about other projects, the agent follows links into unrelated material. It spends tokens working out which pages it should have read, and it may stop at the wrong one.

The same structure is what lets you trust the answer. When knowledge was saved in the right place, in the right shape, an answer that cites it means something. When anything could have landed anywhere, a cited answer still needs checking.

My first wiki was a fork of claude-obsidian, a Claude Code plugin built on Karpathy's pattern. I turned it into a personal knowledge base for my development projects, maintained by Claude and browsed in Obsidian.

It worked the way the pattern describes. You drop a source into .raw/, tell Claude to ingest [filename], and it files what it learned into wiki/. A question makes Claude read the index, drill into the pages and answer. The command lint the wiki finds orphan pages and gaps.

Then I moved everything to Trove. The first reason was how it manages information: books, manuscripts and their versions, instead of a folder of files I had to keep in order myself. It also connects to both Claude Code and Codex, and it has an interface where I can browse and read what the agents wrote.

It is token-efficient in the way I work: agents read the contents first and then only the pages they need. That is my observation from daily use, not a measurement. And it holds books that people share there, including books I have shared myself.

The people behind it mattered too. Trove is an Israeli product. I know its CEO and have consulted with him many times about agentic engineering. He is a great guy, and I was sure he had built a great product. I trust it and want to support it.

The last reason was practical. I was already paying for it for my academic work, where my academic-writer plugin cites sources page by page from it. I wanted everything in one place.

I use Trove the way Terraform is used for infrastructure. Terraform declares what should exist, and the tool keeps reality in line with it. In Trove, everything I do is declared in books and manuscripts, and that declaration is the source of truth.

Books hold the global scopes. I keep one book for my design system and others for architecture, backend design, databases and user-experience design; any subject many projects share gets its own book. Projects reference those books instead of copying them, so many projects can stand on one source of truth.

Manuscripts hold work in progress: a project that is still moving, with its log. Trove's docs describe it plainly: “A manuscript is a living note that agents add to as they work.” (Trove docs, Manuscripts) Every edit is saved as a version, so each book keeps its writing history and I can restore an earlier state.

trove items history <item-id>
trove items restore <item-id> --version <n>

When an agent needs something, Trove's librarian picks the books and the page ranges, and readers open only those pages. The answer comes back with page citations. That is agentic search over books. One caveat from Trove's own docs: the librarian does not yet start reliably on its own, so when the answer matters, ask your agent explicitly to search your Trove library.

A source of truth raises a fair question: what about history? Where did a decision come from, and was it reversed?

My answer is that history is always there. If your wiki lives in Git, Git keeps it. If it lives in Trove, every book keeps its versions. You do not lose it by not reading it.

What agents need for most work is the current state and as little context as possible. When the past teaches something, turn the lesson into a rule: a line in your rules book, a PR rule, a workflow written in Markdown. The agent then follows the rule without reading every decision that led to it.

There are times to read the history on purpose. A refactor is one. Showing how a company's thinking progressed is another. That is a different mode of exploration, and you choose it; it should not be the default.

A side note: a colleague sent me Anton Sten's Where decisions live, which reaches a nearby answer from the other side. He keeps chronological running notes apart from a decisions file: “If I want to understand how we got somewhere, I look at the running notes. If I want to know what is currently true, I look at the decisions.” (Anton Sten, Where decisions live)

He leans on dated history so an agent can tell old from current. I lean on rules and on the tool's own versions.

A wiki is only as current as what flows into it. I use two kinds of ingest.

The first is save skills. In a self-managed wiki you save through skills, and different kinds of content deserve different skills. For my company's wiki I built a meeting-ingest skill that files a meeting's outcomes in the right places. I also have a more generic save skill that works out, for each user and each case, where a piece of knowledge belongs.

The second is a daily routine. First connect your sources to your agent through Claude connectors, plugins or MCP servers: Slack, your meeting recorder (Granola, Fireflies or Read AI) and email. Then set up a routine with a prompt you write once. It reads the relevant channels every day and files what it finds in the right places in the wiki.

I run routines like this on my Claude account. Karpathy pictured exactly this for teams: “an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls.” (Andrej Karpathy, LLM Wiki)

Ingest adds knowledge every day, so something has to keep the whole in shape. I run three layers:

• The fork's lint: lint the wiki finds orphan pages and gaps.
• A daily curator agent reads the PRs merged that day and updates the wiki to match the code.
• A weekly wiki-linter agent walks the whole wiki, looking for pages that drifted from the conventions or from each other.

The lint is cheap and mechanical. The two agents do the judgment work no one on a team wants to do.

I set up a wiki for the engineering team at my company. With engineers writing to it, it was all good. Then people from product started using it too, and they sometimes pushed information that did not follow the conventions.

That was a real problem, because the whole point of a source of truth is that you can trust it. I may write a separate post about how I set that wiki up.

A shared Git wiki lets anyone push anywhere. You have a few ways to guard it:

• Scripts gated by GitHub account that check who may write to which folder.
• Folder ownership by organisation convention. This is not deterministic: a convention can be ignored or worked around unless something enforces it.
• A tool with permissions built in. Trove has owner and admin roles and departments, and books are shared for reading by default.

Trove's docs give the rule I would give anyway: “Give write access only to people with authority over the topic.” (Trove docs, Share a library with your team)

trove team access grant <item-id> --dept <department>
trove team access level <item-id> --access write
trove team access matrix

You can add a knowledge graph on top of all this. Graphify is one example: it maps a codebase and its documents into a graph the agent queries instead of searching file by file. Its README puts it as “No embeddings, no vector store: a real graph you traverse.” (Graphify README)

The token savings on its site are reported by its users, not measured by Graphify. If tokens are very tight for you, it may be worth a look. I have not used it and did not find I needed it, so take this as a pointer, not a recommendation.

I still use this every day. What works is a source of truth that agents read first, books that many projects reference, and pipelines that ingest daily and lint on a schedule. The answers I get are grounded, and I can check where they came from.

What did not work was opening the wiki to writers outside the conventions without a guard. Structure has to be enforced, not just agreed.

Whether you are one developer or a team, start here:

1. Pick a home: Trove, or a Git repository with an LLM wiki.
2. Make one source-of-truth section, apart from logs and notes, with a page or a book per global scope.
3. Add a save skill so knowledge lands in the right place.
4. Add a daily ingest routine from Slack, meetings and email.
5. Add lint and a scheduled curator so the wiki stays true to the code and the conventions.
6. Decide who may write where, and enforce it with scripts or permissions.

Then ask your agent something about your own work and look at what it read to answer. An agent reading a source of truth it can trust needs less context, spends fewer tokens, and gives answers you can trust.