This week, X is again circulating "five GitHub repos to build your AI second brain." Karpathy's LLM Wiki is on every list, next to personal memory projects and Claude-plus-Obsidian hooks.
Those repos are useful. They are also incomplete in a way that only shows up after the wiki has been writing itself for a couple of weeks.
The failure is not "the model forgot." The failure is meaning drift: a result that was true under specific conditions becomes a general fact, and later pages cite that generalization as if it were settled.
The bug showed up in the discourse this week
On November 8, a builder described the wall clearly: even with citations, meaning drifts. A finding that applied under one setup gets rewritten as a universal claim. The next generated page builds on it. A week later, the wiki is confident, interlinked, and slightly wrong.
That is a different problem from the usual goldfish-chat complaint. Persistence is necessary. Persistence without a reviewable source of truth just compounds the first error.
The same week, people were also shipping shared, git-backed wikis so one teammate's coding agent does not start from zero. That instinct is right. Shared agent memory without ownership and review just shares the drift faster.
Why generated pages drift
An LLM wiki works by synthesizing pages from sources, then treating those pages as context for the next synthesis. That loop is the product.
It also creates a citation graph that slowly leaves the evidence:
- A paper, run log, or RFC states a claim with scope: "this held for the 8B model on our eval set."
- The wiki page drops the scope: "the 8B model is accurate enough."
- A later page, written from the wiki rather than the source, recommends shipping the 8B model to customers.
- An agent answers a teammate from page 3, with a tidy citation — to the wiki.
Humans do this too, in meeting notes. Agents do it faster, more politely, and at 2 a.m.
A personal vault can tolerate some of this. You still have the original PDF on disk and a memory of what you meant. A team cannot. The person who ran the eval leaves. The next agent only sees the pages.
Personal second brains vs a team source of truth
X still frames the choice as Notion versus Obsidian: share in the cloud, or own the files. That is a real trade-off for a personal knowledge base. It is the wrong frame for a team that wants agents in the loop.
What you need is a source of truth people already edit, with:
- Immutable raw sources, separate from synthesized pages
- Page owners and review dates
- Permissions, so a draft does not become official just because an agent linked it
- A way for agents to read the workspace without silently rewriting it
That is closer to Knowledge base Software than to a weekend vault hook. If the AI layer can search and cite those pages, you have AI knowledge base Software. If you can run the workspace yourself, you also get the ownership people usually want from an Open source Notion alternative — without pretending a folder of agent-written markdown is a product.
A three-layer setup that holds up
Keep synthesis above the source of truth, not in place of it.
Layer 1 — Human source of truth.
The docs, specs, RFCs, and run logs the team already maintains. Corrections happen here. If you self-host this layer, the documents stay in infrastructure you control, and the model provider stays swappable. AFFiNE's guide to self-hosted AI for teams treats this as its own layer for a reason: the knowledge workspace is not the model server, and it is not the chat UI.
Layer 2 — Review loop.
Every important synthesized page gets an owner, a review date, and a changelog. New claims must link to a source document, not only to another wiki page. If the source is a generated page, it is a draft until a human accepts it.
Layer 3 — Agent synthesis, read-only by default.
This is the LLM wiki: topic pages, briefings, "what we believe about X." Agents read through a scoped credential (MCP is the current pattern). They do not get write access on day one. The write-up on an LLM wiki for teams is explicit about this: start read-only, test with real questions, and fix the documents — not the prompt — when an answer is wrong.
AFFiNE, which I work on, is one option for layer 1: an open-source, local-first workspace with docs, whiteboards, and databases, plus an optional BYOK AI layer and a workspace MCP server that is read-only by default. It is not the only option, and it is a weak fit if you only need a read-mostly handbook or if you need agents to write into the workspace on a stable release today.
A one-week check you can run without buying anything
Pick one topic your agents already answer: pricing, architecture, or an on-call runbook.
- Print (or paste) the three wiki pages they cite most often.
- For each factual sentence, ask: does this cite a source document, or only another generated page?
- Highlight every claim that lost its conditions ("on the staging dataset", "for enterprise tenants", "as of September").
- Move the corrected claim back into the source-of-truth doc. Leave the wiki page as a summary that links out.
- Give the page an owner and a review date.
- Re-ask the same ten questions. Score whether each answer cites the right source. If it fails, edit the doc.
If step 2 is mostly wiki-to-wiki links, you do not have a retrieval problem. You have a drift problem.
Bottom line
A second-brain repo can give one person a writing loop. A team needs a source of truth that outlives the loop.
Let the LLM wiki summarize, link, and brief. Do not let it become the only place a fact lives. The moment a generated page is the sole citation for a later generated page, meaning has started to drift — and the wiki will sound more sure of itself every day.
If you are evaluating Knowledge base Software you can actually run and review, start at the homepage and read the LLM wiki and self-hosted AI pieces before you wire write access to any agent.
