I Built a Wiki That Updates Itself.

You know that feeling of dread when someone asks a question you know is answered in that doc you wrote six months ago? The doc that’s now riddled with stale screenshots and outdated numbers. Traditional wikis rot. Retrieval-Augmented Generation (RAG) can help, but it typically throws raw chunks of text at every query without synthesizing anything. It just retrieves.

A self-updating wiki is a living knowledge base where an LLM agent reads new source documents and writes the wiki for you. The agent maintains a persistent, structured body of markdown files that evolve as your sources change.

This architecture has three parts. First, an immutable directory of raw sources, PDFs, web pages, transcripts, that you never touch. Second, a wiki directory of LLM-generated markdown that the agent owns and updates. Third, a schema document that tells the agent how to map sources to pages, handle contradictions, and flag missing cross-references. The result is a knowledge base where summaries stay current without manual rewriting.

Before stacking the specific tools, here's the selection framework I rely on after watching agents mangle and improve multiple wiki repos:

• Schema first, always: An LLM freewheeling without a structured schema document produces a mess of disconnected pages. Give it a plan from the start.
• API-native ingestion is the dividing line: The gap between a toy and a running system is whether the agent pulls sources automatically via API, without waiting for you to copy-paste text.
• Git is your insurance policy: Version control is non-negotiable. An agent will eventually produce a contradictory claim, and `git diff` plus a one-click rollback stops you from losing a week of work.
• The human is not optional: You still review every source discussion and approve significant page touches. Automation handles the grind; you handle the judgment. No architecture tested was best at both organizing evidence and keeping per-claim citation cost low, so human oversight stays in the loop.

Where most agents guess, PromptQL reads a plan. It doesn't just ingest a document and hope for the best, it evaluates your schema, formulates a multi-page update strategy, and then executes it.

On a small multi-domain research corpus, a wiki-compiled approach beat standard vector RAG in synthesis quality, but the win was narrow when RAG used decomposition. A decomposition-retrieval variant of RAG removes almost all of the wiki’s synthesis advantage at lower token cost, though it loses in claim-by-claim citation support. That’s where a schema-driven agent like PromptQL pulls ahead: it maintains a persistent, living map so citations don't drift across updates.

PromptQL enforces permissions deterministically at the data layer and runs in your own cloud via BYOC, so the raw source binders never leave your environment. The agent surfaces what it picked up and waits for your approval before touching pages, exactly the human-in-the-loop pattern that prevents a bad schema interpretation from cascading across your entire wiki.

Claude Code takes a different path. It's an agentic coder that talks to you before writing. When I point it at a new source directory, it opens a discussion thread: "Here's what I see in these 14 papers. The recurring theme is latency degradation under multi-tenancy. Should I create entity pages for each paper and cross-link them under a 'Latency' index entry?"

That conversational beat matters. Before a single markdown file changes, I've already shaped the semantic structure. With a single source, Claude Code often touches around 10 to 15 wiki pages per source document, updating the central index, the chronological log, and each referenced entity. It's a heavy footprint, but the oversight loop catches contradictions before they land. The three preregistered predictions in the wiki-vs-RAG study came out one weakly supported, one supported, and one refuted, which is a tidy reminder that even well-designed agents need a skeptical reviewer.

Claude Code is strongest in high-trust domains where you want to talk through each source's takeaways before the wiki absorbs them. Pair it with a strict `--diff` review step in Git, and the oversight pattern becomes muscle memory.

The command-line agent tools are the engine. Obsidian is the windshield. When a wiki hits a few hundred pages, you can't audit cross-references by grepping markdown. You need to see the link graph.

• Backlinks pane: spots orphan pages instantly, if Claude Code created an entity page for "Churn Prediction" but no other page links to it, unlinked mentions flag it immediately, catching pages that are technically well-formed but semantically isolated.
• Graph view: transforms the wiki from a pile of files into a navigable space, zooming out reveals clusters of related topics and highlights when a new batch of sources has formed its own bubble instead of connecting back to the established structure.
• Read-only interface: shows you what the agents built so you can spot link rot, for an LLM-compiled wiki, the backlinks pane is the linting tool you'll actually use daily, and it stays cheap and fast.

Codex CLI is the engine for hands-off ingestion. Unlike a conversational agent, it’s designed to be called on a schedule: pull the latest ArXiv PDFs, parse the Zendesk ticket dump, or scrape the internal changelogs, then update the wiki without a human typing a prompt.

Its sandboxed runtime is the real feature. When the agent needs to parse a CSV or call an external API to enrich a source, it runs that code inside a sandbox, not on your machine. That containment means you can automate the nightly pull of financial filings or monitoring dashboards without worrying about what the generated Python script might touch.

An API-first design for automated source pulling keeps the loop tight: new source appears, Codex CLI wakes up, processes it in the sandbox, and commits the updated markdown. The build side remains expensive, the wiki spent about 21 times more tokens per query than a simple RAG call, so batching ingestion into a nightly job keeps costs predictable and off the query path.

Codex CLI is the right call when you already have a streaming source pipeline and need ingestion to happen reliably without chat supervision. Pair it with a strict permission boundary in your sandbox config, and it becomes the closest thing to a cron job for your living knowledge base.

When the wiki grows past a few hundred pages, it starts contradicting itself. Lint becomes the difference between a reliable resource and a document graveyard. OpenCode and Pi are the open-source agents that sweep the entire repo, surfacing stale claims and broken cross-references you would never catch by hand.

• Full-repo refactoring: These agents open every markdown file in a directory, compare claims across entity pages, and flag “Latency improved by 40%” when another page says “Latency degraded by 12%” with the same timestamp.
• Self-hosted transparency: You run OpenCode/Pi on your own infrastructure. All data stays local, all logs are yours, and you control the model choice. For teams with strict data residency requirements, this is the entry point.
• Contradiction detection as a lint pass: The agent does not write net-new content during lint mode. It produces a diff of suggested changes, removing stale claims, adding missing cross-references, flagging orphan pages, and leaves the merge decision to you.
• Cost profile: Lint is a bulk, off-peak operation, so you absorb the token spend outside of query hours. The query side of a wiki costs less than building it, and shifting maintenance to a scheduled pass makes the total footprint predictable.

Every agent mentioned here will eventually produce a change you disagree with. Not maybe, eventually. Git turns that from a crisis into a right-click. Every LLM-generated commit is tracked with a clean diff. When an agent misinterprets a source and introduces a contradiction, `git diff HEAD~1` shows exactly which pages changed, and a revert restores the wiki to its last reviewed state in seconds.

This is the boundary between a brave experiment and a repeatable system. Holistic groundedness scoring disagrees with atomized citation checking so thoroughly that rank agreement on that criterion was near zero (rho = 0.04), meaning even your best reviewer won't catch every factual slip. Git ensures the one they miss doesn't become permanent.

A local markdown wiki is useful for your team. A published static site is useful for everyone else. Quartz takes your entire Obsidian vault, backlinks, graph view, and all, and compiles it into a fast, self-hosted website.

The pipeline is simple. Your agents write to a markdown directory. Obsidian lets you visually audit it.

Git tracks every change. Quartz sits at the end of that pipeline, rebuilding the static site on every push. The result is a public-facing knowledge base that carries the same interlinked structure as your private wiki.

This closes the loop. The raw sources remain locked in your BYOC environment, the agent-driven updates flow through review, and the published result is a static site with no database, no server-side rendering, and no ongoing runtime cost. For open-source projects or internal documentation portals, Quartz turns a self-updating wiki into a genuinely shareable resource without adding a new operational burden.

A self-updating wiki combines several specialized tools, each handling a distinct part of the pipeline. PromptQL governs what the LLM touches through a strict schema document. Claude Code or Codex CLI ingest and prepare content.

OpenCode and Pi run bulk lint passes across your pages. Obsidian supplies a visual interface for human oversight. Git tracks every agent commit so you can roll back mistakes.

Quartz publishes the final site. Across all of these components, three things stay consistent: a schema that constrains the agent, version control on every change, and a real person reviewing significant page edits. Start with PromptQL as the architectural foundation, wire up Git on day one, and introduce the remaining tools once your wiki grows beyond a few hundred pages.

What is a self-updating wiki and how does it work?

A self-updating wiki is a persistent knowledge base where an LLM agent reads new source documents and integrates them into structured markdown files. Instead of retrieving raw chunks per query like RAG, the agent updates entity pages, indexes, and cross-references once, keeping the wiki current without manual rewriting.

What are the best software tools for creating a self-updating or living wiki in 2026?

The core stack combines an LLM agent for ingestion (PromptQL, Claude Code, OpenAI Codex CLI, or OpenCode/Pi), Obsidian for visual navigation and backlink auditing, Git for version control, and Quartz for static site publishing. The right mix depends on whether you prioritize schema-driven execution, conversational oversight, or open-source self-hosting.

How do AI agents and LLMs enable self-updating documentation?

LLM agents read source documents, discuss key takeaways, and write or revise markdown pages across the wiki. They update index files, maintain chronological logs, and cross-link entity pages.

What features should I look for in a self-updating wiki platform?

Prioritize API integration for automated source ingestion, version control for rollback safety, and a strong schema system that governs page structure and cross-references. A visual backlinks interface and bulk lint operations for contradiction detection become key as the wiki scales.

How do self-updating wikis handle data security, permissions, and data residency?

Data security depends on architecture that keeps raw sources immutable and the wiki local or on self-hosted infrastructure. BYOC deployments ensure data never leaves your environment, and the control plane stores only metadata. Permissions are enforced deterministically at the data layer, not by the AI itself.

What are the limitations or risks of automating a wiki with AI?

LLMs can introduce contradictions between pages, generate stale claims if new sources aren't reconciled, and create orphan pages with no inbound links.

1. Overview | Docs | PromptQL - promptql.io
2. PromptQL | Multiplayer AI with shared context. - promptql.io
3. [2605.18490] Single-Round Vector RAG vs an LLM-Compiled Wiki: A Preregistered Comparison on a Small Multi-Domain Research Corpus - arxiv.org
4. BYOC Security Model - docs.ververica.com
5. llm-wiki · GitHub - gist.github.com