Karpathy Wiki: Master LLM Patterns & Durable Context

The surprising part of the Karpathy Wiki pattern isn't that it works. It's that for the right scope, it can outperform the default instinct to build another retrieval stack. One writeup of the pattern says it uses plain text and Markdown instead of vector databases and is 70 times more efficient than traditional RAG systems because it avoids complex indexing and retrieval pipelines, feeding the compiled knowledge base directly into a long-context model at query time instead (MindStudio on the Karpathy LLM Wiki pattern).

That claim got attention because it points at a real architectural shift. The Karpathy Wiki doesn't treat knowledge as a bag of documents to re-search on every question. It treats knowledge as something you compile, structure, inspect, and carry forward. That's a big improvement over ad hoc prompts against raw files.

It's also incomplete.

The original pattern is excellent for personal knowledge work. It is not, by itself, a production architecture for tool-connected agents, shared team memory, or regulated operational workflows. That's where most of the interesting engineering starts.

The Karpathy Wiki Pattern Explained

Andrej Karpathy formally released the LLM Wiki pattern in April 2026 as a persistent, compounding artifact where a large language model incrementally builds and maintains a structured, interlinked collection of Markdown files that sits between raw source documents and user queries, instead of relying only on real-time retrieval from unstructured data (Global Advisors summary of the April 2026 release).

That definition matters because it shifts the unit of work. In a standard retrieval setup, the system keeps rediscovering relevant fragments. In a Karpathy Wiki, the model turns source material into durable knowledge objects: summaries, concept pages, entity profiles, comparisons, and syntheses. The wiki becomes the working memory substrate.

What makes the pattern different

A Karpathy Wiki is best understood as compiled context.

The raw documents still exist, but users don't interrogate them directly for every question. The model reads source material, distills it into linked Markdown pages, updates only what changed, and leaves behind a human-readable artifact that compounds over time. That gives you a knowledge base you can inspect with git, edit by hand if you must, and move between tools without dragging along a proprietary storage layer.

A good Karpathy Wiki isn't just searchable. It's legible. You can open the files and see what the system believes.

That legibility is why the pattern resonated with developers. The output isn't a hidden embedding index or a vendor-specific memory store. It's a file tree.

Why it gained traction so quickly

The pattern also addresses two common complaints about LLM systems. One is hallucination risk from weak grounding. The other is stale knowledge when the model hasn't incorporated later material. The wiki pattern tries to reduce both by making the model maintain a persistent, evolving knowledge substrate instead of improvising against raw data on demand.

The key insight is simple: if the model already did the synthesis work, later queries can operate over a cleaner, more deliberate representation of knowledge.

That's the strength of the Karpathy Wiki. The weakness is that a durable wiki is still only half the system.

Core Principles of the LLM Wiki Architecture

The architecture works because it separates truth, synthesis, and structure. That sounds simple, but in practice it solves a hard problem: keeping model-generated knowledge editable by humans without letting the model overwrite the source of record.

The three layers

A useful implementation model has three layers, each with a different failure mode and maintenance pattern.

Layer	What lives there	Why it matters
Raw sources	Original documents and inputs	These remain the reference record. The system reads them, but does not rewrite them.
Wiki layer	Agent-owned Markdown files	This layer stores summaries, entity pages, concept pages, and links that the model can revise over time.
Schema	Structure and tag taxonomy	This defines how pages should be named, linked, grouped, and updated so the wiki does not drift into a pile of notes.

That separation matters for more than cleanliness. It gives you an audit path. If a wiki page is wrong, you can trace it back to the source document and the schema rule that shaped the output. In production, that is the difference between fixing a page and debugging a black box.

Why Markdown is the right storage format

Markdown is a practical storage choice, not a nostalgic one. Teams can inspect it in git, review it in pull requests, patch it by hand, and move it between tools without exporting from a proprietary memory layer.

It also creates a better security posture.

Plain files are easier to permission, snapshot, diff, and back up than hidden model state. They also make accidental scope creep easier to catch. If a generator starts writing sensitive material into the wrong folder, that mistake is visible in the repository instead of buried inside an index.

Vector search still has a place. It helps when recall over large, messy corpora matters more than editorial structure. The wiki pattern makes the opposite trade. It spends compute up front to create pages that already express relationships, so later retrieval can operate over organized knowledge instead of raw fragments.

Incremental compilation keeps the system maintainable

The strongest idea in the pattern is incremental maintenance. Rebuild only the pages affected by changed inputs. Leave the rest alone.

That keeps cost under control, but the bigger benefit is stability. Full regeneration tends to create churn in links, summaries, and page boundaries, which makes review harder and trust lower. Incremental updates preserve the parts of the wiki that already survived inspection.

I treat this like a build pipeline. Sources are inputs. Markdown pages are artifacts. The schema is the build contract. If you want a broader system-design view of that approach, the idea maps closely to an AI context layer built for repeatable retrieval and controlled updates.

Structure beats prompt cleverness

A good LLM wiki depends less on heroic prompting than on disciplined constraints. Clear page types, predictable frontmatter, stable file paths, and explicit linking rules do more for quality than squeezing another paragraph into the system prompt.

That is also where the original pattern starts to show its limits. The architecture is strong for knowledge compilation, but it assumes a relatively bounded corpus and a human operator who can tolerate manual review. Once the corpus grows, multiple contributors touch the wiki, or downstream systems depend on page correctness, the schema stops being a convenience and becomes operational infrastructure.

Practical Limitations of the Original Pattern

The original pattern is strong as a knowledge compilation method. It is incomplete as an operating model.

A personal Markdown wiki can tolerate manual review, implicit trust, and occasional inconsistencies. Production systems cannot. Once the wiki starts informing tickets, deployments, customer workflows, or agent decisions, the design constraints change. The question is no longer whether the model can write a useful page. The question is whether the surrounding system can control change, enforce access, and keep reasoning separate from side effects.

It stops before execution

The base pattern ends at organized knowledge. That is a useful stopping point for research and note synthesis. It is the wrong stopping point for software that needs to act safely.

In a real deployment, the highest-risk step is not retrieval. It is the transition from "the system found relevant context" to "the system is allowed to do something with it." If the same component both reasons and executes, review gets harder, permission boundaries get blurry, and mistakes carry a larger blast radius.

Three gaps show up quickly:

• No planning and execution split means the system has no clean control point for approval, policy checks, or human review
• No standard tool handoff means external actions become custom glue code instead of a governed interface
• No credential isolation model means secrets tend to drift toward the part of the stack that should only reason over text

That is the main practical limitation. The wiki pattern explains how to accumulate context. It does not explain how to operationalize that context without mixing knowledge, authority, and action.

Team scale exposes file-based limits

The second problem appears as soon as the wiki becomes shared infrastructure instead of a single-user asset.

Flat files and generated indexes are workable for one operator who understands the corpus and can inspect changes manually. They become harder to manage when multiple engineers, analysts, or agents update the same knowledge base concurrently. Merge conflicts are the obvious issue. The more serious issues are consistency, reviewability, and governance. Teams need to know who changed what, which pages are safe to trust, and whether downstream automations are reading approved content or half-finished drafts.

Analysts at Atlan's comparison of LLM wikis and RAG knowledge bases point to the same pressure points: context limits, coordination problems, and weak transactional guarantees. Those are not minor implementation details. They determine whether the pattern stays useful after the prototype phase.

What breaks first

In practice, the failure modes are predictable:

Limitation	Why it matters in production
Global index growth	Retrieval quality degrades once the system relies on an index the model cannot consume or rank reliably.
Concurrent edits	Shared Markdown workflows need extra controls to prevent collisions, stale summaries, and accidental overwrites.
Weak governance	Base wiki patterns do not define approvals, access boundaries, or audit trails for sensitive knowledge.
No action layer	Useful context remains trapped in documents instead of feeding controlled tools and workflows.

The practical takeaway is straightforward. Karpathy's pattern is a strong primitive, not a full system. Developers who want to run it as operational infrastructure need another layer that adds controlled execution, reviewable interfaces, and security boundaries. That is the gap Geode's open-source context vault architecture is trying to close.

Geode An Operationalized Karpathy Wiki

The most useful way to extend the Karpathy Wiki pattern is to keep what made it good, readable Markdown, compounding context, and durable structure, while adding the missing operational boundary between knowledge and action.

A direct lineage exists here. Geode describes Karpathy's LLM wiki concept as a persistent, compounding Markdown knowledge base with a schema, an index, and a change log maintained through ingest, query, and lint operations, and positions that as the basis for tool-agnostic AI context vaults (Geode on the lineage from LLM wiki to context vaults).

The missing architectural move

The critical addition is a vault agent that reasons over the knowledge base but doesn't execute external actions itself.

That's the right boundary.

In a production-grade setup, the planning component should inspect context, interpret requests, and produce a response or execution plan. It should not hold credentials, call remote systems directly, or blur reasoning with side effects. That separation reduces blast radius and makes the system easier to audit.

What ships today versus what's still being built

For a technical audience, this distinction matters more than branding.

Live today:

• Single MCP endpoint for connected assistants
• query, remember, and list_capabilities
• Git-backed OKF vault using plain Markdown with frontmatter
• Secret broker plus caller-only invoke for HTTP connections
• Artifacts
• Operator dashboard
• Bring-your-own-model support, including local and cloud models

Still in development:

• Repo, CLI, and OAuth integrations installer
• Team features such as shared vaults, roles, audit logs, and SSO
• Hardened container-level credential isolation
• Private Managed deployments

That split is important because a lot of AI infrastructure writing implicitly mixes roadmap with present capability. Engineers notice.

The cleanest design choice here is that the vault agent plans, but the calling assistant executes. That keeps the context layer specialized.

Why MCP and OKF matter

Two terms deserve a direct definition.

MCP means Model Context Protocol. It's an open protocol for exposing tools and context to AI clients in a standard way. The practical benefit is interoperability. You're not binding your memory layer to one assistant.

OKF means Open Knowledge Format in this context. It's a git-backed, file-based vault structure using Markdown and frontmatter as durable, inspectable storage.

That combination solves a problem the original Karpathy Wiki left open. The wiki becomes not just a body of text, but a governed context layer beneath interchangeable front-ends. Knowledge persists even when assistants change.

How to Navigate and Grow Your Knowledge Base

A Karpathy-style knowledge base becomes useful when it supports two loops well: retrieval and compounding. Retrieval answers the current question. Compounding makes the next answer better.

Start with query

query is the read path. You ask in natural language, and the vault layer reasons over the stored Markdown graph rather than a one-off prompt history.

A simple interaction looks like this:

query "Summarize our deployment process for customer-facing API changes"

Or with more context:

query "What decisions have we already made about invoice timing for Client X, and where are the relevant notes?"

Good query behavior depends on the quality of the vault, not just the quality of the model. If the wiki files are organized around stable concepts, entities, and SOPs, the answer can point at accumulated knowledge rather than recomposing everything from fragments.

For teams that want a file-based approach, a Markdown knowledge base is the practical substrate here. You can inspect it, diff it, and refactor it without decoding an opaque memory store.

Then use remember to compound value

remember is the write path, at which point the system stops behaving like a chatbot and starts behaving like a maintained knowledge base.

remember "Client X wants invoices issued on the 1st with net-30 terms."

That input should not land as a random note appended to a pile. The useful behavior is richer:

• Re-distill the input into a stable fact or policy statement
• File it in the right place instead of dumping it into a generic inbox
• Deduplicate against existing notes so the vault doesn't drift
• Cross-reference related pages such as the client record, billing SOP, and operations notes

Working habit: If a fact would matter again in a month, store it with remember instead of trusting chat history.

That compounding loop is what gives the pattern staying power. Every saved learning can improve future queries across connected assistants, because the memory lives in the vault, not inside one vendor's session state.

Here's a short walkthrough before going deeper into action paths:

A small command set beats a sprawling UI

The most effective systems here tend to stay narrow. query retrieves. remember compounds. list_capabilities shows what the vault exposes. That small surface area is easier to trust than a large assistant-specific feature set with hidden state.

The quality bar is simple. If a developer can read the files and understand why the answer came back, the knowledge base is doing its job.

Securely Connecting Your Wiki to External Tools

The hard part isn't storing knowledge. It's letting knowledge drive actions without leaking secrets into the model.

A safe implementation keeps three roles separate:

1. The vault agent reads the context and plans.
2. The caller or assistant requests execution.
3. The kernel performs the sensitive integration work server-side.

That separation is the difference between a useful tool layer and a dangerous one.

The vault agent should never execute

This rule should be absolute. The vault agent can inspect notes, recipes, SOPs, and manifests. It can decide that a given task requires an API call or another tool action. It should then return a plan or a structured capability for the caller to use.

It should not run the external action itself.

That boundary matters for two reasons. First, it keeps the planning system specialized. Second, it prevents the component with the broadest contextual view from also being the component that holds operational power.

Secrets should stay outside the model's prompt, outside the vault files, and outside the agent's direct reach.

How invoke should work

invoke is the bridge from plan to action.

A practical flow looks like this:

list_capabilities

invoke "billing.create_invoice" \
  --input '{"client":"Client X","issue_date":"2026-05-01"}'

Under the hood, the important detail is not the command syntax. It's the execution model:

Step	What happens
Plan	The vault agent identifies the relevant capability and required inputs.
Call	The assistant issues invoke against the declared action.
Inject	The kernel fetches the referenced secret from the broker and injects it server-side at runtime.
Return	The system returns the result, not the credential.

This model turns a messy external API or local integration into a named capability with a manifest. The manifest belongs in the vault because it describes how the team works. The secret does not. Only the secret reference belongs in the declarative config.

Manifests keep tools readable

A lightweight manifest might look like this:

name: billing.create_invoice
type: http
method: POST
path: /invoices
secrets:
  - billing_api_key_ref
inputs:
  - client
  - issue_date

That file is auditable. It says what action exists, what inputs it takes, and which secret reference it needs. It doesn't expose the secret value, and it doesn't require the model to reason over raw credential material.

When teams get this right, they stop treating agent tooling as magic. It becomes infrastructure.

Developer Workflows and Contribution Guidelines

A wiki pattern becomes operational only when contribution rules are as clear as the schema. If engineers do not know what belongs in the vault, how changes get reviewed, and when automation is allowed to write, the knowledge base drifts fast.

The practical gap in the original pattern shows up here. It demonstrates how an LLM can maintain linked Markdown, but it does not define the team workflow that keeps that memory reliable under ongoing change. Geode closes that gap by treating the vault as production infrastructure with ownership, review, and rollback.

Treat the vault like project infrastructure

A git-backed vault changes the failure mode. Every model-written edit can be inspected as a diff, attributed to a run, and reverted if it pollutes a page or breaks the link structure.

That should shape contribution policy from day one.

• Store durable knowledge. Procedures, customer-specific constraints, integration notes, and operating decisions belong here because they matter after the original conversation disappears.
• Write into existing structures. Update an SOP, entity page, glossary entry, or manifest before creating a new file. This keeps retrieval quality high and reduces duplicate summaries.
• Separate evidence from memory. Raw documents, tickets, and transcripts are source material. The vault should hold the distilled conclusion with enough context to verify it later.
• Require review for high-impact pages. Security procedures, billing logic, deployment runbooks, and external-tool manifests should not accept silent model writes.

Those rules sound strict. They save time. Teams that skip them usually end up with a repo full of plausible text and very little operational trust.

A contribution loop that holds up in production

Good workflows make model output easy to challenge.

A reliable loop looks like this:

1. Capture a new fact, decision, or procedure with remember.
2. Open the diff and check placement, wording, links, and scope.
3. Confirm the edit did not overwrite a stronger existing summary.
4. Merge the change only if a reviewer could understand and defend it later.
5. Run query against a realistic prompt to verify the vault returns the new knowledge cleanly.

This is the same discipline used for code and config. Memory deserves the same standard because bad memory creates bad actions.

What good contributions look like

The main review question is simple. Will this page still help someone six months from now, outside the chat that created it?

Good vault contribution	Weak vault contribution
Reusable without the original conversation	Depends on chat-specific context
Attached to an entity, concept, SOP, or manifest	Stored as an isolated note
States a decision, constraint, or procedure clearly	Reads like conversational residue
Easy to verify against source material	Hard to trace or justify

One more rule matters in practice. Do not let the agent become the only author who understands the structure. Humans need to recognize where knowledge should live, why a page exists, and what standard an edit must meet. That is the difference between an interesting personal wiki pattern and a shared system a team can trust.

Frequently Asked Questions

How is a Karpathy Wiki different from vector search or standard RAG

The difference is where synthesis happens.

In standard RAG, the system retrieves raw chunks at question time and asks the model to make sense of them on the fly. In a Karpathy Wiki, the model has already distilled source material into a persistent set of linked Markdown pages. Querying happens over that maintained knowledge artifact, not over freshly retrieved fragments.

That gives you a more inspectable system. You can open the files, review the summaries, and see how concepts connect.

Is this just personal note-taking with extra steps

No. Personal note-taking systems usually rely on humans to maintain the graph. The Karpathy Wiki pattern moves that maintenance burden onto the model. The important change isn't that the data lives in Markdown. It's that the model incrementally compiles, updates, and links the knowledge base for you.

That said, the original pattern is still best suited to personal or bounded use unless you add stronger operational boundaries and governance.

Can I use my own model, including local models

Yes, if the surrounding system supports bring-your-own-model. That's an important architectural choice because privacy-sensitive users often want both the context layer and the model runtime under their own control.

In practice, that means a context vault should work with cloud models and local engines such as Ollama, instead of hardcoding a single provider into the memory layer.

Is MCP proprietary

No. Model Context Protocol is an open standard for connecting AI clients to tools and context providers. The practical benefit is portability. Your assistant can change without forcing a memory migration.

That's the right fit for a durable knowledge layer, because the vault should outlast the current crop of front-end assistants.

Why not just put everything in one database

Because hidden storage makes memory harder to inspect, harder to move, and harder to trust.

A git-backed Markdown vault gives you readable files, diffs, normal backup workflows, and a clear separation between context, manifests, and secrets. For many developer workflows, those properties matter more than fancy retrieval plumbing.

Does a Karpathy Wiki eliminate hallucinations

No system eliminates them completely.

What this pattern does is improve grounding by storing curated, persistent, human-readable knowledge instead of making the model rediscover context from raw documents on each query. That's a meaningful improvement. It still depends on source quality, maintenance discipline, and good boundaries between synthesis, storage, and action.

What's the most important production lesson

Keep knowledge durable, keep tools declarative, and keep secrets out of the model.

If you get those three right, the Karpathy Wiki stops being an interesting note-taking pattern and starts becoming real infrastructure.

---

If you want to put this pattern into practice with an open, self-hostable context vault, take a look at Geode. It operationalizes the durable Markdown-first approach, exposes a single MCP endpoint, and keeps the planning layer separate from execution so your assistants can share one source of truth without dragging secrets through the model.