Runbooks Your Agents Maintain: Inside WUPHF's Markdown-Plus-Git Wiki Model

Your AI agents are already operating infrastructure. They roll back deploys, restart services, and triage alerts. Here is the question almost nobody has answered: where does their operational memory live? When an agent consults a runbook before a rollback, and writes a postmortem afterward, what system of record holds those documents — and who gets to audit, correct, or revert what the agent wrote?

In April 2026, a project called WUPHF put forward a blunt answer that earned 260 points on Hacker News: plain Markdown files in a Git repository. No proprietary knowledge base, no vendor API between an agent and its documentation — a wiki agents read with grep and write with commits. The claim worth examining is not "wikis are nice." It is that docs as a Git repo agents can PR beats a SaaS wiki's API on the three properties an agent-operated platform actually needs:

To be fair, that table is scoped to agent-operated knowledge. For non-technical human contributors, a SaaS wiki still wins on editing UX, permissions administration, and zero setup — nobody's marketing team wants to learn git rebase. But when the primary readers and writers of your runbooks are LLM agents, the trade flips, and this post walks through why: what WUPHF actually built, what an agent-driven rollback looks like end to end under this model, where the Git repo beats the wiki API mechanism by mechanism — and the failure mode Git does not solve, which the HN thread nailed to the wall.

What WUPHF Actually Is: The Mechanism​

WUPHF (yes, pronounced "woof") is a self-hosted, bring-your-own-keys workspace where multiple AI agents collaborate over shared context. It runs Claude Code, Codex CLI, or local models via Ollama, and it is free to self-host under a sustainable-use license with forking explicitly encouraged. The Show HN title called it "a Karpathy-style LLM wiki your agents maintain" — a reference to Andrej Karpathy's idea of treating an LLM as a background compiler that turns raw material into a structured, interlinked Markdown wiki that agents then maintain, rather than re-discovering the same knowledge on every query.

The part that matters for platform operators is the memory architecture, which has two tiers:

• Notebooks — per-agent, private working memory. An agent records observations and tentative conclusions here: "the staging deploy failed twice with this error," "the on-call human prefers rollbacks over hotfixes on Fridays." Notebooks are scratch space; nothing in them is authoritative.
• The wiki — a shared Git repository of Markdown articles living at ~/.wuphf/wiki/. This is the system of record, and it is deliberately boring: you can query it with cat, grep, and git log. No proprietary query language, no SDK.

The bridge between the tiers is a draft-to-wiki promotion workflow. Agents do not silently write to the shared wiki. When notebook material looks durable — a playbook that recurred, a fact that got verified, a preference that was confirmed — the agent receives a promotion hint and must explicitly promote the content into the wiki, where every teammate (human or agent) can discover it. Promoted knowledge arrives as commits attributed to an archivist identity, so git log gives you the full author chain of what the machines added and when.

Around that core, WUPHF layers retrieval and hygiene:

• BM25 indexing over SQLite — classic lexical search, no embedding service or vector database required. For runbook-shaped queries ("error code X," "service Y rollback"), exact-term matching is a feature, not a limitation.
• A /lint suite that flags contradictions between articles, orphaned pages, stale claims, and broken cross-references — automated hygiene for a corpus nobody human is proofreading daily.
• Append-only fact logs per entity, so the wiki behaves like a living knowledge graph with typed facts, backed by ordinary files.

None of these pieces is novel in isolation. Docs-as-code teams have kept Markdown in Git for a decade. What is new is the write path: the wiki's primary authors are agents, the review artifact is a diff, and the whole loop — consult, act, document — closes inside one version-controlled repo.

A Rollback, End to End​

Abstract arguments about knowledge management are cheap, so walk through a concrete incident on an agent-operated platform.

1. The agent consults the runbook. A deploy of api-gateway starts failing health checks. The operating agent does not call a wiki vendor's search endpoint with an API token. It runs the same thing you would:

grep -ri "api-gateway rollback" ~/.wuphf/wiki/runbooks/

and gets back runbooks/api-gateway.md, which contains the documented procedure: confirm the failing revision, shift traffic to the previous release, verify health, annotate the incident channel. BM25 search gives the same answer through the index; either way, retrieval is a local read against files on a machine you control. If the platform is down, the runbook is not — a clone of the wiki lives wherever the agent does.

2. The agent executes the documented steps — the rollback itself, via whatever deployment API the platform exposes.

3. The agent writes the postmortem as a reviewable diff. This is the step that separates the Git model from every "agent memory" scheme that appends to an opaque store. The agent drafts the postmortem in its notebook, then promotes it: a new file on a branch, proposed as a change a human reviews before it merges.

+++ b/postmortems/2026-08-07-api-gateway-rollback.md
+## Impact
+12 minutes of elevated 5xx (4.1% of requests) on api-gateway.
+## Root cause
+Revision 214 shipped a connection-pool cap of 10, saturating
+under normal load. Rolled back to revision 213 per
+runbooks/api-gateway.md.
+## Runbook delta
+The runbook's "verify health" step checked /healthz only;
+added a p95 latency check, which is what actually regressed.

Note the last hunk: the postmortem amends the runbook that was just used, in the same commit series. The knowledge loop — runbook consulted, gap found, runbook improved — is one reviewable unit of work, not a ticket filed in a second system that nobody actions.

4. The audit trail is just Git. Six months later, when someone asks "why does the runbook say to check p95 latency?", the answer is not archaeology:

git log --author=archivist -- runbooks/api-gateway.md

shows every machine-authored change, its date, its diff, and the postmortem that motivated it.

5. Bad knowledge gets reverted, not deprecated. Suppose a later incident reveals the agent's "root cause" was wrong — the pool cap was a symptom, not the cause — and other pages have started citing it. The correction is git revert <sha>: an atomic undo of the bad claim, itself recorded as a commit with a rationale. Try expressing "undo this edit and everything it touched, with a record of the undo" against a SaaS wiki's REST API.

Where the Repo Beats the Wiki API — Axis by Axis​

Auditability. In Git, attribution is structural. Every change has an author, a timestamp, and a byte-exact diff, and history ships with every clone — you cannot buy a tier of Git that forgets. SaaS wikis treat audit logging as a monetizable feature: typically gated to enterprise plans, capped at 90 days or a year of retention, and reporting events ("page edited by integration-token-7") rather than content-level diffs. For an agent-operated platform this difference is not cosmetic. When an agent's documented "fact" influences a production action, "what exactly changed, when, authored by which agent, reviewed by whom" is compliance evidence, and Git produces it as a side effect of existing.

Rolling back bad knowledge. Wrong knowledge in an agent system is not an embarrassment; it is an operational hazard, because agents act on it. The rollback story therefore matters as much for docs as for deploys. Git gives you revert for surgical undo, bisect for "when did the wiki start claiming this?", and branch protection to keep unreviewed claims out of the trunk agents consult. Page-based wikis give you per-page version history — fine for restoring one vandalized page, useless when a wrong claim was promoted, cross-referenced from four other pages, and needs to be unwound as a unit.

Ownership. The Google SRE book's postmortem chapter has a line that ages perfectly into the agent era: "an unreviewed postmortem might as well never have existed." Review requires access; access requires the corpus outliving vendor pricing changes, API deprecations, and acquisitions. A wiki that is a Git repo is owned the way your source code is owned: cloned redundantly, readable offline with tools that will exist in thirty years, migrated by git push. And the review gate SRE culture prescribes for postmortems? The PR is that gate. Agent-written knowledge enters the shared record through the same mechanism as agent-written code — a diff a human approves — rather than through an API call that lands unreviewed.

The pattern also inherits docs-as-code's quieter virtue: proximity. When runbooks live in a repo beside the platform's code and state, the deploy that changes behavior and the runbook update that documents it can land in the same review — which is the only reliable cure for documentation drift ever discovered.

The Failure Mode Git Does Not Solve​

The HN thread's most valuable contribution was refusing to let the architecture claim too much. The top-voted concern was quality decay: LLM-maintained wikis accumulate confident errors. As one commenter (ryanshrott) put it, "the confidently wrong problem gets worse over time because bad entries get cited by other agents" — and that is how you end up, in another commenter's words, with "a knowledge base full of confident BS." A third (mplappert) compressed the sociology of it: "Everyone is writing. Nobody is reading."

WUPHF's author was notably honest about the boundary: "garbage in, garbage out. The lint pass helps. It is not a judgment engine." Lint can flag that two pages contradict each other; it cannot tell you which one is wrong.

Git does not solve this either — it makes the remediation cheap (revert, bisect, attribute), not the detection. What actually mitigates confident-wrong accumulation is process layered on top of the substrate:

• Human review gates on promotion. Draft freely in notebooks; merge to the shared wiki only on approval. The promotion workflow exists precisely so the default is not "agent wrote it, therefore it is true."
• Provenance links. A claim citing the incident, log line, or commit that produced it can be re-verified; a bare assertion cannot. Append-only fact logs help here.
• Periodic re-verification. Stale-claim linting plus scheduled agent passes that re-check high-traffic runbooks against reality — the machine equivalent of SRE's practice of resurfacing old postmortems in training exercises.

The honest framing: Markdown-plus-Git is the best substrate yet proposed for agent-maintained ops knowledge, because it makes every failure of the process visible and reversible. It is not a quality guarantee, and any team adopting the pattern should budget for the review discipline, not just the tooling.

Ops Memory for Agent-Operated Platforms​

Zoom out from WUPHF the project to the pattern it demonstrates, because the pattern will outlive any single implementation — the HN wave around Karpathy's LLM-wiki idea produced at least half a dozen independent takes in a single month, all converging on Markdown, Git, and lexical search.

An agent-operated platform has three kinds of memory: the code that defines it, the state that describes it, and the operational knowledge that explains how to run it. The first has lived in Git for twenty years. The second is heading the same way — declarative specs, GitOps, infrastructure state that agents can read as data rather than scrape from dashboards. WUPHF's wager is that the third belongs there too: runbooks an agent greps before acting, postmortems it files as PRs afterward, and a git log that makes the whole operational memory of a platform auditable, revertible, and owned by the people running it.

That is a low bar to clear technically — a directory of Markdown files — and a high bar culturally, because it means treating agent-written knowledge with exactly the rigor you treat agent-written code: reviewed on the way in, attributed forever, reverted without ceremony when wrong. Teams that adopt that discipline get something genuinely new: a platform whose operators improve its documentation as a side effect of operating it. Teams that skip the discipline get a very well-versioned pile of confident BS. The repo model, to its credit, at least lets you git log your way to knowing which one you have.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.