LLM Knowledge Bases (Karpathy pattern)

A personal-knowledge-management pattern where an LLM incrementally builds and maintains a persistent, interlinked markdown wiki instead of performing retrieval-augmented generation at query time. Andrej Karpathy's 3 April 2026 gist made this pattern famous, but the core idea predates it — several practitioners had been running structured compounding knowledge bases long before the gist went viral.

Key points

• Three layers by design ^[src-002]:

1. raw/ — immutable source documents (PDFs, articles, transcripts). Never edited.

2. wiki/ — LLM-generated markdown pages with cross-references, summaries, and concept maps. The LLM owns these.

3. Schema file (e.g. CLAUDE.md) — governs folder structure, citation rules, ingest workflow, and linting conventions.

Plus two load-bearing meta-files: index.md (category-organised catalogue, updated on every ingest) and log.md (chronological record of every operation).

• The workflow is simple: drop a source into raw/, tell the LLM to ingest it, and it creates or updates 10–15 wiki pages in one pass — extracting entities, concepts, relationships, and cross-references. Queries are answered by reading the index and following links, not by vector similarity search ^[src-002].

• Zero infrastructure: no embedding model, no vector database, no chunking pipeline. Just markdown files in a folder. Token cost per ingest: ~$2–5 for a major session (10–15 pages); linting <$1; queries negligible ^[src-002].

• The wiki is just markdown, which means any editor works. The role of Obsidian is to add a graph view for browsing — useful but optional ^[src-002].

• The schema file is the real innovation, not the wiki itself. Treating CLAUDE.md as "a living product requirements document for an AI colleague" scales far beyond knowledge management to any workflow that needs operational knowledge encoded for the LLM to follow autonomously ^[src-002].
• Karpathy's Sequoia interview adds the cognitive reason this pattern matters: even when LLMs can outsource thinking, humans cannot outsource understanding, and wiki-style projections help information make it into the human's own mental model ^[src-055].
• Jack Roberts places the same pattern inside a broader AI memory operating system: Obsidian/markdown is the readable long-term memory option, while Pinecone/vector memory is the scalable semantic-search option ^[src-059].

Why this matters for production AI

This pattern is a practical bridge between personal research, agent memory, and enterprise AI operations. It shows how durable markdown, explicit schemas, and human-readable indexes can turn LLM work from one-off chat into an auditable knowledge system.

For production teams, the important lesson is not "replace RAG with markdown." It is that AI systems need an operating layer: source discipline, clear ownership, versioned knowledge, quality checks, and a way for humans to inspect what the AI thinks it knows.

Related portfolio proof:

• Enterprise AI in Production — how AI systems move beyond prototypes into governed operating models.
• Measurement and Experimentation — how AI work is evaluated through business outcomes, not only technical demos.
• AI Knowledge Graph — the live graph view of this wiki as a machine-readable and human-browsable knowledge layer.

Strengths and limits

Strengths: reliability (no retrieval misses — the LLM reads the index directly), zero infrastructure, excellent human readability, version-controlled via git.

Limits ^[src-002]:

• Scale ceiling around ~200 pages / ~100K tokens of index + content. Beyond that, the LLM can't hold the index in context and you need sub-wikis or a retrieval layer.
• Deduplication is LLM-dependent and fragile at scale — without a deterministic guard, the wiki will accumulate near-duplicate pages over time.
• Temporal signal is weak: a single "last updated" field loses the trend-tracking capability a relational store would give you (first_seen / last_seen).
• Single-user by default: no access control, no merge conflicts, no audit trail beyond the log file.

When to use it vs alternatives ^[src-002]

Related entities

• Claude Code — the runtime used by Karpathy's reference implementation
• Obsidian — the reference browsing layer
• Pinecone — vector-memory alternative for scalable semantic search
• Jack Roberts — practical memory-system workflow source
• Paperclip — related pattern (multi-agent orchestration) that also uses a schema-driven approach

Related concepts

• Agent Orchestration
• Retrieval-Augmented Generation (RAG)
• Understanding Bottleneck
• Software 3.0
• AI Memory Operating System
• Conversation Wrap-Up Memory
• Expert Knowledge Index

Source references

• ^[src-002] Robin Cartier — "Karpathy's LLM Knowledge Base: A Practitioner's Verdict" (2026-04-08)
• ^[src-055] Sequoia Capital — "Andrej Karpathy: From Vibe Coding to Agentic Engineering" (2026-04-29)
• ^[src-059] Jack Roberts — "This Memory System just 10x'd Claude Code" (2026-05-03)