The LLM Wiki Pattern: Giving Your Agent Persistent Memory

There is a pattern Andrej Karpathy wrote about recently called the LLM Wiki.

The idea is simple but paradigm-shifting: instead of stuffing the context window every time you boot up an agent, or trying to rely on stateless RAG lookups across your codebase, you give the agent the ability to maintain a living knowledge base about your project. It writes its own pages. It reads its own pages. It updates them when things change.

It works beautifully for stable knowledge—domain rules, overall architecture, and high-level decisions. Things you append to, more often than you change.

The Schema Constraint

But here is where things get messy: if you attempt to use an LLM Wiki for granular coding implementations, it rots. The details of functions and API routes change daily, and if you force an agent to document every single function, the wiki falls hopelessly out of sync with your actual codebase.

The solution is the schema constraint. We tell the agent to completely ignore fast-moving implementation code, and strictly document stable foundations like architecture graphs and data models.

Building it in Antigravity

I built this exact system for the Antigravity agent. It’s not a complex external extension—it relies on three simple primitives Antigravity already provides natively: a Skill, a Workflow, and a Rule.

1. The Skill (The Brain): This teaches the agent what an LLM Wiki is. It defines how markdown pages should be structured, how confidence strings decay over time, and exactly how old pages get superseded instead of outright deleted.
2. The Workflows (The Procedures): These are the explicit manual triggers: /wiki init, /wiki ingest, /wiki sync, and /wiki lint.
3. The Rule (Always-On): This rule forces the agent to read the wiki’s table of contents every time a session boots, and forces it to automatically run a sync after it performs any source-changing work.

The critical piece that pulls this together is a per-repo schema that lives inside the wiki itself. This schema decides what gets documented and what gets ignored.

Four Case Studies

To see this in action, we evaluated four distinct lifecycles of an LLM Wiki running across a single-page Gemma 4 front-end application.

1. Bootstrapping a Wiki (/wiki init)

For a fresh project without documentation, we trigger the bootstrap. The workflow injects a default schema from the agent’s Skill. The agent scans the entire repository and automatically drafts an overview page, module pages, an architecture tree, and a glossary.

Every page gets front-matter injected containing a title, a last-updated date, references to the exact source files it governs, and a ‘confidence’ rating. An index.md is generated as the master table of contents, and a log.md is initialized to record every operation the agent performs inside the wiki.

2. The Fresh Session Briefing

When you open a brand new Antigravity chat with zero prior context, the “Always-On” rule immediately fires. The agent reads index.md, loads the high-level overview, and instantly briefs itself—without you needing to explain the project.

This relies on the compile-and-synthesize pattern. The agent isn’t wastefully searching the raw codebase to figure out what it’s looking at; it is reading distilled, agent-written notes that it trusts because it wrote them and they possess passing confidence scores.

3. Auto-Sync on Code Change

If you ask the agent to apply an update to your UI (like a label tweak in index.html), the “Always-On” rule dictates a post-action /wiki sync.

Sync is the lightweight cousin of a full ingest. It quickly diffs the working tree against HEAD, identifies which wiki pages govern the changed files, and surgically updates only those pages. If an update touches more than ten wiki pages, the system defers to a deep /wiki ingest to prevent the agent from spiraling during massive refactors.

4. Running the Linter (/wiki lint)

The linter doesn’t auto-fix; it runs seven distinct health checks (staleness, drift, orphans, gaps, contradictions, redundancy, and front-matter hygiene) and proposes changes.

In testing, the linter caught semantic drift where a data-model page claimed a thinkingLevel was MAX, but the raw code had been quietly downgraded to HIGH. This single tool prevents the exact class of bug the LLM Wiki is meant to solve: documentation that is silently lying.

Lifecycle and Confidence Decay

A key component of this architecture is staleness tracking.

Every wiki page tracks the git commit hash it was last synced against. Every time you push a new commit that touches tracked source files, that page’s confidence rating inherently degrades. Zero commits behind guarantees high confidence. One to four commits behind degrades it to medium. Five or more commits marks it as low, signaling the agent to re-verify the codebase against the wiki before trusting its own memory.

Pages are also never silently deleted. When an architectural decision is overturned, the old page gets a supersession note pointing to the newly generated one, preserving all historical context for future sessions.

The Bottom Line

This wiki pattern lives entirely inside your repository under .agents. If you like the workflows, you can easily promote them to global accessibility.

I utilize this pattern heavily across stable builds, where the value isn’t purely speed—it’s preventing the catastrophic accidental deletion of critical code because the standalone agent lost track of what was load-bearing.

For full implementation steps and source code, check the repository link below.