A wiki of a codebase is documentation. A wiki of a person is a profile, and that changes everything about how you have to build it.

Harrison Chase published a short, sharp piece on what he calls wiki memory, and it is worth reading if you care about how agents remember. The idea: instead of retrieving raw chunks at query time, you have an agent read the source material once and write a compact, structured, human-readable synthesis it can consult later. In his words, "A wiki is an agent-maintained data structure that represents source knowledge in an agent-friendly way." The contrast with retrieval is the whole point: "RAG usually retrieves raw chunks at query time. A wiki precomputes and maintains a higher-level synthesis, so the agent does not have to rediscover the structure every time."

Reading this felt less like news than like the industry converging on something a few of us have been arguing for a while. The work was never the storage. It was deciding, at write time, what the data means. Wiki memory is that decision, made in the open, in markdown.

So I agree with the pattern. I want to take it seriously enough to say where it stops, because the post itself draws that line, and the thing on the other side of the line is the entire hard problem.

What the wiki gets right

Precompute the structure once; do not rediscover it on every query. That is the correct instinct, and it is the same one I made the case for in Guided Memory Extraction and 3 Shortcomings of RAG as a Memory: raw content is what was said, extracted memory is what was meant, and the ceiling of any system is set at write time, not retrieval time. Chase is describing the same move one level up, at the document rather than the fact, and reaching for the simplest possible substrate to hold it. "Files are attractive because they are inspectable, editable, versionable, and easy for agents to read and write."

The pattern is already real where it fits. DeepWiki, from Cognition, regenerates browsable documentation for any GitHub repository. Factory shipped AutoWiki to do the same for a codebase and keep it current as the repo changes. Karpathy wrote about maintaining what he called an "LLM Wiki" between himself and his raw sources. For durable domain knowledge, this may well be, as Chase puts it, "the simplest useful long-term memory pattern we have." I would use it, and I would not overthink it. A codebase is a good thing to keep a wiki about.

The boundary the post draws for you

Chase is careful, and he names the limit himself. Wikis are "best for durable domain knowledge, not necessarily short-term conversation state, user preferences, or high-frequency event logs."

Read that exclusion list again, because it is not a footnote. Conversation state, user preferences, the stream of events a relationship generates: that is the person. The customer, the prospect, the employee, the patient. The wiki is for the codebase. The harder and more valuable frontier is the record of a human, and the post quietly hands it back to you as out of scope.

A wiki of a codebase is documentation. A wiki of a person is a profile. The substrate that makes the first one elegant is what makes the second one a problem.

Why a person is not a codebase

Three things break when the subject is a human, and each is a place I have had to build something files cannot do.

Structure for action, not just reading. A codebase wiki exists to be read. A person's record exists to be acted on: pull every contact whose renewal lands in Q2 and whose budget cleared a threshold, sort accounts by churn risk, compute the pipeline. Prose cannot be queried that way. You need typed properties alongside the free text, which is why I have argued memory has to be dual: free text and typed properties at once. The wiki gives you the readable half. It does not give you the half an agent can filter, sort, and compute on, and for anything operational that half is not optional.

Boundaries a file cannot enforce. "Inspectable, editable, versionable" is a virtue for a codebase and a liability for a person. A human record carries PII, consent limits, and facts one team may see and another may not. A markdown file has no field-level permission, no redaction, and no wall between one subject and the next. I have written about zero cross-entity leakage and layered PII redaction not because they are nice features but because, in a governed system, they are the license to operate. A plain file has none of them, and "just read the file" is a different sentence when the file is about a person.

Many writers, and a truth that moves. DeepWiki documents a repo in one pass over a slow-changing source. A person's record is written by many agents and many humans at once, and the facts contradict each other over time: a prospect prefers Vendor A in March and Vendor B in May after a bad rollout. Append-only prose accretes those contradictions and makes the agent reason through them at read time, every time. What you actually need is supersession, conflict resolution, and a write path that compounds instead of piling up, because agents do not share what they know unless the layer underneath makes them.

None of this is an argument against the wiki. It is an argument about what has to sit under the wiki the moment its subject can be harmed.

A wiki of a person is a model of a person

Here is the part worth sitting with. Strip away the substrate debate and a person-wiki is a synthesized, readable dossier assembled from someone's exhaust. Memory is just a polite word for a model of someone. The same auto-generated profile that lets a sales agent open with the one thing a buyer actually cares about is, unchanged, the most efficient targeting artifact you could hand to anyone who wants to move that person toward a decision. Every system precise enough to serve a person this well is precise enough to manipulate them.

That is why files-as-substrate for people is not merely insufficient, it is risky. An ungoverned, copyable markdown dossier on a human is a liability with a filename. And it reframes what governance is for. Governance is not the tax you pay on top of the wiki. For a person, governance is the wiki: it is the layer that decides whether the model of the person serves the person or gets used against them. Take it out and you have not built a lighter memory system, you have built an unattributed profile that anyone with read access can lift.

Build the wiki

The instinct is right, and it will win where it belongs. Codebases, runbooks, product docs, the durable domain knowledge Chase describes: keep a wiki, and enjoy how little machinery it takes. For that world, the simplest pattern really is the best one.

For people, the wiki is only the readable surface of something that has to be structured and governed underneath. Build it anyway. Just do not confuse the document with the model, or the codebase with the person. The first is a file. The second is someone's life, rendered legible to a machine, and legible cuts both ways.

References

  • LangChain (Harrison Chase) — "Wiki Memory": https://www.langchain.com/blog/wiki-memory
  • Cognition — "DeepWiki: AI docs for any repo": https://cognition.com/blog/deepwiki
  • Factory — AutoWiki, referenced in the LangChain "Wiki Memory" post above.
  • Andrej Karpathy — "LLM Wiki," referenced in the LangChain "Wiki Memory" post above.
  • Zep — "Stop Using RAG for Agent Memory" (2025): https://blog.getzep.com/stop-using-rag-for-agent-memory/
  • Letta — "RAG is not Agent Memory": https://www.letta.com/blog/rag-vs-agent-memory