---
title: "What is an LLM wiki and where does it break?"
description: "A definition of the LLM wiki, a standard implementation using Markdown and git, and its limitations for facts that change."
canonical: https://past.dev/blog/llm-wiki
date: 2026-08-30
category: Research
authors: The past.dev team
---
# What is an LLM wiki and where does it break?

An LLM wiki is a knowledge base maintained and read by AI systems. It commonly consists of Markdown files in a git repository. Agents read the files during a task and propose updates when the implementation or company process changes.

Andrej Karpathy described this approach in April 2026. Many engineering teams already use related files such as `CLAUDE.md`, `AGENTS.md` and repository rules.

## LLM wiki uses

An LLM wiki is suitable for information that changes slowly.

- **Conventions.** Naming rules, approved libraries and prohibited patterns.
- **Architecture.** Service responsibilities, dependencies and design decisions.
- **Runbooks.** Deployment, rollback and incident procedures.
- **Glossary.** Definitions of internal terms.
- **Decisions.** The selected option, date and supporting reasons.

This information is usually semantic or procedural memory. The [agentic memory article](/blog/agentic-memory) describes the common memory types.

## Standard implementation

1. Create a git repository containing Markdown files.
2. Store one topic in each file.
3. Maintain an index that lists the available files.
4. Instruct agents to read the index and then open only the relevant files.
5. Require agents to propose updates through pull requests.
6. Review and merge each update.

File search is often sufficient for a small wiki. Embeddings can be added when the repository becomes too large for direct file selection.

Human review controls changes to company policy and architecture. Assign reviewers and response times before depending on the wiki in production. Unreviewed changes will accumulate when ownership is unclear.

The [company brain article](/blog/company-brain) describes systems that cover more data sources and interfaces.

## Maintenance controls

Assign an owner to each topic. Record the date of the last review in the file. Use automated checks for broken links, missing index entries and files that have exceeded their review interval. Require each proposed update to identify the code, ticket or policy that supports the change.

Keep previous versions in git. Reviewers can then compare the new statement with the earlier one and identify when it changed. Restrict write access to the repository and use the normal approval rules for production documentation.

## Limitations for changing facts

Markdown documents do not contain a standard validity model. This creates several problems for activity data.

- Older and newer pages may contain different values for the same fact.
- Search may rank an outdated page before the current page.
- Deleting an old value removes historical information.
- Keeping every value requires the reader to resolve conflicts.

These problems apply to owners, budgets, deadlines, decisions and customer state. Reliable current-state queries require validity dates and supersession records.

## Combining a wiki with memory infrastructure

Use the LLM wiki for conventions, architecture, runbooks and reviewed decisions. Store these files in git and load them at the start of relevant tasks.

Use a memory system for activity records and facts that change. Query it during the task. Require dates and sources in the response.

past.dev provides the second function. `POST /api/v1/ingest` accepts raw text with its original timestamp. The service resolves entities, extracts facts and stores validity periods. `POST /api/v1/recall` returns ranked, dated evidence with a `status` value such as `Supported`, `Conflicted` or `NoKnownSupport`.

See the [quickstart](/docs/memory-api/quickstart) for the API calls. [What is agent memory?](/what-is-agent-memory) covers the broader category. The [benchmarks page](/benchmarks) documents how recall is measured.