The LLM Wiki: Turning the Knowledge in a Few People's Heads Into an Asset Every Agent Can Read

The most valuable asset inside most organizations is also the least readable. It is the knowledge of how the business actually works — how the systems fit together, why a policy exists, what a client agreed to three years ago and the reason behind it — and it lives almost everywhere except a place a newcomer or a machine could read it. It sits in the senior engineer who is the only person who understands how four services talk to one another. It sits in a folder of PDFs no one has opened since the handbook was last rewritten. It sits in a decade of meeting notes, custodial statements, and email threads scattered across a dozen systems that were never designed to be read together. The knowledge is not missing. It is unreadable — and a workflow that cannot read its own institution's memory is operating half-blind.

Map where that knowledge actually resides and the problem takes a specific shape. The largest single estate is tacit — held in the heads of a few long-tenured people who have never had reason or time to write it down, and whose departure would take an irreplaceable portion of the firm with them. The next is code: repositories that run the business but whose architecture, dependencies, and the reasons behind their oddest decisions were documented, if ever, against a system that has since changed three times. Then the long tail — HR rules that live half in a policy PDF and half in what a manager remembers being told, financial data spread across accounting, payroll, custodial, and spreadsheet systems that do not speak to one another, and the sediment of email, chat, tickets, and CRM history that holds the actual record of what happened. Very little of it is readable in any systematic sense, by a person or a model.

The consequence is that retrieval inside most firms is social rather than systematic — the way to find out how something works is to find the person who knows and ask them. That model has two failure modes, and both are expensive. It throttles everyone junior, because a staff engineer who could ship a change in an afternoon instead waits two days for fifteen minutes of a principal's time; the institutional knowledge of how the systems fit together is gated behind a handful of calendars. And it concentrates catastrophic risk in those same few people — the bus factor of an organization whose memory lives in three heads is three. Andrej Karpathy named the way out in a phrase worth taking literally: an organization's documentation should become a wiki written for an LLM to read — knowledge structured not as prose for occasional human reference but as a linked, navigable graph an agent can traverse on demand. The audience for institutional knowledge has changed. Its form should change with it.

An LLM wiki is that form: a knowledge graph, authored as a web of small linked notes, in which the unit is not the document but the entity — a system, a policy, a client, a decision — and the value is in the links between them as much as in the contents of each. It is, deliberately, a wiki in the original sense: every meaningful thing gets its own page, pages reference one another by name, and the references compose into a graph that can be walked. The difference from a conventional wiki is the reader. A human wiki is optimized for a person skimming a page; an LLM wiki is optimized for an agent that lands on a node, follows its links to the three other nodes it needs, and assembles exactly the context the task requires. The graph is not decoration around the knowledge. The graph is the semantic layer.

This is the structural reason an LLM wiki outperforms the default of pointing a model at a pile of documents. Raw retrieval — the naive form of retrieval-augmented generation — treats the corpus as a flat bag of text chunks and hopes that vector similarity surfaces the right ones; it has no notion that a client's investment policy statement is *connected to* the three allocation decisions that cite it, or that a service's outage history is *connected to* the architectural decision that caused it. A graph encodes those relationships explicitly, so the agent retrieves a connected subgraph rather than a scatter of loosely related fragments. The diagram below shows the shape: scattered, unreadable sources flow into a single linked vault, and out of that vault flow the agents and the people who can finally read it — each pulling the connected slice it needs.

The pragmatic way to build this does not require a database vendor or a six-figure platform. It requires Obsidian — an open-source, local-first knowledge tool whose entire store is a folder of plain Markdown files linked by simple `[[wikilink]]` syntax. The choice is load-bearing for four reasons. The files are plain text, so the vault is durable, diffable, and version-controllable in Git — the same discipline a firm already applies to code. The links are native, so the graph exists for free and can be rendered, walked, or queried. The tool is local-first, so a confidential vault never has to leave the firm's perimeter — the same custody argument that governs private AI generally. And it is extensible, so the same vault a person browses is the vault an agent reads and writes through a thin programmatic layer. The vault becomes the system of record for how the firm works.

The agentic layer sits on top of that vault and does two things, not one. It reads the wiki to ground its work — every answer, draft, or recommendation is assembled from cited nodes rather than from the model's parametric guesswork, which is what makes the output checkable. And, crucially, it writes back — a meeting concludes and its decisions become a new note linked to the client; a policy changes and the affected pages are updated and cross-referenced; a service is refactored and its architecture node is revised. This is the observe, reason, execute, escalate loop applied to knowledge itself: the system observes what changed, reasons about which nodes it touches, executes the update, and escalates the judgment calls to a human. A document pile is a static asset that decays from the day it is written. A wiki an agent maintains is a compounding one — more valuable, and more current, every week it runs.

It is also, and this is underappreciated, dramatically cheaper to operate. The cost and latency of an LLM call scale with the tokens it processes, and the naive instinct — stuff the whole corpus into the context window and let the model sort it out — is the expensive one, in dollars and in accuracy both, since a model buried in irrelevant context reasons worse, not better. The semantic layer inverts this. A meeting-prep query against a client whose full corpus runs to a hundred and eighty thousand tokens does not load a hundred and eighty thousand tokens; it walks the graph, retrieves the seven thousand that are actually relevant to this meeting, and leaves the rest in the cheap embedding index where it costs almost nothing to hold. The model sees a small, dense, relevant context and answers faster, cheaper, and better. Token efficiency is not a side benefit of the wiki. It is a direct consequence of giving the agent a map instead of a haystack.

Return to the codebase to see what this unlocks. In most engineering organizations the knowledge of how the systems fit together — which service owns which data, why an interface that looks wrong is load-bearing, what an archaic configuration is quietly protecting — is precisely the tacit, head-held knowledge that gates junior and staff engineers and concentrates risk in a few seniors. An architecture wiki, kept current by the agents working in the codebase, changes the access model. A coding agent that reads it before it touches a service inherits the institutional context a senior engineer would have supplied in a hallway conversation — the history, the constraints, the reasons — and so does the staff engineer reading the same vault. The senior's knowledge stops being a bottleneck and becomes a resource that scales. Any process the agent touches — a migration, a code review, an onboarding — improves, not because the model got smarter, but because it can finally read the institution it is working inside.

The clearest illustration of the pattern at full strength is in wealth advisory, where the unit of knowledge is the client and the firm's entire value is in how well it holds each client's particular situation in mind. Consider a representative advisor running a book of a hundred and fifty households, each with an LLM wiki of its own. A client's wiki is a linked graph of everything that defines the relationship: the investment policy statement and the risk tolerance behind it; the held-away assets and the tax situation that constrains every trade; the family circumstances — a child starting college, a business being sold, an aging parent — that drive the real objectives; and, most valuable of all, the reason behind every past allocation decision, captured as a dated note at the moment it was made. None of this is novel information. It already exists, scattered across the CRM, the custodial portal, a notebook, and the advisor's memory. The wiki simply makes it readable — by the advisor, and by the agents that work for the advisor.

On top of that per-client graph the agentic workflows become straightforward and powerful. A meeting-preparation agent runs the morning of a review: it reads the client's wiki, pulls the current state of the portfolio and the market, and assembles a brief that says what changed since the last meeting, where the allocation has drifted from the policy statement, which life events recorded in the graph now bear on the plan, and what three things warrant discussion — every claim linked back to the node it came from. An allocation-update agent goes a step further: asked to rebalance, it proposes specific changes grounded in the client's documented constraints — the tax situation, the held-away exposure, the stated risk tolerance — and presents them with the reasoning and the citations for the advisor to approve, reject, or adjust. The advisor walks into the meeting prepared in minutes rather than the better part of an afternoon, and the preparation is more thorough than a manual pass, because the agent never forgets a note the human might.

The effect on the desk is not subtle, and it is worth being precise about which part changes. The toil compresses — the gathering, the cross-referencing, the reconstruction of what was decided and why — while the judgment, the relationship, and the final decision stay exactly where they were, with the advisor. The chart below sizes the shift across four representative tasks. What the wiki removes is the part of the advisor's week that was never the point of being an advisor.

This is the same conclusion the broader analysis of the AI stack keeps reaching from a different direction: as the cost of raw intelligence collapses toward zero, the durable advantage is not the model but the context the model is given — and an LLM wiki is that context, made into an asset the firm owns. The model is a swappable input; the wiki is the moat. The human, meanwhile, is not removed from the loop but elevated above it — sovereign over the knowledge, the approvals, and the relationship, relieved only of the retrieval and the typing. The advisor who owns a current, agent-readable graph of every client is not competing on the same axis as the advisor who keeps it all in their head and a spreadsheet. One can scale their judgment across a growing book; the other is capped at what they can personally remember.

Because the wiki is the source of every grounded answer, it also carries the firm's honesty and audit burden in the right place. Each node should record its provenance — where the fact came from, when it was captured, who or what last touched it — so that an agent's claim can always be traced to a source rather than to a confident hallucination, and so that a node which is merely an inference is marked as one. The vault inherits the firm's permissioning, so a client's graph is visible only to those entitled to it. And the linked, dated record becomes the audit trail a regulator or a compliance review actually wants: not a forensic reconstruction after the fact, but a standing answer to *how did the firm know this, and when.* A knowledge graph built for agents turns out to be exactly the knowledge graph an examiner would have asked for.

A 90-day pattern keeps the build bounded and honest. Weeks one through three — pick one entity and seed the vault. Choose a single high-value entity type — a client, a service, a policy domain — and stand up an Obsidian vault with a deliberate note schema and a starting set of pages linked into a graph; resist the urge to boil the ocean across every estate at once. Weeks four through six — wire the read-only agent. Build the grounding layer that lets an agent traverse the graph and answer questions or draft artifacts with every claim cited back to a node, and nothing else yet. Weeks seven through nine — close the write loop. Add the observe-reason-execute-escalate maintenance loop so the graph updates itself as meetings happen, policies change, and code moves — with a human approving every write that carries judgment. Weeks ten through twelve — measure the right things. Track ramp time for a newcomer, preparation time per task, tokens per query, and the share of agent answers that are correctly grounded; a wiki that does not move those numbers has not earned its place. The firm exits the quarter with one entity type fully readable and a pattern it can extend.

The knowledge that runs a firm already exists. That is the part operators consistently miss: building an LLM wiki is not a project to *create* institutional knowledge but to *make readable* the knowledge already locked in a few people's heads, a few neglected repositories, and a thousand scattered files. The firm that does it gives every person and every agent a map of how the institution actually works, and watches that map grow more valuable each week it is maintained. The firm that does not remains one resignation, one undocumented refactor, one forgotten rationale away from amnesia — paying senior people to be human search engines for knowledge that should have been written where a machine could read it. The model that reads the wiki will be obsolete in a year. The wiki will still be there, deeper and more connected, the day the next model arrives. The asset was never the intelligence. It was always the knowledge the intelligence could finally read.

Operators who want to turn the institutional knowledge trapped in a few heads and a dozen systems into an agent-readable asset can start with a [forty-five-minute fit call](/fit-call) — a direct read on which entity type to make readable first and what the wiki would unlock — or commission [a productized first workflow](/first-workflow) built on an Obsidian-based LLM wiki, with the grounding layer, the write-back maintenance loop, and the provenance and audit trail included at construction.