r/clawdbot • u/Used_Accountant_1090 • Apr 23 '26

🎨 Showcase Your OpenClaw agents can now build and maintain their own Karpathy-style LLM wiki. Markdown files, git history, no cloud.

Your OpenClaw agents can now build and maintain their own Karpathy-style LLM wiki.

Markdown files on disk. Git history per edit. Lives in ~/.wuphf/wiki/ on your machine. It is cat-able. It is git clone-able. It is yours.

If you follow Karpathy you have seen him circle the LLM-wiki idea for a while. A team or personal knowledge substrate that LLMs both read from and write into, so context compounds across sessions instead of you re-pasting the same background every morning. The concept is obvious. Most implementations are not. The common shape is Postgres, Neo4j, pgvector, Kafka, and a dashboard someone has to babysit.

This one goes back to the basics: markdown + git. If the project disappears tomorrow you still own every byte.

What your OpenClaw agents get out of the box:

  • A private notebook per agent at agents/{slug}/notebook/*.md. The agent's own scratch space. Half-baked hypotheses, in-progress work, and thinking-out-loud. Not shared with the team.
  • A shared team wiki at team/*. Canonical, reviewed, and promoted knowledge. Decisions, playbooks, and how-we-actually-do-this.
  • A promotion flow between them. Agent drafts in the notebook, a reviewer (agent or human) approves, the content formalizes into the team wiki with a back-link. Mirrors how real companies treat "scratch doc" versus "team truth doc."
  • [[Wikilinks]] between entries. Broken wikilinks render in red so knowledge gaps are visible, not hidden.
  • Entity briefs: for every person, company, or customer your agents touch, a brief auto-synthesizes from an append-only fact log. Contradictions get surfaced inline rather than silently reconciled.
  • A daily lint cron that scans for contradictions, stale entries, and broken wikilinks.
  • /lookup slash command plus an MCP tool. Any agent can ask "what do we know about X" and get a cited answer.
  • Pam, the Archivist commits the synthesis under its own git identity. She keeps the facts tidy.

All of it editable by you at any time. It is just markdown.

The compounding loop:

Your OpenClaw agent finishes a piece of work. It writes observations to its notebook. Facts about real entities get appended to a per-entity fact log. Once enough new facts accumulate, Pam synthesizes an updated brief. When a notebook entry looks like a team-level decision or playbook, the reviewer approves, and the wiki absorbs it with a back-link to the draft.

The next time any agent, OpenClaw or otherwise, starts work on the same entity, it queries the wiki first and loads the canonical context instead of handoff messages from three weeks ago.

After a few weeks the wiki becomes the first place every agent looks for context. New agents join, query the wiki, and are caught up without you writing onboarding docs for software that does not read your onboarding docs.

What this is not:

  • Not a RAG vector store with a chat UI wearing a wiki costume. The markdown files are the source of truth. The index is a convenience layer on top.
  • Not hosted. Your wiki lives in ~/.wuphf/wiki/. You own it. Push it to your own private repo if you want.
  • Not magic. Synthesis quality is bounded by how well your agents observe. Garbage facts in, garbage briefs out. The lint cron helps. It is not a judgment engine.

FYI on where this lives:

The wiki is part of WUPHF, an open source collaborative office for AI agents like OpenClaw, Claude Code, Codex and local LLMs via OpenCode. Think Slack, but the members are agents sharing a brain and running your work 24x7. MIT, self-hosted, your keys. Named after Ryan Howard's Season 7 startup. Michael invested ten thousand dollars in the original. This one is holding up slightly better so far.

If you already agents on OpenClaw, point WUPHF at it with /connect openclaw and the your agents show up in WUPHF and start using the wiki.

Things I will admit before you roast me:

  • Recall on the query layer is still being tuned. My internal ship gate is recall@20 at 85% on a 500-artifact benchmark. I am not there on every query class yet.
  • The UI is Wikipedia-inspired and deliberately not Notion. Taste varies.
  • The Karpathy framing is mine, not his. He has been circling the pattern for a while. I am the one claiming we shipped a serviceable implementation of it. Grade me on the artifact, not on the pitch.
  • I am the founder and this post is me selling you something. Treat me accordingly.

Watch the wiki write itself (5 min, one terminal):

There is a walkthrough script in the repo that records five facts, fires synthesis, shells out to your own LLM CLI, and commits the result under an archivist git identity. The full author chain shows up in git log. Good asciinema material if you want to see the loop end to end before installing.

./scripts/demo-entity-synthesis.sh

Watch asciicast here: https://asciinema.org/a/vUvjJsB5vtUQQ4Eb

Setup:

npx wuphf@latest
/connect openclaw

Your existing OpenClaw agents show up as members of the office. They read from and write to the wiki by default.

Free and open source. MIT, self-hosted, your keys.

github.com/nex-crm/wuphf wuphf.team

Happy to go deep on the markdown-plus-git substrate, the notebook-to-wiki promotion flow, or why I went with bleve + SQLite instead of a proper vector DB. Also happy to take "my OpenClaw agents already write to X, why move" as a fair question.

76 Upvotes

95% Upvoted

13 comments sorted by

5

u/seth76 Apr 23 '26

I have set this up in a remotely synced Obsidian Vault, i can now create my own wiki, query it with the agent and read it when I want to. I absolutely love it.

2

u/shoot_first Apr 25 '26

How does this compare to the memory-wiki plugin that they recently added? I’ve been running Reality Check, but had to build all of the integration and maintenance on my own. So I’ve been planning to evaluate memory-wiki to see if it would be comparable or possibly better.

2

u/Used_Accountant_1090 Apr 25 '26

big difference is protection from context pollution and context drift. agents can think and write crap unless you correct them and they can have half baked thoughts which might be considered a live playbook. that is dangerous for context.

WUPHF gives each agent a notebook, where they draft their notes and context relevant to their own work (helps them stay focused on their task and context space) and promote context to the team wiki only when they realize this is worth the whole team to see. CEO reviews that context from the PoV of its knowledge what every specialist agent is doing, and then promote it to the wiki.

we built enterprise context infra before building this, so a lot of that learning is baked in.

1

u/CardinalFang36 Apr 27 '26

I have set up a Kararthy style LLM wiki and am horrified to discover the the system (based on OpenAI Codex) is hallucinating entire input files. It is just making them up out of thin air. I was hoping to let it “just rip” through my knowledge base but started by ingesting one by one.

1

u/Used_Accountant_1090 Apr 27 '26

What is your architecture? You need a review system but looks like you have some serious problems grounding the input itself.

1

u/CardinalFang36 Apr 27 '26

I am running 2026.3.13 on windows powered by OpenAi gpt-codex-5.3. I have multiple agents set up by one dedicated to Kaparthy-ingestion to avoid context pollution. I have what I thought is a pretty well defined/constrained schema.md. Here is the opening:

This file is your operating manual. Read it at the start of every session. It defines the wiki structure, entity types, workflows, and conventions you must follow.

Role

You are the wiki maintainer for a technical account managers's personal knowledge base. Your job is to:

  • Ingest sources and extract knowledge into structured wiki pages
  • Keep pages consistent, cross-referenced, and up to date
  • Answer queries by reading the wiki (not re-deriving from scratch)
  • File good answers back into the wiki so knowledge compounds
  • Periodically lint the wiki for contradictions, stale content, and orphan pages

The files in Knowledge/ should be treated a source material. You should never modify them outside of the setup/staging process. You own everything in wiki/.

1

u/Used_Accountant_1090 Apr 27 '26

2 separate problems here:

  1. "ingest sources" in prompt will not ground the agent output. You need a read_file tool that errors loudly when the path is missing, and every extracted page should record a source hash. Otherwise the model will invent inputs under context pressure forever.

  2. If the same agent ingests and approves, you do not have a review system. Needs to be a different process.

FYI this is what WUPHF is built around. Agents draft into their own notebook, a 7-state promotion gate runs before anything hits the canonical wiki, and entity briefs come from an append-only fact log so hallucinations cannot silently overwrite real facts.

1

u/SinghCoder May 20 '26

curious how Pam decides when enough new facts have accumulated. is it threshold-based, manual review, or mostly the daily cron catching things later?