Short answer: It is memory of specific events that happened: what occurred, when, and in what order.
Episodic memory stores concrete past interactions and outcomes, not general truths. It helps an agent recall prior sessions, decisions, and sequences. That is different from stable facts that stay true no matter when you check them.
Everything that doesn’t fit inside working memory has to live somewhere else, in some form of long-term storage, and the first real category worth naming there is episodic memory: memory of specific things that actually happened, at a particular time, in a particular sequence, rather than general facts that hold true regardless of when they’re checked. It’s a different kind of content from a stable preference or a standing fact, and it needs to be captured, retained, and retrieved a little differently as a result.
What Actually Makes a Memory “Episodic” Rather Than Just a Fact?
An episodic memory records something that occurred once, tied to a specific moment and specific surrounding circumstances. “The user contacted support on a particular day, frustrated because a delivery was late, and asked about the refund policy” is episodic: it describes an event, with a beginning, a context, and a reason it happened when it did. “The user prefers email over phone” is a different kind of thing entirely, a standing property that doesn’t belong to any particular moment and stays true independent of when it gets checked.
The distinguishing test is whether a memory is describing something that happened or something that’s simply the case. Episodic memory is fundamentally about the former: a record of an occurrence, not a description of a standing state of the world.
Why Does the Surrounding Context of an Event Matter as Much as the Event Itself?
It’s tempting to treat an episode as just a delivery vehicle for whatever fact can be extracted from it, stripping away the surrounding circumstances and keeping only the bottom line. This throws away something genuinely useful: the reasoning behind a decision, the alternatives that were tried and rejected, the specific sequence of events that led somewhere. Reducing “we tried approach A, it failed for a specific reason, so we switched to approach B” down to just “we use approach B” loses exactly the part that would answer a very reasonable future question: why not approach A, and what happens if the circumstances that ruled it out change?
This is what separates recalling a reasoning chain from recalling a conclusion. A flat fact answers “what’s true right now.” An intact episodic memory can answer a meaningfully different question: “how did we get here, and what did we already learn along the way,” which is often exactly the thing worth knowing when a similar situation comes up again.
Should Episodic Memories Be Kept Forever in Full Detail?
Not necessarily, and for reasons different from why a stale fact eventually needs correcting. A standing fact, once established, generally stays just as relevant indefinitely, right up until something changes it. A specific episode’s exact, blow-by-blow detail tends to matter most while it’s recent, and gradually matters less as time passes, except in the specific cases where reconstructing the full story is exactly what’s needed, like retracing how a mistake happened or auditing a past decision months later.
This suggests a different kind of maintenance than what a plain fact needs. Rather than being corrected or replaced, an aging episodic memory is often a good candidate for compression: keeping the gist and the key turning points while letting the exhaustive detail fade, rather than either preserving everything forever or discarding the whole thing once it’s no longer fresh. The goal isn’t permanence or deletion, it’s proportionate retention that matches how likely that level of detail is to actually matter again.
Does Episodic Memory Need a Different Retrieval Approach Than a Simple Fact Lookup?
A fact lookup is usually looking for a single, current answer to “what’s true.” Episodic recall is frequently answering a different kind of question, “what happened, and in what order,” which sometimes means pulling together several related episodes rather than finding one best match. Reconstructing how a particular decision came about might require the initial attempt, the reason it didn’t work, and the eventual resolution, three separate episodic memories that only tell the full story when considered together rather than individually.
This mirrors a pattern already covered when multiple agents each contribute a piece of a larger picture that only becomes useful once combined: episodic memory frequently needs the same kind of assembly, multiple related events retrieved and read as a connected sequence, rather than treated as isolated, independent facts competing for a single top result.
How Does Weaviate Engram Capture and Retrieve Episodic Memory?
Weaviate Engram handles this by extracting what actually happened, including the reasoning and sequence, rather than reducing an event down to a single flattened conclusion the moment it’s stored. Consider an IT incident-response assistant that needs to remember, in a future similar incident, not just that a fix eventually worked but the actual sequence that led there:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
[
{"role": "assistant", "content": "Database latency spiked at 2am. First tried restarting the connection pool, which didn't help."},
{"role": "assistant", "content": "Checked recent deploys and found a migration had added an unindexed column used in a hot query path."},
{"role": "assistant", "content": "Adding the missing index resolved the latency within minutes; restarting the pool was a red herring."},
],
user_id="ops-team",
)
Months later, when a similar latency pattern shows up, retrieving this episode brings back the full arc, not just the eventual fix, which matters because the false lead is exactly what should be skipped this time around:
results = client.memories.search(
query="Have we dealt with a similar database latency spike before, and what actually fixed it?",
user_id="ops-team",
)
What comes back isn’t just “add a missing index.” It’s the sequence: what was tried first, why it didn’t help, and what actually worked, which is considerably more useful than the bare conclusion alone, since it tells the next responder exactly which dead end to skip. That’s the practical value episodic memory adds over a flattened fact: not just knowing the answer, but knowing the path that got there, including the parts that didn’t work.
Episodic memory captures what happened, but a great deal of what an agent needs to know isn’t tied to any particular event at all, it’s simply true, generally, regardless of when or how it came up. Our next chapter, What is semantic memory?, turns to exactly that other half of long-term memory.