Andrej Karpathy recently suggested the idea of an LLM Wiki: a persistent wiki that an LLM incrementally builds and maintains. Instead of uploading documents into a RAG system and asking the LLM to rediscover the same information every time, the LLM compiles those documents into durable Markdown pages. When a new source is added, the LLM reads it, extracts the important parts, updates the relevant pages, and leaves behind synthesis that can compound over time.
That pattern is powerful because it turns knowledge management from repeated retrieval into maintained context. The useful output is not only an answer to the current question, but an improved working environment for the next question.
This post is a companion idea file to Karpathy’s LLM Wiki. The short version is: an LLM Wiki becomes more useful when subjective context is treated as a first-class source too. Call this LLM Wiki with Opinions. Here, “opinions” means the preferences, constraints, decisions, and working assumptions that shape how knowledge becomes useful.
The core idea
The original LLM Wiki framing emphasizes immutable raw sources as the foundation: articles, papers, books, notes, transcripts, and other external documents. The LLM reads those sources and compiles them into a maintained wiki.
That is still the foundation. But in practice, subjective context also compounds.
For example, a research paper’s factual claims should be preserved as faithfully as possible. Its methods, results, and limitations should not be rewritten to match the user’s preferences. But the usefulness of that paper can depend heavily on the user’s context:
- A researcher may want conclusions and limitations before implementation details.
- A builder may care more about practical constraints than theoretical framing.
- A reader comparing many papers may want tables rather than long prose.
- A person with limited hardware, budget, time, or domain access may need the system to flag which claims are actually actionable.
- A team may care about whether a source supports an existing business decision, product constraint, or operating principle.
None of these are immutable facts about the source. They are facts about the context in which the source will be used. But they still matter. If the LLM knows them, the next ingest or query can be more useful without the user repeating the same instructions every time.
This is the key extension: the system should not only compile external knowledge; it should also compile the user’s working context.
This extends the schema idea, but it is not only schema. A schema tells the LLM how to maintain the wiki. Subjective context tells the LLM how the wiki should be useful for a particular user, project, team, or decision process. Some of that context becomes schema-like instructions, but some of it is better treated as memory, a wiki page, or a task-specific workflow.
Subjective context also behaves differently from raw sources. A research paper’s conclusion will not change next month. A user’s preference for how to evaluate papers might change as their use case evolves. A source can be treated as provenance; a preference is often better treated as a current working assumption. That means subjective context should not be maintained with exactly the same rules as objective source material.
So the goal is not simply to dump opinions into the wiki. The goal is to let personal context become durable while preserving the distinction between:
- external facts,
- source metadata and provenance,
- synthesized knowledge,
- personal preferences,
- reusable procedures,
- and current task state.
Architecture
Karpathy’s LLM Wiki is framed as three layers:
- Raw sources — immutable source documents.
- The wiki — LLM-generated Markdown pages that synthesize those sources.
- The schema — instructions that tell the LLM how to maintain the wiki.
In LLM Wiki with Opinions, both the source layer and the instruction layer start to split apart. Once the system is also learning preferences and helping with actual work, a single folder of sources and a single schema file can become too blunt. Different kinds of durable context have different lifecycles.
Raw sources
Raw sources are still the foundation. These are external materials like articles, papers, blog posts, documentation, transcripts, books, and other source documents. They should be preserved as source material, not rewritten into whatever the LLM currently thinks the user believes.
This part is very close to the original LLM Wiki idea. Obsidian Web Clipper, Markdown files, local assets, and a simple folder of raw sources are all still useful.
But the source layer can split too. A system may need to distinguish:
- immutable external sources,
- raw personal notes,
- conversation transcripts,
- task artifacts,
- inventory or environment facts,
- and generated backups.
These are all useful inputs, but they do not deserve identical treatment. A clipped paper, a meeting transcript, a corrected preference, and a local machine inventory can all inform future work, but they have different provenance and update rules.
Memory and reusable instructions
Memory or profile is where compact subjective context belongs: preferences, stable facts about the user, recurring corrections, and working assumptions that should affect many future tasks.
This can include preferences such as concise answers, checkpoint-sized setup guidance, source-verification standards, preferred output formats, or operational boundaries that the agent should not cross without approval.
The important constraint is compactness. If everything goes into always-loaded memory, it becomes noisy and expensive. Memory should hold the small facts that are likely to matter across many future tasks.
There is also a conflict risk. A user might prefer concise answers for routine status updates, but detailed reasoning for research reviews. If both preferences are always loaded without context, the agent may apply the wrong one. Keeping always-loaded memory small, and moving detailed procedures into task-specific instructions, makes preferences easier to apply only when they are relevant.
Reusable instructions are a practical extension of the schema layer.
A schema file is enough when the task is mostly “maintain this wiki in this style.” But once subjective context includes procedures, the instructions can get large. Some preferences are really workflows:
- how to ingest a research paper,
- how to plan a trip under specific constraints,
- how to update a business CRM or customer-note system,
- how to decide whether something belongs in memory or the wiki,
- how to collaborate on a draft without overwriting the author’s voice.
These do not need to be loaded into every task. They should be available when relevant. A system can treat them as separate reusable instruction files: smaller than a full wiki, more procedural than memory, and more targeted than a global schema.
This also makes the schema less monolithic. The effective schema becomes a composition of general wiki rules, compact memory, and task-specific procedures.
The wiki
The wiki remains the human-readable synthesis layer. It is where durable conclusions, decisions, comparisons, current-state notes, and reference material live.
In LLM Wiki with Opinions, the wiki can include subjective context, but usually at the level of reusable synthesis rather than tiny interaction preferences. For example:
- A travel wiki might preserve destination research as sources, but also maintain a page on the traveler’s constraints: budget range, mobility limits, preferred pace, food restrictions, and tolerance for logistical complexity.
- A business wiki might preserve customer interviews as sources, but also maintain a page on product strategy, target customer assumptions, and decision criteria.
- A reading wiki might preserve book notes as sources, but also maintain a page on the reader’s current questions, recurring interests, and preferred comparison dimensions.
- A personal productivity wiki might preserve logs and references, but also maintain a page on which habits are currently worth tracking and which are intentionally ignored.
These pages are subjective, but still browsable and useful. They are not just prompt fragments. They are part of the maintained knowledge environment.
This distinction keeps the wiki from becoming a junk drawer. The wiki should remain something a human can browse and understand.
Operations
Many operations remain the same as in the original LLM Wiki:
- Add raw sources.
- Ask the LLM to ingest them.
- Update the wiki.
- Maintain an index.
- Query the wiki later.
- Periodically check for broken links, stale claims, or contradictions.
The new work starts when the input is not a document but a preference, correction, constraint, or decision.
Querying with subjective context
For raw sources, querying is mostly the same as Karpathy’s version: the LLM searches the wiki, reads relevant pages, and answers from the accumulated synthesis.
The difference is that the answer can also account for subjective context.
A normal LLM Wiki can answer, “What did these papers say?” An LLM Wiki with Opinions can answer closer to, “Given what these papers say and this user’s constraints, what should matter most?”
For example, suppose the wiki contains notes on several tools for running local LLMs. A generic answer might compare accuracy, speed, and installation steps. A subjective-context-aware answer might also know that the user has limited GPU memory, dislikes fragile setup work, and mainly wants a reliable weekend project. The answer can then start with the option most likely to fit those constraints, rather than treating every criterion as equally important.
The system should still ask clarifying questions when the relevant preference or constraint is not already captured. Subjective context is not a substitute for asking the user; it is a way to avoid asking the same questions repeatedly.
This matters because many useful questions are not purely factual. They involve judgment, priorities, taste, and constraints. If the LLM knows those constraints, it can give a better first answer and ask fewer repeated clarification questions.
Capturing preferences
Preferences can be captured explicitly or implicitly.
Explicit capture is straightforward. A user might say:
Remember that concise, direct answers are preferred.
or:
For setup instructions, give only the next checkpoint in detail.
Those are stable enough and broad enough to save as memory.
Implicit capture is more interesting. Often, the user does not start by saying a preference abstractly. The preference appears as a correction during real work. For example, the user may requery the LLM. In research, the user may ask for limitations before methodology because that is how they triage papers. In travel planning, the user may reject a technically optimal itinerary because it has too many hotel changes.
When that happens, the system should not only fix the current output. It should consider whether the correction should improve future behavior. That feedback loop is important. Without it, the LLM makes the same mistake next time. With it, normal collaboration becomes a way to improve the working environment.
Linting facts, revalidating preferences
Adding opinions creates a new maintenance problem: preferences go stale faster than facts.
A research paper’s conclusion will not change next month. A preference about a workflow might. If the system tries to keep every preference perfectly current all the time, maintenance becomes expensive again — the exact burden the LLM Wiki was supposed to reduce.
A good principle for subjective context is YAGNI: do not continuously audit every subjective preference. Revalidate it when it matters.
An outdated preference usually does not cause harm while it is sitting unused. It becomes relevant when the agent is about to act on it. At that point, correction is relatively cheap because the source of truth is the user. Unlike external facts, no web search or literature review is needed to determine whether a preference is still valid. The system can simply surface the relevant assumption when appropriate, and the user can say, “Actually, that changed.”
Objective claims still benefit from more traditional wiki linting: broken links, stale sources, contradictions, missing provenance, and unclear assumptions. Subjective context needs a lighter touch. It should be cheap to save, cheap to correct, and easy to override.
Routing corrections to durable context
The most valuable part of this setup is not that the LLM writes a note once. It is that corrections can become durable.
The loop is:
- The agent does work.
- The user corrects or redirects it.
- The agent updates the current output.
- The system considers whether future behavior should change.
- If yes, the correction is routed to the right durable layer.
The routing question matters, but it is secondary. The main point is that the system can learn from corrections. Once that is true, placement becomes an implementation detail:
- A broad interaction preference may belong in memory.
- A document-shape correction may belong in wiki conventions.
- A recurring procedure may belong in a skill or instruction file.
- A concrete decision may belong in the wiki.
- A one-off correction may belong nowhere permanent.
This is also why the system should not save everything. The value comes from changing future behavior where appropriate, not from making every sentence permanent.
Tips and tricks
- Obsidian is very useful for browsing and raw capture. It is a strong interface for Markdown, links, local assets, and clipping external documents. Subjective context often emerges through conversation and task execution, so the agent also needs a way to capture corrections and decisions.
- Version control is useful. If an LLM is writing durable notes, Git provides diffs, rollback, provenance, branch-based experiments, and a review surface for changes the user did not personally type.
- Split the schema only when it starts to hurt. A single schema file is easy to start with. YAGNI still applies: do not split instructions just to make the system look more organized. But if the schema grows into detailed procedures, edge cases, or tool-specific workflows, the agent can suggest moving a recurring procedure into a separate skill or instruction file.
- Keep memory compact. Always-loaded context should be reserved for small, broadly useful facts. Longer explanations, examples, and procedures usually belong in the wiki or in task-specific instructions.
- Use an agent, not just a chatbot, when execution matters. This post is mostly about subjective context, not execution. But the pattern becomes more powerful when the same system can read the wiki, update memory, load instructions, edit files, use Git, and run checks.
Why this works
The original LLM Wiki works because LLMs are good at the part of knowledge management humans usually abandon: bookkeeping. They can summarize, cross-reference, update, and reorganize without getting bored.
LLM Wiki with Opinions works for the same reason, but applies it to a different kind of bookkeeping. Personal preferences and working conventions are usually scattered across conversations, corrections, and half-remembered decisions. They are valuable, but annoying to maintain manually.
The LLM can help maintain that context, as long as the system respects the difference between facts and preferences. External sources need provenance and careful synthesis. Subjective context needs compactness, easy correction, and revalidation at the point of use.
This is not a replacement for Karpathy’s LLM Wiki. It is an extension of it. The raw-source wiki is still the foundation. The additional idea is that once an LLM is maintaining a wiki, it can also maintain the context that makes the wiki useful for a specific user, team, or project.
Relationship to the original LLM Wiki
Karpathy’s original post already hints at personal use cases: goals, health, psychology, self-improvement, business context, and other domains where the user’s own perspective matters. This post expands on that direction rather than arguing against the original framing.
The exact implementation does not matter as much as the separation of lifecycles. The pattern does not require a specific agent, folder structure, or memory system. The general shape is:
- preserve external sources,
- maintain a human-readable wiki,
- save compact personal context where it can actually affect future work,
- move recurring procedures out of the main prompt and into reusable instructions,
- version the system so changes are inspectable and reversible,
- and keep subjective context easy to correct.
That is the extension: not just a wiki of what has been read, but a wiki system that gradually learns how its user wants to work.