# LLM Wiki as agent-memory substrate

The [[llm-wiki-pattern]] started as a personal-knowledge technique: an LLM reads sources and maintains a persistent, cross-linked markdown wiki instead of re-deriving answers from documents at query time. During 2026 it stopped being only a technique and became a storage decision that shipping agent-memory products converge on.

## The convergence

Three independent projects, different languages, different target users, same substrate choice:

- **[[toolbox/codealmanac|CodeAlmanac]]** applies it to a codebase. The wiki is plain markdown under `almanac/` in your repo, reviewed in Git like any other change, holding what code can't say — decisions, invariants, gotchas, cross-service flows.
- **[[toolbox/agentmemory|agentmemory]]** cites it directly: its design doc "extends Karpathy's LLM Wiki pattern with confidence scoring, lifecycle, knowledge graphs, and hybrid search," and the repository is the implementation of that document.
- **[[toolbox/openhuman|OpenHuman]]** compresses personal data into scored markdown trees in SQLite and mirrors them as a Karpathy-style Obsidian vault, citing the same source and describing the alternative as "vector-soup black box."

Note where they differ: a codebase, a coding-agent session history, and a person's whole digital life. The pattern is being picked for reasons that survive the change of domain.

## Why markdown-plus-links wins over a vector store

The properties that make it attractive are all about the artifact rather than the retrieval:

- **Inspectable.** You can open the memory and read what the agent believes about you or your code. A vector store's contents are not meaningfully readable, so errors in it are undiscoverable until they surface as bad output.
- **Editable by hand.** Wrong memories can be corrected directly. This matters more than it sounds — the [[memory-conflict-detection]] problem gets much easier when a human can just fix the page.
- **Diffable and reviewable.** CodeAlmanac's move of putting the wiki in the repo means memory changes go through code review. That's the strongest version of the argument: memory becomes a reviewable artifact rather than accumulated state.
- **Portable and greppable.** Plain files survive the tool that wrote them. The [[toolbox/atomicapp]] watchlist entry flags exactly this in reverse — a SQLite-only store means you can't grep your way out.
- **It is already the retrieval unit.** A wiki page is roughly the size of a useful context injection. The chunking problem that dominates RAG design mostly disappears when the author wrote page-sized things on purpose.

The cost is that markdown has no native notion of confidence, recency, or decay, which is why agentmemory layers scoring and lifecycle on top and OpenHuman keeps a scored tree in SQLite with the vault as a mirror. Neither abandons the files.

## The relationship to the memory-tool cluster

The wiki's existing agent-memory pages describe systems built the other way. [[toolbox/hippo-memory]] and [[toolbox/mempalace]] are storage-first designs with markdown mirrors bolted on; [[agent-memory-components]] decomposes any such system into extractor, store and retriever. Read through that decomposition, the LLM Wiki pattern is a specific answer to the *store* question — and one that pushes work into the extractor, since a page-shaped memory needs an LLM to write real prose rather than emit statements.

The gardening step is the other distinctive piece. CodeAlmanac runs a daily **Garden** job over stale pages, duplicates, weak links and unsupported claims; this vault has the same thing as its `/lint` workflow. That's the maintenance cost markdown imposes and vector stores don't — a vector store never contradicts itself visibly, it just retrieves worse.

## Caveats

- **Adoption is not validation.** Two of the three projects are recent, star-heavy launches, and star counts are not evidence that the substrate choice was right. What's notable is convergence under different constraints, not popularity.
- **Nobody has shown it beats a vector store on retrieval.** agentmemory's own LongMemEval numbers come from hybrid search *over* the store, not from the markdown shape. The case for the pattern is auditability and portability, not recall.
- **It scales by adding a gardener, not by scaling.** Every one of these systems needs a periodic LLM pass to keep the graph coherent, which is an ongoing cost proportional to the wiki's size.

## Cross-references

- [[llm-wiki-pattern]] — the pattern itself
- [[toolbox/codealmanac]], [[toolbox/agentmemory]], [[toolbox/openhuman]] — the three implementations
- [[agent-memory-components]] — the extractor/store/retriever decomposition this fits into
- [[filesystem-is-graph-database]], [[files-as-graph-database]] — why plain files are already a graph
- [[obsidian-ai-complete-guide]] — the production personal implementation
- [[agent-memory-decay]], [[memory-conflict-detection]] — the problems markdown makes visible instead of hiding