The rise of the LLM-readable project wiki
The pattern is now widespread. Teams are restructuring docs, ADRs, PRDs, design notes, research folders, and live planning files so AI coding agents can understand the system faster. NotebookLM-style project knowledge bases, AGENTS.md / CLAUDE.md / PLANS.md conventions, Cursor rules, and repo-native wikis are all examples of the same move.
It is a useful move. An agent given a curated, retrievable library of project knowledge has a better starting point than one piecing things together from scattered chat history, tribal knowledge, or whatever happens to be open in a buffer.
The result is a generation of teams who have invested in making project knowledge legible to LLMs. The question this article is about is what that legibility actually buys you, and what it does not.
A library improves recall. It does not create authority.
A wiki can tell the agent what the architecture is. It cannot guarantee the agent treats that information as a constraint.
In practice, agents working against an LLM-readable wiki can still:
- retrieve the wrong document for the task at hand
- miss the relevant ADR entirely
- treat a binding rule as ambient background context
- follow a rule in one session and forget it in the next
- generate code that looks locally correct but violates a system boundary the wiki described
These are not failures of the documentation. The decision is written down. The architecture is on the page. The wiki found it. The agent read it. And then the agent shipped code that contradicted it.
The problem is not that the agent cannot read the rule. The problem is that reading is not the same as obeying.
The failure mode: the rule was documented, but not enforced
The most painful cases in real codebases are rarely caused by missing documentation. The decision usually exists. The architecture is written down. The PRD is clear. The ADR explains the constraint.
The failure is that none of it is active at the moment code is generated. The agent has access to the text. The agent may even cite it. But the text has no enforcement surface, so there is nothing in the loop that can block a generation that disagrees with it.
This is the structural reason that "we wrote it down, so the agent will follow it" keeps disappointing teams. Writing it down is necessary. It is not sufficient.
Documentation is context. Governance is constraint.
This is the category distinction worth keeping straight.
- Answers: what should the agent know?
- Organizes docs, ADRs, PRDs, plans
- Improves retrieval and grounding
- Passive: read only at request time
- Can be ignored, missed, or paraphrased away
- Answers: what must the agent not violate?
- Encodes binding architectural constraints
- Injected before generation, checked at CI
- Active: enters the loop, not just the context
- Deterministic verdicts with provenance
A wiki is a knowledge surface. Governance is a control surface. They are not competing layers; they sit on top of each other. The mistake is treating the knowledge surface as if it were already a control surface.
What turns project knowledge into governance?
Most project knowledge stays in the wiki and should stay there. Reference material, design context, history, and rationale do not need to be enforced; they need to be findable. Only a subset of project knowledge is binding, and that subset has to clear a higher bar to become governance.
Useful project knowledge becomes governance only when it is:
- Explicit.Stated as a checkable rule, not implied across paragraphs of prose.
- Scoped.Tied to the part of the system it actually governs, so it is retrieved when it is relevant and not when it is not.
- Retrievable at the right moment.Surfaced into the loop before the agent commits to a candidate change, not buried in a doc that may or may not be fetched.
- Enforceable before code lands.Evaluable by a hook or CI gate that can return a deterministic verdict against the resulting artifact.
- Auditable back to the source decision.Every verdict can be traced to the ADR, PRD, or policy it derives from, so enforcement is reviewable rather than opaque.
Knowledge that meets all five criteria is doing a different job than knowledge that sits in a wiki. It has stopped being reference material and become an executable architectural constraint.
The Mneme comparison frame
It helps to name each layer by what it actually does, rather than treating them as interchangeable.
| Layer | What it does |
|---|---|
| LLM wiki | Organizes project knowledge so agents can read it |
| Prompt files | Remind the agent what generally matters in this repo |
| ADRs & PRDs | Record architectural and product decisions for humans |
| Mneme | Turns selected decisions into enforceable constraints in the agent loop |
None of the upper layers go away. A team that adopts governance still needs ADRs and a project wiki, just like a team that adopts CI still needs a README. What changes is that the binding parts of the knowledge stop relying on the agent’s discretion to be honored.
Where Mneme fits
Mneme does not replace docs, ADRs, AGENTS.md files, or project wikis. It sits after them. It takes architectural intent from repo-native sources and makes it available as enforceable constraints for AI-assisted development — retrieved before generation, enforced at the hook and CI layers, and provenanced back to the source decision.
The wiki remains the library. Mneme becomes the law.
An LLM wiki helps agents understand the system. Architectural governance determines which parts of that understanding are binding.
Closing
If your team already has ADRs, design notes, or project rules, the next step is not another wiki. It is deciding which parts of that knowledge should become enforceable architectural constraints — and what enforcement surface they belong on.
The library is good work. It is not the last layer.