The three-layer memory model — short-term, long-term, semantic — is the floor. It is enough to keep a single agent session coherent and to let one session find what another session wrote. It is not enough to keep a workspace coherent over a year. For that you need a fourth layer: wiki memory.
A wiki memory is not a file the agent writes. It is not a vector store the agent queries. It is a knowledge base a human is actively editing, organized so the agent can read it the way the human reads it — by following links, by trusting provenance, by knowing which pages are still alive and which ones have been superseded.
This piece is about what a wiki memory is, why it is a different layer rather than just a bigger long-term memory file, and what it costs to keep one alive.
Why three layers is not enough
The standard three-layer model has a quiet failure mode. After the first few months, the long-term memory file accumulates notes that contradict each other. The semantic store retrieves a chunk from a year-old decision that nobody remembers making. The agent starts hedging. The user starts losing trust. The workspace drifts.
This drift is not a retrieval problem. The retrieval is doing exactly what it was designed to do — surface the most relevant chunk for the current prompt. The drift is a curation problem. Nobody is deciding which notes are still true, which ones contradict each other, and which ones the agent should treat as canonical.
Long-term memory, even when it is written carefully, is append-only in practice. Agents add notes; they almost never remove them. Semantic memory is even more append-only — chunks get added, but the embedding model drifts, the chunk boundaries stop making sense, and the index becomes a graveyard.
Wiki memory is what you get when someone decides to edit the knowledge base, not just write to it. Editing means: pulling related notes into a single page, marking which page is the canonical version of a fact, linking a claim to its evidence, and deleting the older pages instead of letting them accumulate forever.
What a wiki memory looks like
A wiki memory has three properties that distinguish it from a notes folder:
1. Link density. Pages cite other pages. A fact is a link, not a re-statement. The reader follows the link to verify; the agent follows the link to gather more context. 2. Canonicality. Each fact has one page that owns it. Other pages may mention the fact, but they link to the canonical page rather than re-asserting it. When the canonical page changes, all the other pages pick up the new version automatically. 3. Provenance. Every claim carries evidence. A wiki memory that does not say why a page says what it says is just a Markdown folder with extra steps.
The combination of these three properties is what makes a wiki memory useful to an agent. The agent can read the wiki the way the human reads it — following links, trusting canonical pages, checking provenance before acting on a claim.
A notes folder does none of these things reliably. A vector store cannot do any of them at all.
Wiki memory is not just long-term memory with structure
The common mistake is to treat wiki memory as a stylistic upgrade to long-term memory. "Our MEMORY.md is already well-organized. We don't need a wiki." That is wrong, and the difference is more than cosmetic.
Long-term memory is append-mostly. Wiki memory is edit-heavy. Long-term memory asks "what should the agent remember?" Wiki memory asks "what should the agent believe right now, given everything it has learned?" Those are different questions. The first grows monotonically. The second is revised.
A practical test: if you cannot delete a memory file without losing information that the agent needs, you do not have a wiki memory yet. You have a long-term memory that has become a wiki in all but name — which is fine, but it should be operated like a wiki, not like a notebook.
The costs of operating it like a wiki:
- Someone (human or agent) must review pages and decide what is still true.
- Canonical pages must be moved, renamed, or merged when facts change.
- Outdated pages must be deleted, redirected, or marked as superseded.
- Provenance must be updated when evidence changes.
These are not optional. They are what makes the wiki a wiki and not a pile.
Why agents need wiki memory, not just better long-term memory
Long-term memory files are written by the agent, for the agent. Wiki memory is written by both, but edited primarily by the human. This is the part most agent designs skip.
The reason the human has to be the editor is that the agent cannot detect when its own memory is stale. The agent will cheerfully cite a six-month-old page as the current state of the world because, from its perspective, it is the current state of the world. The agent will not know that the canonical name of a project changed, that a service account was rotated, or that a configuration file is now in a different path. Those facts live in the heads of the humans who run the workspace.
When those facts go into a wiki, the human is the one who updates the page. When they go into long-term memory, the agent writes a new note, the old note is still there, and the contradiction sits silently until something breaks.
The minimum viable wiki memory
You do not need a full Obsidian vault to get the benefits of wiki memory. You need three things:
1. One canonical page per durable concept. Examples: a page per entity, per recurring task, per external service, per recurring pattern. The pages are short. They are linked from everywhere. 2. A "see also" or "related" section on each page. This is what makes the wiki traversable. A page that is not linked is a page that does not exist. 3. A review cadence. Once a quarter, someone reads every page and decides whether it is still canonical. Pages that are no longer canonical get marked superseded; pages that contradict the current state get rewritten; pages that nobody links to and nothing has read in six months get deleted.
The review cadence is the part most workspaces skip. Without it, the wiki slowly becomes the long-term memory file it was supposed to replace — append-only, contradictory, and silent.
When a wiki memory is overkill
A wiki memory is not free. The cost is the human review time. For a personal assistant that handles a handful of recurring tasks, that cost is too high. A well-maintained long-term memory file is enough.
The signal that you need a wiki memory is one of these:
- The agent's answers are starting to contradict each other across sessions, and you cannot tell which one is correct without re-reading the conversation.
- You find yourself re-explaining the same project context every week because the agent's notes do not match your understanding.
- New team members (or new sessions) cannot get up to speed from the long-term memory file alone, because the file is too dense or too outdated.
None of these failures are retrieval problems. They are curation problems. The fix is to move the relevant facts into a wiki, link them, mark the canonical version, and review the wiki regularly.
What the agent's job becomes with a wiki memory
Once a wiki memory exists, the agent's job changes in two specific ways.
First, the agent stops writing long-term memory for facts that have a wiki page. Instead, the agent writes a note that says "see project-x" and the wiki page carries the detail. The long-term memory file becomes shorter, not longer, as the wiki grows. This is the opposite of what most workspaces expect.
Second, the agent starts reading the wiki at intake, not just the long-term memory file. The wiki is the agent's source of truth; the long-term memory file is the agent's own scratchpad. The wiki is edited. The scratchpad is appended.
The intake order at the start of a session is roughly:
1. System prompt. Identity, role, capabilities. 2. Wiki memory. Hand-edited canonical pages for the workspace. 3. Long-term memory. The agent's own notes, scoped to what is not already in the wiki. 4. Semantic retrieval. Top-K chunks from the vector store, used only when the wiki and the notes do not have an answer.
This is the layer cake. Each layer covers what the layer below it does not.
A field note on provenance
Provenance is the cheapest part of a wiki memory and the most skipped. Every claim in the wiki should answer two questions:
- Where did this fact come from? (A primary source, a transcript, a date, a person.)
- When was this fact last verified? (The review date.)
If the answer to either question is missing, the wiki is collecting unverifiable facts. Those facts will drift. The drift will be silent. The agent will cite them confidently. That is how wiki memories become liabilities instead of assets.
The simplest implementation: each page has a small "Sources" or "Last reviewed" line at the bottom. A line of two fields. That is enough to make the wiki auditable.
Closing
Three-layer memory gets an agent through the first month. Wiki memory is what gets a workspace through the first year. The cost is real — a human (or a disciplined agent) must review and edit periodically — but the cost is paid once per page, not once per session. The compounding benefit is that every session after the review runs against a knowledge base that is closer to the truth, not further from it.
If you are building or running a long-lived agent workspace, the question is not whether you need a wiki memory. The question is when you will start paying the cost of keeping one alive.