Rohit Ghumare · August 4, 2026 · 8 min read

OpenWiki: The LLM Wiki Pattern as Running Code

The LLM wiki is a pattern, and patterns get implemented. In 2026 this one got built into real tooling, twice, by two teams that reached opposite conclusions about what shape it should take. One is a connector-rich command-line product whose wiki is Markdown you commit alongside your code. The other is the same generate-search-refresh-lint lifecycle taken apart into functions and triggers on a runtime. Reading both back to back is a short course in a bigger question: when do you ship a capability as a product, and when do you ship it as primitives?

Disclosure: I contributed to the worker implementation discussed below. I have tried to describe both projects from their source rather than sell either.

The product: a self-maintaining CLI

langchain-ai/openwiki bills itself as "the self-maintaining wiki, built for agents, explored by humans." It is a TypeScript CLI you install with npm install -g openwiki, built on the Deep Agents SDK, and it runs in two modes: a default code mode that documents a repository into an openwiki/ directory, and a personal mode that documents connected knowledge sources into ~/.openwiki/wiki. Since its June 2026 debut it has drawn past fourteen thousand stars, which tells you the itch is real.

Its defining decision is that the wiki is plain Markdown you own and version-control. Every page is emitted in Google's Open Knowledge Format, a light frontmatter convention where each concept doc declares a type and links to others with ordinary Markdown links, with index.md and log.md reserved exactly as the original pattern describes. The operations are the ones you would expect, exposed as flags:

• openwiki --init reads the repo and writes the first wiki.
• openwiki ingest all pulls raw material through connectors: git, Notion, Slack, Gmail, X, Hacker News, and Tavily web search, each landing raw data before an agent synthesizes it.
• openwiki --update refreshes, and dropped into CI it opens a documentation pull request on every change.
• openwiki visualize serves an interactive graph viewer on loopback so you can walk the wiki as a graph.

Linting leans on the format: a lightweight, zero-dependency Mermaid diagram check by default, a wiki-link validator, and an evals/ suite, with broken diagrams degraded to plain text fences and repaired on the next update. The whole thing is a product in the honest sense: broad connector coverage, an open output standard, and a refresh loop that lives in your CI and files PRs at you.

The decomposition: the same lifecycle as a worker

The iii-hq/workers openwiki worker (v0.1.0, Apache-2.0) makes the opposite bet. Instead of one binary, it exposes the same lifecycle as roughly twenty-five openwiki::* functions on a runtime, reachable four ways: the iii trigger CLI, an HTTP API and browser UI the engine serves under /openwiki, a Server-Sent-Events stream for live generation progress, and an MCP surface compatible with the DeepWiki convention. You install it with iii worker add openwiki, which pulls its own dependencies, a state store, a cron worker, and an LLM router.

Where the CLI writes files, the worker persists pages and a page index into the runtime's key-value state, keeping a single side-index per wiki so a query never has to load every Markdown body and block the event loop. The git clone, which cannot live in a key-value store, sits on the filesystem pinned to a commit SHA, and citations are path:line references anchored to that pinned commit. Generation is a two-stage flow: a lead agent ranks the repository into a prioritized file tree and produces an outline where every item must cite a real path, then parallel writer sub-agents fill each page grounded in the source files they were handed. Refresh is incremental, it regenerates only the pages a git diff touches, and the cadence is driven by the engine's own cron through a set-schedule function rather than by an external CI job. Lint checks citation integrity, that each cited file exists and the line range is in bounds, plus thin pages and a present clone.

Pick an operation and see how the same verb resolves in each.

Same idea, two philosophies

The abstract pattern maps cleanly onto both, which is the point worth sitting with. One capability, generate a grounded wiki and keep it current, expressed once as a product and once as a set of primitives.

Neither is more correct. The product wins when the wiki's job is to be read by humans and their coding agents, checked into the repo, portable to anyone who clones it. The decomposition wins when the wiki is one capability among many that a larger system needs to call, schedule, and compose, when "generate the wiki" should be a function another service can trigger and "refresh nightly" should be a cron edge, not a YAML file in someone's CI. This is the same tension I traced in the composable agent runtime: a product is a point chosen on the thin-to-thick slider and frozen there; primitives leave the slider in your hands. You pay for that flexibility with a runtime to host them.

What both prove is that the LLM wiki has crossed from idea file to infrastructure. The interesting engineering is no longer whether an LLM can maintain a knowledge base, it plainly can, but which of these two shapes your use actually wants. If your knowledge should travel with your code, take the files. If it should be a service the rest of your system calls, take the functions. The lifecycle underneath, ingest, query, lint, is the same either way.