This blog post was written specially for DOU.

Probably everyone who works with LLMs has encountered classic RAG (Retrieval-Augmented Generation). You upload a bunch of PDF files or connect a folder of documents, ask a question, and the model searches for relevant text chunks and generates an answer. This is convenient, but it has a fundamental flaw: the model reinvents the wheel every single time. It doesn't accumulate knowledge. If you ask it to compare facts from five different documents, it will search for and piece those fragments together over and over again, without creating any lasting structure.

Recently, Andrej Karpathy, a well-known AI researcher and co-founder of OpenAI, proposed an alternative approach — LLM Wiki. Instead of putting together an answer "on the fly" each time, an LLM agent takes on the role of an archivist and editor. It gradually processes your incoming materials and compiles them into a single, structured, cross-referenced knowledge base of Markdown files.

In this post, I would like to break down the concept of LLM Wiki in detail and look at its concrete practical implementation, adapting similar approaches for the Ukrainian language.

What is the Core Concept of LLM Wiki?

Karpathy proposed a simple metaphor:

  • LLM agent (e.g., Claude Code, Antigravity, or any other CLI agent) is the programmer.
  • Knowledge Base (Wiki) is the codebase.
  • Obsidian (or another Markdown editor) is the IDE where you visually review results, follow links, and look at the interactive connection graph.

Instead of simply storing texts in a vector database, LLM Wiki compiles them. When you add a new source (an article, a note, a podcast transcript):

  1. The agent carefully examines the material.
  2. Creates concept pages (concepts/) and entity pages (entities/) or integrates new facts into already existing pages.
  3. Updates the index of the knowledge base.
  4. Adds cross-references between pages.
  5. Resolves or notes contradictions if the new source refutes or complements old data.

Knowledge accumulates (compounds). When you write a query, the model does not reread gigabytes of raw data — it turns to the already structured and updated knowledge base.

Architecture of the Ukrainian Implementation

The Ukrainian version of the LLM-Wiki project has the following structure:

.
├── AGENTS.md          # System instructions for the AI agent (Schema)
├── .agents/skills/    # Scripts and automated skills (ingest, query, linter)
├── inbox/             # Folder for new raw materials and images
├── raw/               # Immutable archive of primary sources (grouped by YYYY-MM-DD)
└── wiki/              # Persistent knowledge base (Ukrainian language only)
    ├── concepts/      # Concept pages (theories, technologies, terms)
    ├── entities/      # Entity pages (people, companies, tools)
    ├── archives/      # Archive of complex analytical query responses
    ├── index.md       # Content catalog of all wiki pages
    └── log.md         # Activity log and completed operations

Why Markdown and Git?

  • Compatibility: Markdown is a universal format that can be opened by anything.
  • No vendor lock-in: You are not tied to a specific cloud service or proprietary database.
  • Git: The knowledge base is a regular Git repository. You get version history, branching capabilities, and convenient sync between devices for free.

Main Workflows

In the Ukrainian implementation, the agent's behavior logic is automated via skills in the .agents/skills/ folder.

Isolating individual skills is an important architectural decision that allows us not to keep the entire work context in the agent's "head" (context window). When you only need to search or analyze information, the agent uses the query skill and works exclusively in read-only mode, without loading import instructions. Conversely, during bulk document import, the ingest skill is activated, and the agent doesn't have to keep search or linting rules in memory. This significantly saves the model's context and increases the accuracy of actions.

1. Source Ingestion (Ingest Workflow)

You drop a raw text file (e.g., a copied article or notes) into inbox/, and media files into inbox/assets/. After that, you tell the agent: "Process the new materials".

During ingestion, an important approach is implemented — using isolated subagents (a separate agent for each file). When there are several files to import, the main agent does not process them himself within a single long conversation. Instead, it sequentially creates subagents, delegating the processing of exactly one file to each. This prevents cluttering and overflowing the main agent's context with tons of raw information and guarantees high-quality structuring of each source.

The worker agent does the following:

  • Moves raw sources to raw/YYYY-MM-DD/ adding YAML metadata (ingestion date, original source).
  • Analyzes content. If a new concept (e.g., "Quantum Computing") or entity ("John Doe") is mentioned, it creates the corresponding files quantum-computing.md or john-doe.md in the wiki/ directory.
  • If the concept already exists, it updates it, integrating new facts and referencing the new source in the sources: section of the YAML metadata.
  • Updates wiki/index.md and writes execution progress into the chronological log wiki/log.md.

2. Queries and Compounding Answers (Query Workflow)

When you ask the agent something complex (e.g., "Compare approaches to quantum decoding based on the last three articles"), it searches the wiki, formulates an answer, and saves it in wiki/archives/ as a new page. By doing so, your intellectual efforts and the model's conclusions do not disappear in the chat history but become part of the knowledge base.

3. Linting and System Health (Lint Workflow)

Over time, broken links, orphan pages, or logical contradictions appear in any wiki. The linter skill allows the agent to regularly scan the database, auto-fix technical errors (e.g., updating index or links), and flag contradictory statements for your attention.

Peculiarities of Ukrainian Language Adaptation

Localizing such a project is more than just translating a configuration file. Several linguistic nuances were resolved:

  1. English for filenames (kebab-case): To ensure maximum compatibility with Git, Obsidian, and console utilities, filenames are created in Latin characters using kebab-case as a translation of the corresponding concept (e.g., artificial-intelligence.md or quantum-computing.md), while the H1 heading and all content inside the file are kept exclusively in Ukrainian. This avoids encoding issues with Cyrillic characters in filesystem paths and simplifies linking.
  2. Bypassing the limitations of Ukrainian morphology (semantic search): Unlike traditional search engines, where the declension of Ukrainian words (e.g., *'квантовий'*, *'квантових'*, *'квантовому'*) requires complex lemmatization or stemming algorithms, an LLM operates on semantics. It easily finds relationships between concepts regardless of the grammatical case or word form, and also automatically translates foreign terms during import, keeping the original English equivalents in parentheses for accuracy.
  3. Localized templates: All templates (templates/) are translated into Ukrainian and support a single metadata format.

Practical Use Cases

Example 1: Personal "Second Brain" (Personal Knowledge Management)

You keep journals, save notes from books read, links to interesting reports, and recipes.

  • How it works: You simply drop messy notes into inbox/. The LLM sorts them. For instance, your note about a workout will update the cardio.md concept, create the coaching-app.md entity, link them, and update your personal goals. You get a structured picture of your life without the manual sorting routine.

Example 2: Professional Research (Research Deep-dive)

You are studying a new complex technology, such as WebAssembly or CRDT.

  • How it works: You configure the Obsidian Web Clipper browser extension, saving interesting articles and research papers directly to inbox/. The agent parses them, creates pages for different algorithms (e.g., y-js.md, automerge.md), highlights the pros and cons of each approach, compiles benchmarks, and forms a general conceptual map.

Example 3: Interactive Companion for Reading Books or Exploring Lore-rich Universes

Reading complex novels or studying the history of fictional worlds (like "The Lord of the Rings" or "A Song of Ice and Fire") can be difficult due to hundreds of characters and geographical names.

  • How it works: After reading each chapter, you dictate or write a short summary in a file in inbox/. The LLM creates and updates character profiles in entities/ (their status, family ties, motivation) and locations in concepts/, building a massive interactive connection graph. You get your own interactive encyclopedia of the book.

Example 4: IT Team or Startup Knowledge Base

Keeping internal documentation up-to-date is a perpetual pain for teams. Confluence often turns into a graveyard of outdated information.

  • How it works: You can set up imports from Slack channels, meeting transcripts, and Jira task descriptions into the project's inbox/. The LLM agent analyzes the new information and automatically updates project pages, records changes in architectural decisions, or tracks responsible persons in entities. The team always has an up-to-date knowledge base without spending time on manual updates.

Multi-project workflow

The project is designed so that it can be used simultaneously and completely independently for different tasks. Since the entire knowledge base is just an isolated folder with Markdown files and local agent configurations:

  • You can easily clone this repository into separate folders for each of your tasks (e.g., one clone for a work project, one for learning a programming language, and another for personal training).
  • You start working with each project locally.
  • If some work "doesn't take off" or loses relevance, you simply delete the folder with no consequences.
  • Conversely, if a project goes great, you initialize Git, set up a private repository on GitHub, and start tracking your progress with commits.

Quality Control and Scaling

To make working with LLM Wiki as reliable and scalable as possible, time-tested engineering approaches are used:

  1. Git as a Control Mechanism (Human-in-the-loop): You don't have to blindly trust the model and its generations. Since the entire knowledge base is a Git repository, after each import or edit operation you can run git diff in the console or your favorite IDE. This allows you to visually inspect all added facts, corrected links, or edited concepts before committing the changes. If the model hallucinates or breaks layout, you simply roll back the changes.
  2. Scaling via Ripgrep and Local Search: If your wiki grows to thousands of pages, passing the entire index.md index to the model's context during each query becomes inefficient and expensive. For such scales, the agent can use the console utility ripgrep (rg) or a local search system based on the MCP protocol (such as qmd). This allows the model to quickly and precisely find the necessary files through fast text or vector search on your machine, without loading unnecessary information into context.

Why This Approach Really Works

Any note-taking system (from notebooks to Notion) usually dies due to the so-called "bookkeeping tax". A person quickly gets tired of adding tags, verifying links, updating the table of contents, and keeping track of outdated pages.

LLM Wiki solves this problem cardinally: the human only consumes information and provides new sources, while all the bureaucratic work of maintaining the structure is done by the AI.

Crucially, you define the rules of the game together with the model in the AGENTS.md (Schema) file. This is a "live" configuration document: if you notice the model making a systematic error, grouping or tagging information incorrectly, you write one or two sentences with new rules there. Next time, the agent will take your corrections into account, gradually adapting to the peculiarities of your thinking and knowledge domain.

If you want to try building your own persistent brain managed by artificial intelligence, clone the repository, set up your agent, and start experimenting!

Project on GitHub: BogdanovychA/llm-wiki