LLM Memory: Karpathy’s Maintained Wiki Pattern Explained

Karpathy’s LLM memory wiki pattern stores an assistant’s organized knowledge in a maintained collection of linked pages outside the chat. An LLM, a large language model that generates text, helps update those pages as you add material. The useful result is a record you can inspect and reuse, rather than another conversation to search.

A knowledge base also creates work: reviewing changes, resolving questions, and remembering what remains unfinished. fenbs can keep those project decisions, tasks, and handoffs alongside your wiki. It does not build or maintain the wiki for you.

What did Karpathy actually propose?

In his original LLM Wiki idea file↗ (opens in a new tab), Andrej Karpathy describes curated source material, an assistant-maintained wiki, and instructions governing that work. The assistant develops reusable pages from the sources and reads those pages for later questions. The document presents a pattern you adapt, rather than a finished app or a memory feature you enable.

His proposed activities include processing new material, answering questions, and checking the wiki for problems. An index helps navigation; a chronological log records updates. Those are the core elements of the proposal. The examples and review routine below are a suggested way to try it on a small work project, not a required Karpathy configuration.

If the terminology is new, start with what an LLM is and what agent memory means. A page in a folder only becomes useful to an assistant when that assistant can access it and is told when to read it.

What should a small working wiki contain?

Say a fictional design studio is researching how to explain a new service. Begin with a few approved source documents and one real question: what can the studio confidently promise? Keep experiments small enough that someone can compare every proposed conclusion with its evidence.

You can use a plain text editor. If you choose Obsidian, its data storage documentation↗ (opens in a new tab) explains that a vault is a local folder containing Markdown plain text files. Local files still need an intentional assistant connection and a backup plan. Their location alone says nothing about where an AI provider processes text.

How should you process the first source?

Set the boundary before requesting edits. Name the source the assistant may read and the pages it may propose changing. For the studio, start with the approved service description; leave unrelated client files outside the exercise. Ask for a proposed change list before allowing a broad rewrite.

1. Identify the source and version. Keep the original material available for checking.
2. Ask for candidate claims, each with a source location and any conditions attached to it.
3. Review the claims. Separate what the document states from what the assistant inferred.
4. Update only the relevant pages, preserving qualifications and marking unanswered questions.
5. Record the changed pages and the checks performed so another session can continue.

Suppose the document says delivery time depends on receiving complete materials. Reject a proposed wiki sentence that promises a fixed completion date. Keep the condition attached to the claim wherever it is used. The important output is an accurate explanation, even if the polished but inaccurate version sounds more appealing.

When should an answer become a saved page?

Save an answer when it will help with another question and someone has checked its evidence. A one-off request to shorten an email may not belong in the wiki. A reviewed explanation of what counts as complete materials could help the next proposal, onboarding document, and client conversation.

Before saving, ask whether the answer adds anything to the existing pages. Revise an existing explanation when that keeps one clear current account. Create a new page when it addresses a distinct question. Several almost identical summaries create an extra maintenance job and make it easier for conflicting versions to survive.

Label analysis as analysis. In the fictional studio, “clients may misunderstand the materials checklist” is a question to investigate. It should not become “clients misunderstand the checklist” merely because the assistant repeated it in an answer. Keep the evidence, uncertainty, and proposed follow-up together.

Who should review changes and resolve disagreements?

Choose a person responsible for accepting changes that matter to the work. Ask the assistant to show old and proposed wording, the reason for the change, and the source supporting it. Review qualifications as carefully as headlines. A missing exception can alter the meaning without making a sentence look obviously wrong.

When two sources disagree, preserve the disagreement until you understand it. They may refer to different service versions or different audiences. Ask which conditions apply rather than letting the assistant average the answers. If a person chooses a policy, record that choice separately from the source comparison.

For teams comfortable with Git, a tool that records file versions, the official commit history guide↗ (opens in a new tab) explains how to inspect recorded changes and their differences. A saved version helps you examine what changed; it does not prove that a claim is true. Use an equivalent reviewable version process if Git adds unnecessary friction.

Keep knowledge and authority distinct: an assistant can suggest clearer wording, but a person approves a new promise to clients. fenbs Decisions and rules can record that human choice so later assistants have a current instruction to read.

What maintenance should you schedule?

Review the pages affected whenever an important source changes. For the studio, a revised service description should prompt a check of service promises and proposal guidance. Do not assume that rewriting the source automatically updates every derived explanation. Keep a short list of pages that depend on it.

Periodically test the wiki with questions whose answers you can verify. Ask what is included, what remains uncertain, and which source supports an exception. Check for broken references and statements without evidence. An assistant admitting that the wiki cannot answer is more useful than a confident answer that quietly fills the gap.

For adjacent technical questions, see memory frameworks, memory management, how assistant memory works, Hindsight memory, and memory banks.

How to do this with fenbs

1. Create a free account and add the wiki project with its purpose and review owner.
2. Record the rules a person has chosen: approved sources, who accepts changes, and how to handle contradictory evidence.
3. Add tasks for the first source review and outstanding questions. Keep source references in the relevant notes so someone can verify the findings.
4. Connect a supported AI assistant using Integrations. Ask it to read the project context before the session and save progress afterward, including what was checked and the next step.

fenbs is free for one person, no credit card. It is not the right fit if you only want a Markdown wiki editor or an automatic document-ingestion system. Use it when a maintained knowledge base also needs people’s decisions, review tasks, and continuity between assistants. The second-brain hub covers the wider choice of knowledge workflows.