A compounding memory that can't leak

The idea breaks down when the wiki has to serve 30 lawyers who are legally forbidden from reading each other's cases.

The idea itself is good. Your notes, emails, and documents can become a knowledge base an LLM reasons over. Instead of retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked set of markdown files sitting between you and the raw sources. Knowledge gets compiled once and kept current, rather than re-derived on every query.

1. The source idea: knowledge as a compiled artifact

Karpathy reached for an analogy from software engineering: compilation.

You don't execute source code every time you want to run a program. You compile it once into a binary and run that. Treat knowledge the same way. Your PDFs and notes are the source code; the wiki is the binary. Figure 2 puts the two side by side.

Figure 2 — The same move, applied to knowledge instead of code.

The problems it removes

• Repeated retrieval — the same passages get pulled out of the same documents on every related question.
• Repeated summarization — the model re-compresses material it already compressed before.
• Duplicated reasoning — a conclusion previously reached on gets derived from scratch again on later-on.
• Weak long-term memory — nothing from a session survives it in a form the next session can use.
• Poor synthesis across many documents — connections that appear only when two sources are read together rarely surface at all.
• No accumulated knowledge — the system is exactly as informed on its thousandth query as on its first.

Set against retrieval-augmented generation, the trade is legible:

The wiki is a persistent, compounding artifact: it gets richer with every source added and every question asked. NotebookLM, ChatGPT file uploads, and most RAG systems do not do this.

The three-layer architecture

1. Raw sources — curated and immutable. The LLM reads them and never writes. Source of truth.
2. The wiki — LLM-generated markdown: summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. You read it; the LLM writes it.
3. The schema — a config document telling the LLM how the wiki is structured, what the conventions are, and what the workflows are. This is what makes the LLM a disciplined wiki maintainer rather than a generic chatbot.

Figure 3 shows how the three stack up.

Figure 3 — Three layers. Only the middle one is written by the model.

The three operations

• Ingest — drop a source in; the LLM reads it, discusses the takeaways, writes a summary page, updates the index, updates related entity and concept pages, and appends to a log.
• Query — ask against the wiki; the LLM finds pages, reads them, and synthesizes an answer with citations. Good answers get filed back into the wiki as new pages, so explorations compound.
• Lint — a periodic health check for contradictions between pages, stale claims superseded by newer sources, orphan pages, concepts lacking their own page, missing cross-references, and data gaps.

Figure 4 — Every operation feeds the same artifact.

2. The gap — why you can't ship that as-is inside a legal platform

Five collisions between "personal wiki" and "multi-tenant legal SaaS."

1. What happens when two readers can't trust each other? Karpathy's wiki has exactly one person on both ends. A firm has around 30 lawyers sharing one AI, and two of them can be legally required not to know about each other's case. Lawyer A represents the buyer in an M&A deal; Lawyer B, at the same firm, represents a party suing that same buyer in an unrelated matter. If the AI's memory has no walls, Lawyer B's chat can surface a fact the model learned from Lawyer A's case.

2. What happens when a page merges two cases? A personal knowledge vault trusts its single reader with everything. A stored client page that quietly combines two matters isn't confusing UI — it's confidential data sitting somewhere it shouldn't. A client has two unrelated cases at the firm, and one stored client summary pulls facts from both. The moment that page is saved, information has crossed a wall it should never have crossed. Nobody even needs to read it wrong.

3. Who's going to maintain this thing? Karpathy's design depends on the owner actually opening the vault, reviewing summaries, and fixing bad pages. Lawyers bill hours and will not maintain a wiki. A wiki that needed a lawyer to review new pages weekly would be abandoned inside a month, and would then start feeding the AI stale, unverified notes — worse than no memory at all. So it has to be agent-internal: no UI, and no lawyer ever opens it.

4. What happens when refresh cost multiplies by every firm? One person re-summarizing their own notes is cheap and can happen on demand. A SaaS platform has to do it for every matter, in every firm, on every tenant database, without a human triggering it. If every document upload triggered an instant re-summary of the whole matter, a firm bulk-uploading 200 discovery documents would fire 200 expensive rewrites in a few minutes. That needs a budget-bounded design: flag now, batch-rewrite later.

5. What happens when the AI guesses wrong? If a personal wiki invents a detail about your own research notes, you catch it and shrug. If a matter summary invents a deadline or misstates a contract term, and a lawyer relies on it without checking the live file, the result is a missed deadline or a bad filing — real client harm, not an annoyance. The summary has to be strictly extractive and explicitly labeled non-authoritative.

3. How we tackled each gap

1. Let access decide what gets stored. Instead of one global knowledge base that everyone's questions draw from, we split the wiki along a single line: anything with one fixed audience — a case, and everyone already on it — can safely be written down, and anything whose audience changes depending on who is asking cannot. That one rule does the work of preventing leaks between walled-off cases, with no per-question permission checks bolted on afterward.

2. Never store the combined page at all. Rather than pre-writing a summary page for a client or a counterparty — which would necessarily blend every case they touch, across every lawyer — we compute that page on the fly each time someone asks, using only the cases that specific person is allowed to see. Nothing merged ever touches a disk. Two people asking the same question can get two different answers, by design.

3. Separate noticing from rewriting. When something changes on a case, we do the cheapest possible thing: flip a lightweight flag saying this one is out of date. The expensive thing — asking the model to rewrite the summary — happens in one batched pass overnight, across everything flagged that day. A case that changed fifty times in one day still gets rewritten once.

4. Force it to only ever repeat back what's real. The model writing a case summary is instructed to use only facts explicitly present in that case's own records, and to write less rather than invent detail when the records are thin. Every summary handed to a lawyer is labeled as orientation rather than fact, which nudges them to double-check before relying on it. We test that against a real model run, not just against the prompt wording, so a summary that quietly invents a date fails before it ships.

4. What we actually built — the Graph Memory Layer

The first design call: it's agent-internal. Nobody at the firm ever opens this wiki. There's no page for a lawyer to browse, nothing to approve, no folder to organize. It exists purely so the AI's own answers are sharper, and a lawyer only notices it as "the assistant already seemed to know where this case stood." That is a genuinely different product decision from the source idea, where a human sits on the other end of the wiki reading it. Here the AI is both the only writer and the only reader.

4.1 Mapping the three layers onto a law firm

• Raw sources stay exactly what they were: the firm's existing case records, documents, deadlines, invoices, drafts, and correspondence, plus the search index that already lets the AI find relevant passages inside documents. The memory layer neither touches nor duplicates any of it — that layer is read-only input.
• The wiki becomes two things: one rolling AI-written summary per case, and a simple connection map linking lawyers, cases, clients, and counterparties. Anything that would describe a person rather than a case — a client page, a counterparty page, a lawyer page — is deliberately not written down anywhere. It gets assembled fresh every time, for the one person asking.
• The schema — the rulebook telling the AI how to write and how to answer — lives in the instructions attached to the two tools described below, plus the instructions given to the model when it writes a case summary. Together they define what a summary may contain, in what shape and what tone, and what the AI is and isn't allowed to claim about it.

4.2 The graph: connections you don't have to ask an AI to invent

The interlinked part of the wiki is a small map with exactly four kinds of things on it: lawyers, cases, clients, and counterparties. Exactly three kinds of connection exist between them — a lawyer works on a case, a case is for a client, a case is against a counterparty.

None of that is invented by a model. Every connection is derived automatically from information the platform already holds: who is assigned to a case, which client it is for, which counterparty it is against. Because that is a straightforward derivation rather than a judgment call, rebuilding the whole map from scratch always produces the same result — so recomputing it is provably safe to do as often as needed, and costs nothing in AI usage.

Documents, emails, deadlines, and invoices are deliberately left off the map. Those are case contents, not connections: they feed into a case's summary and stay searchable the normal way, but they don't become nodes. Holding the map to four kinds of thing is what makes it possible to reason cleanly about who is allowed to see which connection.

4.3 The pages: one written summary per case

A case gets one rolling AI-written summary, kept current over time. It is scoped to cases specifically, and nothing broader, for one reason: a case has one fixed, known list of people allowed to see it. Anything broader — a summary about a client, say — would necessarily pull together facts from every case that client has ever had, mixing audiences that were never supposed to mix. That mixed record would be the leak.

Writing the summary is kept narrow. The AI sees only the case's own header information, its client and counterparty, and a bounded, recent slice of its documents, drafts, deadlines, invoices, and prior working notes. Nothing is pulled in from anywhere else, and every piece of text is capped to a short length. Every sentence in the result can be traced back to something that is actually part of that case's record, which is what keeps the summary a compression of real facts rather than a guess.

The instructions given to the model are strict on purpose: use only what's in front of you, never invent a date, a value, a deadline, or a relationship, keep it short, and if there isn't much to work with, write less rather than filling in the gaps. Every one of these summary-writing calls is logged the way every other AI call in the platform is, so its cost and behavior stay visible and auditable.

If generating a summary fails for any reason, the platform keeps the previous version and tries again later. Memory is a nice-to-have layered on top of the product, never something the product depends on to keep working.

4.4 Client, counterparty, and lawyer pages — computed, never stored

This is the most interesting design move in the whole thing.

For a client, a counterparty, or a lawyer, there is no stored page at all. Instead, the moment someone asks about one, the platform looks up every case that person is connected to and that the current viewer is specifically allowed to see, then stitches those case summaries into one answer on the spot.

4.5 Two ways for the AI to ask the wiki a question

The assistant gets two new abilities on top of everything it could already do.

• Walk the connection map. Given any lawyer, case, client, or counterparty, find what else it connects to. This doubles as a conflict-of-interest check: "does this counterparty show up in any other case?" is answered by walking the map from that counterparty's node. Results are capped to a sensible page size, so a very well-connected entity can't flood the conversation.
• Pull a brief. Given a case, return its stored summary. Given a client, counterparty, or lawyer, assemble their live brief as described above.

Both carry the same built-in discipline. The AI is told explicitly that these briefs are orientation and not ground truth, and that it should verify anything that actually matters against the live records before acting on it. Anything outside the current viewer's access simply doesn't appear, with no indication that it was ever hidden.

4.6 Making the wiki searchable by meaning, not just by name

Every case summary also becomes a search-by-meaning entry, so the assistant can find "the case about the commercial lease dispute" without knowing its exact name. That search is filtered like everything else: only cases the requesting viewer can actually see are searchable at all, so a case behind a wall can't surface just because it happens to be a strong semantic match. If the search index is ever unreachable, the summary itself still gets saved — searchability is a bonus layer, not a dependency.

4.7 Keeping the wiki current without making every action expensive

The source idea's ingest step assumes a human dropping in a file and supervising the process. Here, updates have to be invisible and cheap, because they happen constantly and automatically across many cases at once.

Whenever something relevant changes on a case — a document finishes processing, an analysis completes, a new draft appears — the platform does the cheapest possible thing and flips a flag saying this case's summary is now out of date. Nothing expensive happens at that moment.

Separately, once a night, the platform walks every case flagged that way and rewrites its summary, capped to a modest batch size per firm so one very active firm can't eat the whole run. A case that changed fifty times in a day still gets rewritten once, the next morning. If a rewrite fails, the case stays flagged and is retried the following night. If a brand-new case gets asked about before the first nightly run reaches it, its summary is generated on the spot rather than coming back empty. Each firm's refresh runs independently, so one firm having a bad night never affects another.

4.8 The wall — proving who can see what

One rule runs through the whole system: you can see a connection or a brief only if you could already see the case behind it.

Who can open a case was settled long before any of this existed — you own it, you're on its team, or you're a firm admin. The memory layer asks that same question and accepts the same answer. It never widens it. No one learns anything through memory that they couldn't have found by opening the case directly.

Three useful things follow from that.

Every connection belongs to exactly one case. So "can I see this connection?" collapses into "can I see this case?" — a question the product already answers. There is no second permission system to keep in sync with the first.

A case you can't see looks like a case that doesn't exist. Not "access denied," not a greyed-out row, not a count that doesn't add up. Nothing. Hidden and absent are indistinguishable, so the mere existence of a case never leaks.

Only reads care who's asking. A summary is written from one case's own contents, and what it says doesn't depend on who reads it later. That means the writing side never reasons about permissions at all — which is what keeps the rule in a single place instead of scattered across the code.

4.9 Roughly how big this was

In plain terms: a little over a thousand lines of new implementation, a test suite almost as large as the implementation itself, two new pieces of stored data — the connection map and the case-summary store — one new place summaries are made searchable by meaning, one nightly background job, and two new abilities exposed to the AI assistant.

Not a small feature, but a contained one. Most of the size is in getting the summary-writing and the access rule exactly right, not in the mechanics around them.