What is an LLM wiki? The basics

In one week you read an article on how Austria is implementing NIS2, an interview with someone from a national cyber-security agency, and an analysis of which mid-sized companies now count as "important entities". Three good pieces. Four weeks later a client asks what NIS2 means for their supply chain, and you know you read about it — but no longer where, and no longer exactly what.

An LLM wiki starts at that point. Not with finding single texts again, but with holding on to what they add up to. Pith is a reading memory for consultants: you save what you read, and Pith writes an LLM wiki from it in which every paragraph cites the source it rests on.

What an LLM wiki is

An LLM wiki is a set of pages that a language model writes from your sources. Each page covers one concept: "NIS2", "supply-chain security", "Model Context Protocol". When you save a new source, the model reads its full text, checks whether the matching concepts already exist, and extends the existing pages or creates new ones.

Four properties make it more than a pile of summaries:

• Every paragraph cites its source. The evidence points to texts you saved. What the model knows from its training does not belong in it.
• Pages are versioned. Every change is stored as a new version. You can see what a page said before and restore an earlier one.
• Disagreements are recorded. When a new source says something different from the page, the model writes the disagreement in as an ordinary sentence and also stores it as a dispute — with both sources. The wiki then does not claim one side is right, only that your sources disagree.
• The pages are yours. They are text you can read, pass on and export, not an answer that disappears when you close a window.

The result is a reading memory: what you have read no longer sits there as a list of links, but as knowledge, ordered by what it is about.

How it differs from search over a folder of files

The obvious alternative is RAG: put documents in a folder, cut them into chunks, and on every question a system finds the best-matching chunks and has a model phrase an answer from them.

That works as long as the question fits individual passages. It has three limits that show up quickly in consulting work:

1. The work is redone on every question. RAG assembles the sources fresh each time. Whether today's answer matches last week's depends on which chunks the search happens to find.
2. Connections across many texts get lost. A search returns the five most similar chunks. That two sources you read three weeks apart contradict each other is something it does not see — they are rarely retrieved together.
3. Nothing is left to check. The answer lives in the chat window. Anyone who wants to verify it later has to ask the same question again and hope the same thing comes out.

An LLM wiki moves the work forward. The synthesis happens on saving, once, and the result is written down. There is still a search — but it finds pages where the work has already been done.

How it differs from a chatbot with memory

Many assistants now remember things about you. That is useful for preferences and ongoing tasks. For subject knowledge it has a weakness: you cannot see what the assistant remembered, where it came from, or whether it still holds.

A wiki makes that memory visible. Every claim sits in one place, with evidence and a history. If it is wrong, you can find it and change it. We described the difference in more detail in An LLM wiki is not a chatbot with memory.

What makes a good LLM wiki

Not every wiki a model writes is fit to be the basis of work a client pays for. A few properties decide it:

• Pages by subject, not by article. A page is called "PostgreSQL", not after the headline of the article it came from. Otherwise knowledge grows under headlines instead of under the subject.
• Evidence that leads to the passage. A pointer to "a source" is not enough. The citation has to lead to the saved text, so you can check it in seconds.
• You decide what goes in. A wiki that takes every article you read mirrors your feeds, not your judgement. Pith has a separate decision for this: into the wiki, keep only, or skip.
• Disagreement is allowed. A model likes to smooth things over. A good wiki lets two readings stand side by side when your sources support both — with both citations.
• Maintenance is built in. Sources get deleted, texts change, two pages describe the same thing. Without maintenance the wiki goes stale. How we separated sorting, building and syncing is in Who actually maintains your LLM wiki?.

How your own agent reads and writes the wiki

An LLM wiki is not only there for you to read. Over the Model Context Protocol, your own AI assistant can work with it — the one you already use.

It can search and read pages, fetch a page's version history and restore an earlier version. It can check which saved sources are not yet in the wiki, and write pages itself. For example: before a client meeting you ask your assistant to sum up what your wiki says about NIS2 and supply chains. It reads the pages, names the evidence and tells you where your sources disagree.

Writing follows one rule that comes from a practical problem: often two agents work on the same wiki, Pith's own and yours. Every write therefore names the version it read. If the page has changed since, the write is refused, and the agent has to re-read and merge. Nobody silently overwrites what they never saw.

Your agent stays the tool you think and write with. The wiki is the memory it draws on — with evidence you chose yourself.

What about Raindrop, Readwise or Pocket?

Bookmark and read-later services solve a different job, and many solve it very well. The difference is in what you get back.

• Pocket was a clean read-later queue with a calm reader: save, read later, done. Mozilla shut it down in 2025. It stored the article; there was no synthesis across sources.
• Raindrop.io is a mature bookmark manager with collections, nested folders, tags, full-text search and permanent copies. Its bookmarks deliberately stay separate links that you still have to open and read.
• Readwise is the tool of choice for collecting highlights from many sources and resurfacing them through spaced review, and Reader is an excellent reader. Concept pages written across many sources are not part of its core.
• Recall summarises saved content and links it in a graph, but does not cite each individual claim to its source.

From these services you get back a well-ordered collection: links, highlights, summaries per item. An LLM wiki gives you pages written from many sources that name each of them. If you mainly want to read, highlight or organise links, they serve you well. If you need citable knowledge from what you read, you need the layer above.

The one-to-one comparisons: Pith vs Pocket, Pith vs Raindrop, Pith vs Readwise and Pith vs Recall. For an overview, see bookmark managers with AI and read-it-later alternatives after Pocket.

What an LLM wiki is not

An LLM wiki is not a fact check. It tells you what your sources say, and where they disagree. Whether a source is right remains your judgement. Nor is it a search engine for the whole web: it knows only what you saved. That is the point. When someone asks "says who?", the answer is a source you read yourself.

Further reading

• Who actually maintains your LLM wiki? — sorting, building and syncing as three separate jobs.
• Every claim cites its source — why source grounding reverses the order.