What happens when an AI system needs to remember a fact from yesterday? It cannot keep the full conversation in active context forever. The record must be stored, organized, and retrieved later. Epistemic memory is the part of an agent’s memory system that holds what the agent believes to be true about its work and past.
The word epistemic concerns knowledge. In plain terms, epistemic memory stores facts, decisions, preferences, and verified project details. It also preserves events that may explain those facts. This gives an agent a history it can use without loading every past conversation into each new session.
Two layers of memory
A useful design separates memory into two layers.
The first layer is a daily log. It records events as they happen. A log might contain a user request, a tool action, an observation, or a decision made during a session. The record is often append-only. New entries are added, but old entries are not silently rewritten.
JSONL is one common format for such records. Each line holds one JSON object. This makes the file easy for software to read and easy to inspect as a human. It also gives the system a basic audit trail. Someone can review what was recorded and when.
Daily logs are useful, but they are not ideal as the agent’s main memory. They can grow large. They can contain repeated remarks, temporary details, and unfinished thoughts. Loading all of that into an active session would waste space and add noise.
The second layer is a durable memory file. A file such as MEMORY.md can hold a shorter set of current beliefs. These may include a project constraint, a stable user preference, or a fact confirmed during earlier work. This file is curated. It is meant to hold what remains useful after the session ends.
The two layers serve different purposes. The daily log answers, “What happened?” The durable file answers, “What do we now believe or need to remember?” Keeping them separate helps prevent a long transcript from becoming the whole memory system.
How facts move into durable memory
Active context has a limit. As a conversation grows, the system may need to compact it. Compaction means that older material is summarized or removed from the active window.
A pre-compaction memory flush creates a checkpoint before that happens. When the session approaches its context limit, the runtime gives the agent a quiet chance to save important new facts. The agent reviews the current conversation and writes durable information into its memory store.
This step matters because a summary can lose details. A compacted transcript may preserve the broad topic but omit a small constraint. It may remember that a decision happened without retaining the reason. Saving first gives the system a place to recover those details later.
The flush should not preserve everything. A useful memory system needs selection. Temporary comments, repeated instructions, and uncertain guesses may belong in the log, not in the durable file. A verified project fact or lasting preference may deserve a durable entry.
This is also where human review matters. A memory file can contain mistakes. It can preserve an old belief after the facts change. “Stored” does not mean “true.” A durable memory should carry its source, status, or date when that context affects its use.
A small example
Suppose a research assistant works on a digital collection.
During one session, the user says that a project uses a local identifier called MS-204. The assistant records the exchange in its daily log. Later, the user confirms that the identifier refers to a manuscript image set, not a catalog record.
That confirmed fact may move into durable memory:
MS-204 refers to the manuscript image set in the current project.The daily log still preserves the event. The durable file keeps the useful result. If the assistant later sees MS-204, it can connect the code to the right object without searching the entire transcript.
The example also shows why memory needs care. If the user later corrects the identifier, the durable entry must change. Otherwise, the system may retrieve an old belief and present it as current knowledge.
Finding memory with two kinds of search
Memory storage alone does not solve retrieval. The agent must also find the right record when a new question arrives.
Vector search compares the meaning of a new query with the meaning of stored text. It can find related ideas even when the wording changes. A question about “manuscript images” may retrieve a note that uses the phrase “digitized folios.”
Keyword search works differently. It looks for exact words, codes, names, and identifiers. SQLite FTS5 is one tool that supports this kind of full-text search. BM25 is a ranking method often used to order keyword matches.
Each method has a weakness. Vector search may miss a rare code or exact variable name. Keyword search may miss a useful passage written with different terms. Hybrid search combines both signals. A system can use semantic similarity for broad meaning and keyword matching for exact details.
The balance between the two methods is a design choice. It should not be treated as a universal rule. The right mix depends on the records, the queries, and the cost of retrieving a wrong memory.
Memory needs boundaries
Epistemic memory also raises a governance problem. An agent may have access to tools, files, and commands. Memory tells it what it knows, but memory alone does not control what it can do.
That control belongs to the harness around the agent. The harness sets boundaries for actions. A policy layer can inspect a proposed command before it reaches a tool. A gateway can block unsafe requests. A sandbox can limit the damage if a command behaves badly.
This creates a useful separation. The memory layer stores knowledge and history. The control layer governs action. Both matter, but they solve different problems. A correct memory does not make an unsafe tool call acceptable.
For those of us who teach database use, this distinction is familiar. A catalog record describes an item. It does not grant permission to use the item. In the same way, an agent’s memory can describe a file or a rule without giving the agent unlimited authority.
Epistemic memory is best understood as a record system with judgment built into it. Logs preserve events. Durable files preserve selected beliefs. Pre-compaction saving protects important details from disappearing. Hybrid search helps recover both meanings and exact terms.
The limits are plain. A memory store can be incomplete, stale, or wrong. A search system can retrieve a nearby record instead of the right one. A policy layer can restrict actions, but it cannot repair a false fact by itself. Good design therefore depends on clear records, careful updates, and visible boundaries.
You can now distinguish an event log from a durable fact store, explain why memory is saved before context compaction, and see why semantic and exact-term search work better together. You can also tell where memory ends and governance begins. That is the practical promise behind The Source List: one digital source worth knowing, one search tip, and one honest limitation.