Build an LLM wiki that an agent writes, an agent reads, and that gets better every time you use it. Three exercises, each a complete working system, each adding exactly one idea to the previous one: the vanilla mechanic, ingestion at scale, and interactivity that learns from every query.
5-minute Quickstart:
git clone https://github.com/decodingai-magazine/llm-wiki-workshop.git cd llm-wiki-workshop/01-llm-wiki-vanilla claude # or your harnessThen type one prompt and watch a wiki appear:
/01-llm-wiki-vanilla ingest ../data_input_examples/notes/01-easy/
📑 The presentation is available here ↓
🎬 Full workshop available on YouTube ↓
Three ways in. Pick the one that fits the time you have — or do all three in order, since each builds on the last:
- Read a finished wiki. ~15 min, nothing to install. Open a committed
reference run —
01-llm-wiki-vanilla/examples/wiki-01-ai-engineering/is the smallest — ideally as an Obsidian vault. You'll see the two halves (raw/vswiki/), every claim carrying its citation, and what the ≥2 threshold chose to write, before running anything yourself. - Run one exercise's demo. ~30 min. Install the
prerequisites,
cd 01-llm-wiki-vanilla, open your harness, and type the prompts indemo.md. Every prompt comes with one thing to verify. - Work through all three exercises. ~2–3 h. Exercises 01 and 02 start from
nothing; exercise 03 starts from a committed copy of exercise 02's end state. Read
each exercise's
CHANGES-FROM-PREVIOUS.mdfirst to see exactly which files the new idea touched — that diff is the lesson.
A directory of markdown files with two halves that never mix:
raw/— immutable copies of what you ingested. What was said.wiki/— pages an LLM wrote from those copies. What you know.
Every page carries YAML frontmatter, every claim carries a [[wikilink]] to what
backs it, and one rule governs what exists at all:
A concept gets a page when ≥2 distinct sources engage with it.
One note mentioning something is a fact about the note. Two notes mentioning it is a fact about your knowledge. That single threshold is what stops the wiki filling with stubs.
Navigation works via progressive disclosure through a hierarchy of indexes:
Visualized in Obsidian:
 |
 |
The master index.md — one hop to every section |
concepts/index.md — one hop to every concept page |
Growing from 14 sources to 135:
 |
 |
| Exercise 02's reference run — 14 sources, 17 nodes | The same system after months on a real corpus — 135 sources, 120 nodes |
What a page actually looks like — a real concept page from `02-llm-wiki-ingest` (click to expand)
Full page at wiki/concepts/agent-memory.md:
---
type: concept
title: Agent Memory
description: The persistent layer that lets an agent reuse context across a
session or across interactions — framed across sources either as a queryable
knowledge graph reached through MCP tools, or as flat markdown files loaded
wholesale into the system prompt at session start.
sources:
- "[[wiki/sources/agentic-graphrag-via-mcp-servers]]"
- "[[wiki/sources/article-building-a-coding-agent-from-scratch-system-design]]"
- "[[wiki/sources/article-context-engineering-for-coding-agents]]"
- "[[wiki/sources/article-the-coding-agent-loop]]"
- "[[wiki/sources/mongodb-for-an-ai-agent-unified-memory]]"
- "[[wiki/sources/the-right-way-of-building-agents-with-mcp-servers]]"
- "[[wiki/repos/github-decodingai-magazine-building-a-coding-agent-from-scratch-course/ARCHITECTURE]]"
related:
- "[[wiki/concepts/graphrag]]"
- "[[wiki/concepts/mcp]]"
- "[[wiki/concepts/agent-harness]]"
created: 2026-08-31T17:23:45Z
timestamp: 2026-08-31T20:15:00Z
source_count: 7
---
# Agent Memory
> Multiple framings — see Definition
## Key claims
- A knowledge graph — typed nodes and edges extracted from ingested documents
— is the recurring representation across the three MCP-based sources […]
[[wiki/sources/agentic-graphrag-via-mcp-servers]], [[wiki/sources/the-right-way-of-building-agents-with-mcp-servers]]
- Decode's memory is prompt-embedded, not tool-mediated: assembled once at
session start, with `.decode/MEMORY.md` periodically rewritten in place […]
[[wiki/sources/article-context-engineering-for-coding-agents]]
## Tensions
Two incompatible architectures share the name "agent memory" here. […] Neither
cluster reconciles the two — likely a scale question (personal knowledge base
vs. single coding session) that no source states directly.
[[wiki/repos/github-decodingai-magazine-building-a-coding-agent-from-scratch-course/ARCHITECTURE]]
lands squarely on the file-based side and hardens it […]
> Synthesis: Six of seven sources trace to one practitioner […] so their
> agreement still reads as one voice across time, not independent
> confirmation. [[wiki/sources/mongodb-for-an-ai-agent-unified-memory]]
> remains the sole architecturally independent, vendor-framed source […]
... # Other detailsEach exercise builds on the previous one. You can do them independently as well.
| Exercise | Adds | The idea it teaches | Read the diff |
|---|---|---|---|
| 01 · vanilla | the whole mechanic, inline | Identity is the raw path; the ≥2 threshold decides what exists; the index is a cache. Hard cap: 10 notes per run. | — |
| 02 · ingest | subagents + adapters | Fan-out is context engineering: each raw file is read once, by one agent, and the orchestrator only ever sees receipts. Anything with a URI becomes a source. | CHANGES |
| 03 · interactive | questions, notes, repo answers | The wiki learns from being used — and the interesting design work is deciding what not to count as evidence. | CHANGES |
Join 44k+ engineers reading the Decoding AI Magazine and watching the Decoding AI YouTube channel to learn to design LLM wikis and advanced agent-memory techniques.
| Skills | Comfortable in a terminal. No coding required — you only type prompts. |
| Level | Anyone who has used an AI coding assistant. |
| Time | ~30 min per exercise, ~2–3 h for all three. |
| Cost | $0 beyond your harness's LLM usage. |
| Requirement | Check | Install |
|---|---|---|
| An agent harness (Claude Code is the reference) | claude --version |
claude.com/claude-code |
| Python ≥3.12 | python3 --version |
uv python install 3.12 or python.org |
uv |
uv --version |
curl -LsSf https://astral.sh/uv/install.sh | sh (docs) |
git + curl |
git --version, curl --version |
pre-installed on macOS/Linux |
| Obsidian (optional) | Visualize the examples | obsidian.md |
Verify the setup — from the repo root, run one of the workshop's scripts against a committed reference run:
uv run --script 01-llm-wiki-vanilla/.agents/skills/01-llm-wiki-vanilla/scripts/count_mentions.py \
--wiki-dir 01-llm-wiki-vanilla/examples/wiki-01-ai-engineeringIt should print a mention table with 12 candidate entities/concepts, of which only 9 pass the ≥2 threshold — if you see that, your setup works.
Each exercise is a self-contained project with its own skill. Start in one, open your
harness there, and work through its demo.md:
cd 01-llm-wiki-vanilla
claude # or your harness
/01-llm-wiki-vanilla ingest ../data_input_examples/notes/01-easy/data_input_examples/ holds a few notes, a GitHub repo URL and Substack article URLs as examples:
| Input | What |
|---|---|
notes/01-easy/ |
5 notes — one tight cluster (MCP vs. skills vs. CLIs) |
notes/02-medium/ |
10 notes — context layer, memory, GraphRAG, harness |
notes/03-hard/ |
all 50 notes, including tiny and noisy personal ones |
github_repositories.md |
one repo URL |
substack_articles.md |
four article URLs |
The tiers are nested (5 ⊂ 10 ⊂ 50) and a note's identity is its filename.
Goal: see the whole mechanic with zero moving parts. One skill, two scripts, no subagents, no web.
Ingest. The orchestrator does everything itself: copies one local note into raw, and then updates the wiki.
Query is read-only: index.md → a concept page → maybe a source page, and
raw/ only if a page genuinely fails.
Run it — 01-llm-wiki-vanilla/demo.md:
/01-llm-wiki-vanilla ingest ../data_input_examples/notes/01-easy/
/01-llm-wiki-vanilla what do my notes say about when to use an MCP server vs. a CLI?
Goal: remove the ceiling, and let anything with a URI become a source.
Ingest changes who reads. Every page is written by a subagent defined as plain
markdown in agents/: source_writer reads one raw file.
This exercise also adds support for GitHub repositories and web articles, and can easily be extended to other sources such as YouTube videos or Reddit threads.
Run it — 02-llm-wiki-ingest/demo.md:
/02-llm-wiki-ingest ingest ../data_input_examples/notes/02-medium/
/02-llm-wiki-ingest ingest https://github.com/decodingai-magazine/building-a-coding-agent-from-scratch-course
/02-llm-wiki-ingest ingest https://www.decodingai.com/p/building-a-coding-agent-from-scratch-system-design https://www.decodingai.com/p/the-coding-agent-loop
Goal: make interaction a second way for the graph to grow.
Capture user or agent interaction within the wiki (questions/, notes/,
open-questions.md) so the knowledge base grows organically as users interact with it.
We track all questions, create new notes as compositions of multiple concepts or entities, and keep track of open questions. On top of the default notes, the wiki also grows notes based on repositories.
Run it — 03-llm-wiki-interactive/demo.md:
cp -r examples/wiki-03-ai-engineering-before wiki-ai-engineering/03-llm-wiki-interactive when should I use an append-only log instead of updating rows in place?
/03-llm-wiki-interactive how do I decide that a fact in the memory has gone stale?
/03-llm-wiki-interactive in the coding agent repo, how does a tool call actually get routed to the permission gate, and what happens while it waits for the human?
Join 44k+ engineers reading the Decoding AI Magazine and watching the Decoding AI YouTube channel to learn to design LLM wikis and advanced agent-memory techniques.
| Resource | What it is |
|---|---|
| Introducing the Open Knowledge Format | Google Cloud's introduction to OKF and why a shared shape for knowledge bundles matters. |
| Open Knowledge Format (OKF) spec | The spec the wiki/ bundle aligns with: markdown + frontmatter, path is identity, the index is a rebuildable cache. CONVENTIONS.md §10 lists what we honour and where we diverge. |
Andrej Karpathy's llm-wiki gist |
The idea file this pattern traces back to: an LLM that incrementally builds and maintains a persistent wiki, instead of re-deriving answers from raw documents on every query. |
| Turn 10,994 Notes Into Memory · video | The Decoding AI lesson behind this workshop — an LLM wiki as agent memory, run against a real 10,994-note corpus. |
| Engineering Your Own AI Assistant - Paul Iusztin | Podcast between Paul Iusztin and Alexey Grigorev. |
| LangChain's OpenWiki | A CLI that writes and maintains agent documentation for your codebase — the same pattern, pointed at code. |
For any questions or issues, open a GitHub issue.
Do I need Claude Code?
No. Any harness that can load a skill, read and write files, and run shell
commands works — nothing pins a model or a tool name. Exercises 02–03 also want
subagents; without them, run the agents/*.md files as sequential prompts.
Can I point it at my own notes?
Yes — that is the point. Pass any directory of markdown to an ingest prompt, and
swap the URLs in data_input_examples/*.md for your own articles and repos. The
fixture exists only so every reader can reproduce the same wiki.
Is Obsidian required? No — it is the inspection tool, not a dependency. Everything is plain markdown; Obsidian's graph view just makes the threshold visible (hollow nodes are ideas waiting for a second source).
Paul Iusztin |
Senior AI Engineer, Educator & Founder of Decoding AI. Author of the best-selling LLM Engineer's Handbook. |
If this workshop was useful, consider starring the repository so others can find it too.
MIT — see LICENSE.
Built by Decoding AI.