**Llm Wiki Architecture: Building Persistent AI Knowledge Bases**

The traditional approach to integrating Large Language Models (LLMs) with private data relies heavily on Retrieval-Augmented Generation (RAG). In a standard RAG system, a user uploads a collection of files, the system...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-28-conte-6ac26b11/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/Archive/2026-04-28/Content/LLM Wiki Architecture.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-28T00:17:19.0770106Z
Content hash	sha256:6ac26b1128d12f0b2f0b867a227d7f77b993d170728cfb3daace49b459e250b9
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-28-content-llm-wiki-architecture-6ac26b1128d1.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-28-content-llm-wiki-architecture-6ac26b1128d1.txt

Current File Content

Structure Preview

• **LLM Wiki Architecture: Building Persistent AI Knowledge Bases**
• **Introduction: The Shift from RAG to Compounding Knowledge**
• **The Three-Layer Architecture**
• **1\. Raw Sources**
• **2\. The Wiki**
• **3\. The Schema**
• **Core Operational Workflows**
• **Ingest**
• **Query**
• **Lint**
• **Navigational and State Management Files**
• **Trade-offs: LLM Wiki vs. RAG**
• **Works cited**

Raw Version

# **LLM Wiki Architecture: Building Persistent AI Knowledge Bases**

## **Introduction: The Shift from RAG to Compounding Knowledge**

The traditional approach to integrating Large Language Models (LLMs) with private data relies heavily on Retrieval-Augmented Generation (RAG). In a standard RAG system, a user uploads a collection of files, the system chunks and embeds them, and the LLM retrieves relevant fragments at query time to generate an answer.1 While effective for large-scale semantic search, this stateless approach forces the LLM to rediscover knowledge from scratch on every single query without building a foundational understanding.1

To solve this, AI researcher Andrej Karpathy proposed a paradigm-shifting alternative known as the "LLM Wiki".1 Rather than retrieving raw data on the fly, the LLM incrementally builds and maintains a structured, interlinked collection of plain markdown files that sits between the user and the raw sources.1 When a new source is added, the LLM reads it, extracts key information, and integrates it into an evolving wiki—updating entity pages, revising summaries, and explicitly tracking cross-references.1 In this architecture, the knowledge is compiled once and compounds over time, functioning less like a traditional database and more like a codebase where the LLM acts as the dedicated maintainer.

## **The Three-Layer Architecture**

The LLM Wiki architecture fundamentally separates the original source data from the LLM's synthesized knowledge and its operating instructions. It is organized into three distinct layers:

### **1\. Raw Sources**

This layer consists of a curated collection of original documents, such as PDFs, clipped articles, data files, and meeting transcripts.2 This directory (often simply named raw/) is completely immutable.3 The LLM reads from these files but is strictly prohibited from altering them, ensuring they serve as the absolute source of truth for grounding claims and preventing data loss.3

### **2\. The Wiki**

The core of the architecture is the wiki directory itself, which contains a highly structured collection of markdown files.1 These files include concept pages, entity summaries, comparison tables, and synthesized documentation.3 The LLM owns this layer entirely; it creates the pages, writes the content, and maintains the internal wiki-style links connecting related concepts.3 Because humans read this layer but rarely write to it, the files often utilize YAML front matter to track metadata like the page title, relevant tags, last-updated timestamps, and provenance (which raw sources contributed to the specific page).

### **3\. The Schema**

The schema is the critical configuration layer that governs the LLM's behavior. Usually defined in a single markdown file like CLAUDE.md, SCHEMA.md, or AGENTS.md, it acts as the instruction manual or "discipline" for the AI agent. The schema dictates the wiki's overall structure, the required naming conventions, hallucination prevention rules (such as enforcing explicit citations back to the raw sources), and the exact workflows the LLM must execute when processing data.3

## **Core Operational Workflows**

To keep the wiki alive, accurate, and consistently updated, the LLM is instructed via the schema to perform three primary operations:

### **Ingest**

When a new document is added to the raw sources, the LLM executes the ingest workflow.4 The agent reads the source, identifies key takeaways, and writes a summary page.4 Crucially, it then updates the central index and modifies all existing entity and concept pages that are relevant to the new information.4 A single new source might prompt the LLM to systematically update 10 to 15 interconnected pages, flagging any contradictions between the new data and old claims.1

### **Query**

When a user asks a question, the LLM searches the pre-compiled wiki rather than the raw data. It reads the relevant synthesized pages, generates an answer with citations, and can even save valuable new insights—such as a newly requested comparison between two concepts—back into the wiki as a brand new page.4 This ensures that complex syntheses generated during a chat session are permanently captured rather than lost in the chat history.4

### **Lint**

Because the LLM Wiki is a living document, it requires regular maintenance. The "Lint" operation is a periodic health-check workflow where the LLM scans the entire wiki directory to identify issues.4 During a linting pass, the agent searches for logical contradictions between pages, stale claims that need updating, missing cross-references, and "orphan" pages that lack inbound links.4

## **Navigational and State Management Files**

As the wiki scales, the LLM requires specific navigational files to understand the repository's state without needing to read every single file simultaneously:

* **index.md (or WIKI.md)**: A content-oriented catalog of every page in the wiki, usually accompanied by one-line summaries and tags. When performing a task or answering a query, the LLM reads the index first to orient itself and determine which specific pages it needs to open and read.4
* **log.md**: A chronological, append-only record of every semantic event performed by the LLM, such as ingests, queries, and lint passes. This file provides the agent with an immediate history of the wiki's recent evolution without needing to diff every file.4

## **Trade-offs: LLM Wiki vs. RAG**

While the LLM Wiki architecture provides superior synthesis and interconnected context, it is not a universal replacement for RAG pipelines.

The LLM Wiki excels in bounded, highly curated environments—such as personal research projects, codebases, or internal engineering wikis—where cross-referencing and architectural context matter more than raw data retrieval. However, the ingest process is computationally expensive because the LLM must actively read and compile the documents into markdown. Therefore, for enterprise deployments involving thousands of constantly churning documents, customer support logs, or legal search systems requiring strict, real-time citation traceability to the exact original text, traditional embedding-based RAG pipelines remain the more scalable architecture.

#### **Works cited**

1. llm-wiki · GitHub, accessed April 27, 2026, [https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
2. Beyond Traditional RAG: A Deep Dive into Andrej Karpathy's LLM ..., accessed April 27, 2026, [https://medium.com/@jiten.p.oswal/beyond-traditional-rag-a-deep-dive-into-andrej-karpathys-llm-wiki-concept-329cbeebd842](https://medium.com/@jiten.p.oswal/beyond-traditional-rag-a-deep-dive-into-andrej-karpathys-llm-wiki-concept-329cbeebd842)
3. I used Karpathy's LLM Wiki to build a knowledge base that maintains ..., accessed April 27, 2026, [https://medium.com/@k.balu124/i-used-karpathys-llm-wiki-to-build-a-knowledge-base-that-maintains-itself-with-ai-df968e4f5ea0](https://medium.com/@k.balu124/i-used-karpathys-llm-wiki-to-build-a-knowledge-base-that-maintains-itself-with-ai-df968e4f5ea0)
4. What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis | by ..., accessed April 27, 2026, [https://medium.com/@tahirbalarabe2/what-is-llm-wiki-pattern-persistent-knowledge-with-llm-wikis-3227f561abc1](https://medium.com/@tahirbalarabe2/what-is-llm-wiki-pattern-persistent-knowledge-with-llm-wikis-3227f561abc1)
5. LLM Wiki vs RAG for Internal Codebase Memory: Which Approach ..., accessed April 27, 2026, [https://www.mindstudio.ai/blog/llm-wiki-vs-rag-internal-codebase-memory](https://www.mindstudio.ai/blog/llm-wiki-vs-rag-internal-codebase-memory)

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: **LLM Wiki Architecture: Building Persistent AI Knowledge Bases**; **Introduction: The Shift from RAG to Compounding Knowledge**; **The Three-Layer Architecture**; **1\. Raw Sources**; **2\. The Wiki**; **3\. The Schema**; **Core Operational Workflows**; **Ingest**. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-509 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "**Llm Wiki Architecture: Building Persistent AI Knowledge Bases**",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-archive-2026-04-28-conte-6ac26b11/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/Archive/2026-04-28/Content/LLM Wiki Architecture.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:6ac26b1128d12f0b2f0b867a227d7f77b993d170728cfb3daace49b459e250b9",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-28T00:17:19.0770106Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-509",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}