The LLM Wiki Pattern: Obsidian as Permanent Structured Memory for AI Agents

How to Use This Obsidian LLM Wiki

A practical guide to working with this vault — from daily operations to extending the system.

Table of Contents

1. What You Have
2. Daily Workflow
3. Ingesting a New Source
4. Querying the Wiki
5. Running a Health Check (Lint)
6. The Wiki as Permanent Memory for AI Agents
7. Working with AI Agents: Collaborative Workflow
8. How to Extend the Wiki
9. Troubleshooting & Pitfalls

1. What You Have

WGA_main/                        ← This vault
├── SCHEMA.md                    ← Rules, tags, conventions (read this first!)
├── index.md                     ← Every page cataloged with one-line summary
├── log.md                       ← Chronological action log (append-only)
│
├── raw/                         ← Layer 1: Immutable sources
│   ├── articles/                ← Web articles, blog posts
│   ├── papers/                  ← PDFs, arxiv papers (TBD)
│   ├── transcripts/             ← Podcasts, interviews (TBD)
│   └── assets/                  ← Images, diagrams (TBD)
│
├── entities/                    ← Layer 2: People, orgs, tools
├── concepts/                    ← Layer 2: Topics, ideas, techniques
├── comparisons/                 ← Layer 2: Side-by-side analyses
├── queries/                     ← Layer 2: Filed Q&A worth keeping
│
├── blog/                        ← Symlinked Hugo site (165 posts)
├── health-and-longevity/        ← Your original Obsidian notes
├── business-and-marketing/
├── linux/
├── ux-design/
├── computer-science/
├── psychedelics/
├── concepts/                    ← (wiki-owned, in same dir)
│   ├── intro_to_LLM_Wiki.md
│   ├── hermes-agent.md
│   └── 🔗 howto_use_this_Obsidian_LLM_wiki.md  ← You are here
├── entities/                    ← (wiki-owned, in same dir)
├── _archive/                    ← Superseded notes

Key principle: The vault has two layers of content:

The wiki pages exist to synthesize and cross-reference your original notes. They don’t replace them.

2. Daily Workflow

Every time you open the vault

1. Glance at log.md — see what changed since you last opened it
2. Check index.md for new pages you might not know about
3. Open Graph View (Ctrl+O → graph: or the Graph tab) — see how new pages connect

When you learn something

• Quick capture → drop a link or note in a raw source file
• Full ingest → ask your AI agent to process it (see Ingesting a New Source)
• Just a spark → add a [[wikilink]] placeholder on an existing page. If you write [[my-new-idea]] on a page, that creates an unresolved link that the agent can flesh out later

When you want to find something

• Search first in index.md — it lists every wiki page with a one-liner. Much faster than full-text search.
• Follow [[wikilinks]] — pages are connected; if one page is relevant, click its links
• Use Dataview queries (if you have the Dataview plugin):

TABLE confidence, created FROM "entities" WHERE contains(tags, "person")

LIST FROM "concepts" WHERE confidence = "low"

3. Ingesting a New Source

You found something worth keeping — an article, a paper, a podcast transcript. Here’s the full workflow:

3.1. Save the raw source

raw/
├── articles/       ← Blog posts, web pages
├── papers/         ← Academic papers, PDFs
├── transcripts/    ← Podcast/video transcripts
└── assets/         ← Images, diagrams

Create a file with this frontmatter:

---
source_url: https://example.com/article
ingested: 2026-05-10
sha256: <hex digest of content below frontmatter>
---

The raw file body is the full source content. Do not modify it after saving — it’s immutable. If you re-ingest an updated version, save it as a new file with the new date and hash.

3.2. Identify what it touches

Ask yourself (or your agent):

• Entity pages — who is involved? What tools/companies/products appear?
• Concept pages — what ideas does it explain or challenge?
• Comparison pages — does it compare X vs Y?
• Existing vault notes — what existing files in health-and-longevity/, linux/, blog/ are relevant?

One source typically touches 2–5 wiki pages.

3.3. Write or update pages

New page — create a markdown file with frontmatter:

---
title: Page Title
created: 2026-05-10
updated: 2026-05-10
type: entity | concept | comparison | query
tags: [from SCHEMA.md taxonomy]
sources: [raw/articles/filename.md, health-and-longevity/existing-note.md]
confidence: low | medium | high
contested: true          # only if contradictory
contradictions: [other-page-slug]  # only if contradictory
---

Update an existing page — bump updated:, add new info, add new [[wikilinks]]. If the source contradicts existing content, see Contradictions.

Rules to follow:

• At least 2 outbound [[wikilinks]] per page (or it’s an orphan-in-waiting)
• Tags must already exist in SCHEMA.md’s taxonomy — if not, add there first
• For pages with 3+ sources, add paragraph-level provenance: ^[raw/articles/source.md]

3.4. Update navigation

After every change:

1. Add/update the entry in index.md under the correct section with a one-line summary
2. Append to log.md — format: ## [YYYY-MM-DD] action | subject

## [2026-05-10] ingest | Article: "Title of Article"
- Saved raw source to raw/articles/title-of-article.md
- Created entities/person-name.md
- Updated concepts/existing-concept.md with new findings
- Updated index.md, log.md

3.5. Real example

You find: A Huberman podcast transcript on creatine supplementation.

1. Save → raw/transcripts/huberman-creatine-2026.md
2. Update → entities/andrew-huberman.md (bump confidence, add this source)
3. Update → concepts/creatine.md (add cognitive benefits section, link to source)
4. Link → add [[creatine]] to entities/andrew-huberman.md
5. Index → add concepts/creatine.md to index if new, update summary if existing
6. Log → append entry

Result: one source strengthened 3 pages and created a new cross-link.

4. Querying the Wiki

This is where the pattern shines over RAG. When you want to know something:

4.1. Self-service (manual)

1. Open index.md
2. Find the relevant pages by reading the one-line summaries
3. Open them, follow their [[wikilinks]]
4. Synthesize the answer yourself

4.2. Agent-assisted

Ask your AI agent a question. The agent:

1. Reads index.md to find relevant pages
2. Reads those pages (and follows their links)
3. Synthesizes an answer with citations
4. If the answer is substantive, files it as a new page in queries/

Example: “How does creatine affect cognitive decline?”

The agent reads:

• concepts/creatine.md — existing synthesized knowledge
• entities/andrew-huberman.md — source context
• concepts/cognitive-decline.md — related concept

It produces an answer drawing from all three, then saves it as queries/creatine-cognitive-decline-2026.md for future reuse.

4.3. When to file a query vs. write a comparison

Rule of thumb: if you’d ask the same question again in 3 months, file it. Otherwise, don’t bother.

5. Running a Health Check (Lint)

Over time, the wiki decays. Pages get stale, links break, orphans accumulate. Run a lint periodically (every 1–2 months or after a big ingest session).

Checklist:

You can automate this by asking your agent: “Run a lint on the wiki.”

Quick lint commands (Obsidian search)

path:entities/ -path:_archive/   → list all entity pages
path:concepts/ -path:_archive/   → list all concept pages
[[   → all wikilinks (check for broken ones)

In Obsidian, broken wikilinks appear in the Graph View as unlinked nodes (grey, no connections). You can also use the Unlinked mentions pane or plugins like Note Linker.

6. The Wiki as Permanent Memory for AI Agents

This is the most important concept to understand about the LLM Wiki pattern — and the reason it exists.

6.1. The problem: agents have no long-term memory

Every AI agent conversation starts from scratch. Even agents that claim “memory” are really just:

• Compressing past conversations into summaries (lossy)
• Re-reading previous transcripts (burns context window)
• Using a vector database (RAG — re-derives answers every time)

None of these compound knowledge. Ask the same question to a fresh agent session and it re-derives the answer from scratch, possibly contradicting what it said last time.

6.2. The solution: externalized, structured, permanent memory

This wiki is not stored in the agent’s brain. It’s stored in files that the agent reads and writes. This gives you:

6.3. The compounding effect

Session 1: You share a Huberman podcast on creatine. The agent writes concepts/creatine.md from scratch — definition, mechanism, dosage, references.

Session 2 (next week): You share a study on creatine and cognition. The agent:

1. Reads concepts/creatine.md (already written)
2. Reads index.md — finds concepts/cognitive-decline.md exists
3. Updates concepts/creatine.md — adds a “Cognitive Benefits” section, links to [[cognitive-decline]]
4. Updates concepts/cognitive-decline.md — adds creatine as a potential intervention
5. Bumps confidence on both pages from low to medium

Session 3 (next month): You ask “What supplements help cognition?” The agent reads both pages (already synthesized from 2+ sources each) and answers with confidence levels and provenance. It didn’t re-read the raw podcast transcript or the study PDF. It read the curated pages.

This is the core loop: sources come in once → knowledge compounds forever. Every agent session starts smarter than the last one.

6.4. Why this beats RAG

RAG (Retrieval-Augmented Generation) works like this:

Question → Search vector DB → Find 5 raw documents → Agent reads them → Answers from scratch

LLM Wiki works like this:

Question → Read index.md → Read 2 curated pages → Agent answers from synthesized knowledge

6.5. What the wiki remembers (and what it doesn’t)

The wiki remembers:

• Facts about people, topics, tools (entity & concept pages)
• Comparisons and analyses you found worth keeping
• Answers to questions you filed
• What sources you’ve seen and where they came from
• Confidence levels and contradictions

The wiki does NOT remember:

• Your personal preferences (agent’s memory system handles that)
• In-progress work (use the agent’s session history for that)
• Your vault structure changes (log.md tracks those)
• Raw source content beyond the immutable copy (it’s there but the agent doesn’t re-read it unless needed)

6.6. Cross-agent memory: one wiki, many agents

You run Hermes Agent on your VPS (Telegram bot) and Claude Code locally. They share this wiki. The memory is in the files, not in any one agent’s brain:

1. Hermes ingests an article → writes to concepts/, entities/, index.md, log.md
2. You switch to Claude Code, ask a question about that topic
3. Claude reads index.md → finds the page → reads it → answers
4. Claude has never seen the raw article, but it benefits from Hermes’ synthesis

This works with any number of agents, any mix of providers. The wiki is the single source of truth. Each agent contributes to it, all agents read from it.

7. Working with AI Agents: Collaborative Workflow

This section covers the concrete mechanics of how you and your agents work together on the wiki.

7.1. The division of labor

YOU (the human)                          AI AGENT
──────────────                           ───────────────
• Decide what's worth keeping           • Download/save raw sources
• Set the schema and conventions         • Write and update wiki pages
• Resolve contradictions                • Add [[wikilinks]] between pages
• Review and approve agent's work       • Update index.md and log.md
• Run lint to check health              • Answer queries from the wiki
• Define new tags and page types        • Generate Dataview queries
• Ingest high-level direction            • Execute the mechanics

You direct, the agent executes. You’re the curator; the agent is the scribe and synthesizer.

7.2. The full collaborative loop

1. DISCOVERY
   You: "Read this article on NMN and send me a summary."
   Agent: Reads it, summarizes, asks clarifying questions.
   You: "Yes, add it to the wiki."

2. INGEST
   Agent:
   - Saves raw source to raw/articles/nmn-2026.md
   - Reads index.md and existing pages
   - Updates or creates wiki pages
   - Updates index.md and log.md

3. REVIEW
   You: Check pages, fix any errors.
   You: "The dosage was 500mg not 250mg, fix it."
   Agent: Corrects, bumps updated date, logs the correction.

4. COMPOUND
   Later, you: "What NAD+ precursors have evidence?"
   Agent: Reads index.md → concepts/ → finds NMN and NR pages
         → synthesizes answer with confidence levels and sources
         → optionally files answer in queries/

5. LINT (periodic)
   You: "Run a lint on the wiki."
   Agent: Checks orphans, broken links, stale pages, etc.
   You: Review findings, decide what to archive or update.

7.3. Setting up a new agent to use this wiki

Step 1: Give the agent access to the vault path.

# For Claude Code:
claude --allowed-dir /home/wga/Documents/obsidian/WGA_main/

# For Hermes Agent:
# Config at ~/.hermes/config.yaml — ensure file tool has access to this path

# For Gemini CLI:
gemini --allowed-dir /home/wga/Documents/obsidian/WGA_main/

Step 2: Point the agent to SCHEMA.md as ground truth.

Before working with the wiki, read /home/wga/Documents/obsidian/WGA_main/SCHEMA.md.
It defines the rules, tag taxonomy, and conventions. Follow it strictly.

Step 3: Create an agent skill/profile for wiki operations.

For Hermes Agent, save a skill at ~/.hermes/skills/llm-wiki-ingest.skill.md (see Section 8.2).

For Claude Code, save an instructions file and pass it with --instructions or via .claude.md in the vault root:

# .claude.md — LLM Wiki Instructions for Claude Code

This vault is an LLM Wiki. When the user asks to add, update, or query knowledge:

1. Read SCHEMA.md first for conventions
2. Read index.md to find existing pages
3. For ingest: save raw source, then update/create wiki pages
4. Every wiki page needs YAML frontmatter with title, dates, type, tags, sources, confidence
5. Add at least 2 [[wikilinks]] per page
6. Update index.md and log.md after every change
7. Tags must exist in SCHEMA.md's taxonomy

Step 4: First interaction.

You: "Read index.md and tell me what's in this wiki."
Agent: Lists all sections and pages.
You: "Now read SCHEMA.md so you know the conventions."
Agent: Confirms understanding.

Now the agent is onboarded. From here, it can ingest, query, and maintain the wiki.

7.4. Prompt patterns that work

7.5. Prompt patterns that DON’T work

7.6. Reviewing agent output: what to check

Agents get better with correction. After 3–5 ingests, the pattern becomes reliable.

7.7. Session management across agents

┌─────────────────────────────────────────────────┐
│              THE WIKI (permanent)                │
│  entities/ concepts/ comparisons/ queries/       │
│  index.md log.md SCHEMA.md raw/                 │
└──────────┬────────────────────┬──────────────────┘
           │                    │
    ┌──────▼──────┐      ┌─────▼──────┐
    │ Hermes Agent│      │Claude Code │
    │ (VPS, 24/7) │      │ (local)    │
    │ Telegram bot│      │            │
    └─────────────┘      └────────────┘
           │                    │
           │   (both read and   │
           └─── write same ─────┘
                wiki files

Rules for multi-agent operation:

1. No simultaneous writes — both agents writing at the same time can cause conflicts. Either use one agent at a time, or establish domains (e.g., Hermes handles ingest, Claude handles queries).
2. log.md is the source of truth — if you don’t know what changed, read log.md. It’s append-only and chronological.
3. Agent A doesn’t know what Agent B did until it reads the wiki again — if Hermes updated concepts/creatine.md and you then ask Claude about creatine, Claude will see the updated page because it reads the file fresh. But Claude won’t volunteer that there was a recent update unless you tell it or it checks log.md.
4. Onboarding takes one sentence — “Read index.md for the current state of the wiki.” Any new agent catches up instantly.

7.8. Off-boarding: what happens when you switch agents

Nothing. The wiki is just files. If you switch from Hermes to Claude to whatever comes next:

• All 190+ pages survive
• All wikilinks survive
• All confidence levels and contradictions survive
• The new agent reads index.md and SCHEMA.md and is instantly productive

Zero migration cost. This is the durability guarantee of the LLM Wiki pattern.

8. How to Extend the Wiki

Same as before - extension points covering new domains, agent skills, page types, custom frontmatter, Dataview, git backup, and meta section.

8.1. Adding a new domain

The wiki currently covers: health & longevity, business/marketing, Linux/tech, UX design, psychedelics, computer science.

To add a new domain (e.g., “photography”):

1. Update SCHEMA.md — add new tags under the taxonomy:

   - **Photography:** photography, camera, lens, lighting, composition, editing
   

2. Create a raw sub-directory if needed — e.g., raw/photos/ for camera test shots

3. Optionally create a top-level directory — e.g., photography/ for your original notes

4. Start ingesting — the new tags propagate to all new pages

8.2. Agent skills

If you use Hermes Agent, you can create a skill that teaches the agent the ingest workflow. This makes repeatable operations one-command.

Save a skill file at ~/.hermes/skills/llm-wiki-ingest.skill.md:

# LLM Wiki Ingest Skill

## When to use
When the user shares a URL, PDF, or text to add to their LLM wiki.

## Steps
1. Download/extract the source content
2. Save to `raw/articles/<slug>.md` (or raw/papers/, raw/transcripts/) with frontmatter:
   - source_url, ingested date, sha256 hash
3. Read `index.md` to find existing related pages
4. Read the related pages to understand current state
5. Create or update wiki pages:
   - entities/ for people, orgs, tools
   - concepts/ for topics, ideas
   - comparisons/ if the source compares things
6. Every new/updated page must:
   - Have YAML frontmatter (title, dates, type, tags, sources, confidence)
   - Have at least 2 [[wikilinks]]
   - Use tags from SCHEMA.md taxonomy
   - Bump `updated` date if updating existing
7. Add/update entries in index.md
8. Append to log.md

Load it with hermes --skills llm-wiki-ingest.

8.3. New page types

The four types (entities, concepts, comparisons, queries) cover most needs. If you need a new type:

1. Add it to SCHEMA.md’s allowed type: values in the frontmatter spec
2. Create the directory (e.g., guides/, projects/)
3. Add it to the three-layer diagram in concepts/intro_to_LLM_Wiki.md
4. Add a section in index.md for the new type

Examples of new types:

• projects/ — ongoing projects with status, milestones, notes
• protocols/ — step-by-step procedures (fasting protocol, supplement stack)
• guides/ — how-to guides that span multiple concepts
• timelines/ — chronological events around a topic

8.4. Custom frontmatter fields

The standard fields (title, created, updated, type, tags, sources, confidence, contested, contradictions) cover most cases. To add more:

1. Document them in SCHEMA.md under the frontmatter section
2. Add to all relevant pages

Useful extras:

• status: seedling | growing | evergreen — lifecycle stage of the page
• supersedes: [old-page-slug] — explicit deprecation chain
• tldr: "One-sentence summary" — for index auto-generation
• related: [page-slug, page-slug] — for pages that should be linked but aren’t yet
• projects: [project-name] — group pages by project

8.5. Automation with Dataview

The Obsidian Dataview plugin can turn your YAML frontmatter into queryable data. Install it and add queries to your pages:

TABLE confidence, created, file.outlinks AS "Links Out"
FROM "entities"
SORT confidence ASC

LIST rows.file.link
FROM "concepts"
GROUP BY tags

TABLE confidence, updated
FROM "concepts"
WHERE confidence = "low" AND updated < date(today) - dur(90 days)

You can pin these queries to a dashboard page, or embed them in index.md.

8.6. Git backup

The vault is just files — back it up however you want:

cd /home/wga/Documents/obsidian/WGA_main/
git init
git add .
git commit -m "Wiki snapshot $(date +%Y-%m-%d)"

Or use Obsidian Sync, Nextcloud, or any file-based sync.

Pro tip: Add a .gitignore for _archive/ if the archived notes are only of historical interest:

_archive/
.obsidian/workspace.json
.obsidian/graph.json

8.7. The meta section in index.md

As the wiki grows, index.md gets long. Consider adding a ## Meta section for utility pages like this one:

## Meta
- [[howto_use_this_Obsidian_LLM_wiki]] — Complete usage guide
- [[intro_to_LLM_Wiki]] — The LLM Wiki pattern explained
- [[SCHEMA]] — Rules, conventions, tag taxonomy
- [[log]] — Chronological action log

This anchors your infrastructure pages so they’re findable.

9. Troubleshooting & Pitfalls

“I can’t find what I’m looking for”

• Check index.md first — if it’s not there, it probably doesn’t exist yet
• If it’s a passing mention in a raw source, it might not have been promoted to a wiki page yet
• Search with Obsidian’s native search (Ctrl+Shift+F) for full-text across all files

“The agent created a page with broken wikilinks”

• Common early mistake. Fix the link target or remove the link
• Add a note to the agent: “Check that all [[wikilinks]] point to existing files before saving”
• Run the lint to catch these systematically

“The wiki is growing too fast / too many pages”

Apply stricter thresholds:

• Don’t create a page for single-source mentions unless the topic is central
• Use existing pages instead of creating new ones — append to an existing concept
• Archive aggressively — move superseded pages to _archive/
• The 200-line limit forces you to split, which naturally limits page count

“Tags are getting out of control”

• This is exactly what the tag taxonomy prevents. If you see a tag not in SCHEMA.md, either:
  • Add it to the taxonomy (it’s a real gap), or
  • Rename it to an existing tag (it was a duplicate)
• Lint will catch this automatically

“Conflicting information from different sources”

Follow the SCHEMA.md conflict policy:

1. Check dates — newer sources generally supersede
2. If genuinely contradictory, note both positions with sources and dates
3. Mark contested: true and contradictions: [other-page] in frontmatter
4. The contradiction is visible in the lint report for your review

“I want the agent to work with a different AI tool”

Any AI agent that can read/write markdown files works. The LLM Wiki pattern is tool-agnostic — it’s a file structure convention. You can even maintain it manually without an agent.

Quick Reference Card

Last reviewed: 2026-05-10 Related: [[intro_to_LLM_Wiki]], [[SCHEMA]]