Memory is the part of an agent system that decides whether the agent remembers anything between loops. The model itself remembers nothing. The platform it runs on may remember a transcript. A separate layer may remember facts. A wiki layer may remember which facts are canonical. Each layer costs something — disk, retrieval time, human review — and each one buys a different kind of coherence.

This pillar surveys the four layers Triadive has documented, the design choices that decide which layer to reach for, and the failure modes that show up when the wrong layer is picked for the job. It is meant to be read once and returned to when a memory problem shows up in a running system.

The point is not to memorize the layers. The point is to recognize which one a system is currently relying on, why it is failing when it is, and what moving to a different layer — not a better embedding — would do.

What memory is, in one paragraph

Memory in an agent system is state that survives between iterations of the loop. Anything that does not survive an iteration is not memory; it is local variable. Anything that does survive an iteration is memory, regardless of whether it lives in a file, a database, an embedding index, or a wiki page.

Three properties define a memory layer:

1. What it stores. Facts, transcripts, vectors, canonical pages, tool call logs. 2. How it is queried. By exact match, by semantic similarity, by following links, by timestamp. 3. Who edits it. The agent, the human, both.

Different layers optimize for different answers to those three questions. Choosing a memory layer is mostly answering them explicitly.

The basic piece on Memory: Short-Term, Long-Term, and Semantic introduces the three-layer model. This pillar adds a fourth layer and treats all four as a system rather than a stack.

The four memory layers

Triadive works through four memory layers. Each one has a clear job, a clear cost, and a clear failure mode when it is asked to do work that belongs to a different layer.

Layer 1 — Short-term memory

Short-term memory is the conversation context the model sees in the current call. It includes the system prompt, the user's messages, the model's previous replies, and any retrieved chunks that were injected for this turn. It does not survive past the call.

Short-term memory is fast, cheap, and obviously bounded by the context window. Its job is to keep a single iteration of the loop coherent. Its failure mode is that it runs out: once the context window is full, the agent loses track of the earliest parts of the conversation. The piece on Why Context Explodes Without Bounding treats this in depth.

The most important design choice for short-term memory is what to leave out. Long system prompts, raw transcripts, and over-aggressive retrieval all push the window toward overflow. The fix is usually to make the short-term layer smaller, not to make the window bigger.

Layer 2 — Long-term memory

Long-term memory is notes the agent writes for itself, across iterations and across sessions. It is usually a file (or a folder of files) that the agent reads at intake and appends to at persistence. It survives the call. It does not survive without curation.

Long-term memory is what lets the agent carry context between sessions. Its job is to be the agent's own scratchpad. Its failure mode is the well-documented one: long-term memory files grow monotonically, contradict themselves, and accumulate notes that nobody re-reads. The piece on Memory Design Mistakes catalogues the four most common versions of this drift.

The most important design choice for long-term memory is what to delete. A long-term memory file that never shrinks is, in practice, a slow-moving wiki that nobody is editing as a wiki.

Layer 3 — Semantic memory

Semantic memory is a vector index over the agent's notes and transcripts, queried by similarity rather than by exact match. It survives sessions the way long-term memory does, but it answers a different question: what chunks of past work are most relevant to the current prompt?

Semantic memory is what lets the agent find old notes that are related to the current work even if the wording has changed. Its job is retrieval at scale. Its failure mode is that it cannot tell the truth from the stale: a chunk retrieved from a six-month-old decision that nobody remembers making looks, from the index's perspective, exactly like a chunk retrieved from yesterday.

The most important design choice for semantic memory is what not to index. Indexing everything means retrieving anything; retrieving anything means the agent spends context budget on chunks that look relevant but are not current.

Layer 4 — Wiki memory

Wiki memory is a hand-edited knowledge base that sits on top of the other three layers. It is edited primarily by the human, read by the agent, and organized so the agent can follow the links the way the human does. The piece on Wiki Memory introduces this layer.

Wiki memory is what keeps a workspace coherent past year one. Its job is to be the canonical source of truth for the things the long-term memory file cannot keep straight on its own. Its failure mode is the cost of keeping it alive — review time, edit time, the discipline of marking superseded pages as superseded.

The most important design choice for wiki memory is what pages to create in the first place. A wiki with a page for every transient fact is a wiki-shaped notes folder. A wiki with one page per durable concept is a wiki.

How the four layers work together

Once the layers are visible, the design choice becomes a routing problem: at any moment, which layer does this fact belong in?

A useful default, in order of intake at the start of a loop:

1. System prompt. Identity, role, capabilities, ground rules. 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. 5. Short-term memory. The current conversation context, which accumulates as the loop runs.

Each layer covers what the layer below it does not. The wiki is the floor for durable facts; the long-term notes cover recent work not yet promoted to the wiki; the semantic index covers retrieval at scale; the short-term context covers the live conversation.

A useful default for persistence at the end of a loop:

1. Did the loop produce a durable artifact? Save it where the wiki can link to it. 2. Did the loop produce a note worth keeping? Append it to the long-term memory file. 3. Did the loop reveal that the wiki is wrong? Update the wiki, not the long-term memory file. 4. Did the loop reveal that the long-term memory is wrong? Edit the long-term memory file — do not just append a contradicting note.

This is the layer cake in operation. It is what makes the four layers a system rather than four separate files competing for the agent's attention.

Choosing a memory layer for a new fact

When a new fact shows up in the workspace, the question is not "where should I store this?" It is "which layer is responsible for this kind of fact?" A short decision tree:

  • **Is it about the workspace itself — entities, recurring tasks, external services, recurring patterns?** → Wiki.
  • **Is it about a specific decision the agent just made, with a short shelf life?** → Long-term memory file.
  • **Is it about a transcript or a chunk that the agent might want to retrieve later by similarity?** → Semantic index.
  • Is it about the current conversation? → Short-term context, and let it expire when the conversation does.

If the answer is unclear, the answer is the wiki. The wiki is the slowest layer to update and the cheapest layer to query. Treating "wiki by default" is the right starting position; demoting a fact to long-term memory when it proves transient is easier than promoting a long-term note to the wiki when the agent's behavior starts depending on it.

Failure modes the memory system has to defend against

Memory fails in patterns that repeat across workspaces. Triadive catalogues seven. They are listed here in order of cost.

  • Silent contradiction. Two notes say opposite things; the agent uses whichever it retrieves first. Detection requires review; the wiki is the only layer where review is cheap.
  • Stale canonicality. A fact changed but the page that records the old fact is still being linked. Fix is at the wiki layer: mark the old page superseded, link the new one.
  • Embedding drift. The semantic index returns chunks from a year-old decision because the embedding model or the chunk boundaries changed. Fix is re-indexing, with explicit decisions about what to drop.
  • Append-only long-term memory. The long-term memory file grows forever and never gets edited. Fix is a quarterly review that deletes or consolidates notes.
  • Context-window overflow. Short-term memory pushes the conversation out of the window. Fix is at intake: bound the retrieval, shorten the system prompt, summarize older turns.
  • Cross-session leakage. A fact from one session bleeds into another session that should not have it. Fix is at session boundaries: explicit intake scope, explicit persistence scope.
  • Wiki that nobody reads. A wiki exists but is not actually consulted at intake. Fix is wiring: the wiki pages have to be linked from where the agent starts reading, not buried.

These failures are not retrieval failures. They are curation failures. The fix is almost always at the curation layer — the wiki, the long-term file, the index — not at the retrieval layer.

The cost of each layer

Memory layers are not free. Each one carries a cost the operator pays in time, disk, or review effort. The right layer is the cheapest one that still does the job.

  • Short-term memory costs context window. The bill is paid every turn.
  • Long-term memory costs file maintenance. The bill is paid whenever a note needs to be edited or deleted.
  • Semantic memory costs index maintenance and retrieval time. The bill is paid at reindex and at every retrieval.
  • Wiki memory costs human review time. The bill is paid once per page, not once per session.

For a personal assistant that handles a handful of recurring tasks, short-term and long-term are usually enough. For a workspace that runs multiple agents over months, semantic becomes worth it. For a workspace that needs to stay coherent across years, the wiki is the only layer that scales.

The signal that the cost of a lower layer is rising is that the operator keeps re-explaining the same context. The signal that the cost of a higher layer is too high is that nobody is reading the wiki. Both signals are about the gap between the layer's job and the layer's actual use.

Reading order for the memory coverage on Triadive

The memory pieces on Triadive build on each other. Read in this order:

1. Memory: Short-Term, Long-Term, and Semantic — the three-layer model. Start here. 2. Why Memory Is the Hardest Part of Any Long-Running AI Workflow — the operator's-eye view. 3. Memory Design Mistakes — the four most common failure modes. 4. Why Context Explodes Without Bounding — short-term memory in stress. 5. Wiki Memory — the fourth layer and when it is worth the cost.

Read in this order, the pieces fit together. Read out of order, each piece still makes sense — but the connections become invisible.

The takeaway

Memory design is mostly about deciding which layer is responsible for which kind of fact and then defending the layers against the failure modes they each have. The layers are not a stack where the higher one replaces the lower one; they are a cake where each layer covers what the layer below it does not.

If you take one thing from this pillar, take this: when an agent system starts contradicting itself, the fix is rarely a better embedding model. The fix is almost always at the curation layer — edit the wiki, prune the long-term memory file, bound the semantic retrieval, or shrink the system prompt. The layers are cheap to build and expensive to operate. Treat the cost as real.