AI agents
Episodic Memory and Event Histories
Store and retrieve agent experiences as scoped events with outcomes, provenance, and relevance conditions.
By the end you can
- Define episodic agent memory as an operational contract rather than a capability label
- Contrast Raw event log with Episode summary in “A support agent reused a workaround from an incident that had already been fixed”
- Trace “A retrieved success can be the wrong precedent” through a concrete execution path
- Produce “Design an episodic record” with evidence for “Retrieved episodes retain their original time, policy, and environment context”
Example
On fast-changing questions GPT-4 never exceeds 15%
Some questions have answers that expire. FreshQA is a 600-question benchmark built around exactly that. Its questions are split into never-changing, slow-changing, fast-changing and false-premise. The fast-changing slice is where a once-correct answer keeps being returned after it has stopped being correct.
Models do badly there. Across the models tested, overall accuracy ran from 0.8% to 32.0% under the strict grading that penalises hallucination, and from 0.8% to 46.4% under relaxed grading. On the fast-changing questions the strongest model collapses. The 2024 FreshLLMs paper says so on its own results: “While GPT-4 generally obtains the highest accuracy on these questions, it never exceeds 15% in both evaluation modes.”
The refusal behaviour is the other half of the picture. On those same fast-changing questions GPT-4 declined to answer 60% of the time, against ChatGPT's 16%. Read the two numbers together and the design problem is exact. A system that cannot tell whether a stored fact is still in force must choose between answering wrongly and refusing broadly. Neither is a memory policy. A record that carried its own time, policy and environment conditions would not have to choose.
- Decision at stake: Store and retrieve agent experiences as scoped events with outcomes, provenance, and relevance conditions. FreshQA's four-way split into never-changing, slow-changing, fast-changing and false-premise questions is that scoping turned into a benchmark.
- Hidden assumption: Any previously successful episode is a strong template for a similar request. On the fast-changing questions GPT-4 never exceeds 15% in either evaluation mode, and overall accuracy across the models tested bottoms out at 0.8%.
- Primary control question: A retrieved success can be the wrong precedent. Does the stored record carry the validity window that FreshQA's fast-changing category was built to expose, or only the answer?
- Evidence to collect: Retrieved episodes retain their original time, policy, and environment context. The paired measurement is the refusal rate — 60% for GPT-4 on fast-changing questions against ChatGPT's 16% — which is what a system does when it has the answer but not the conditions.
91.0% against 80.1%, from storing the critique rather than the run
Episodic memory represents particular events: a task, observation, action, result, approval, failure, or human correction. It can help agents recognize recurring situations and avoid investigating the same thing twice. Reflexion is a working instance of that contract, and it keeps the episodes outside the weights. Its 2023 abstract says how: “Reflexion agents verbally reflect on task feedback signals, then maintain their own reflective text in an episodic memory buffer to induce better decision-making in subsequent trials.”
The headline figure is 91.0% pass@1 on HumanEval Python, against 80.1% for GPT-4 and 65.8% for the prior state of the art (CodeT + GPT-3.5). The number that matters for record design is smaller and sits in an ablation. On 100 HotPotQA questions the authors separated self-reflection from plain episodic memory — the condition that simply replays the most recent trajectory. Self-reflection was worth an 8% absolute boost over replay alone. Storing the run is not the same as storing what the run means. The gap between them is measurable.
Past success is not a universal rule. Episodes need time, context, version, scope, and outcome so retrieval can distinguish precedent from obsolete accident.
Time, version, and scope are what let retrieval say no to an episode; strip them and every stored run looks equally applicable.
Case
25,000 events at AWS, 51,200 at Temporal, at least six months by law
An event history is a real data structure with real limits. AWS Step Functions stores up to 25,000 events per execution and keeps closed histories for 90 days. Temporal terminates a run once its event history passes 51,200 events. Azure Durable Functions records the same kind of append-only history and rebuilds state by replaying it. All three are episodic memory under another name.
The vendors set the ceiling. A regulator now sets the floor. The EU's AI Act requires, in Article 12(1), that “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.” Article 12(3) goes further and names the fields for the biometric systems of Annex III point 1(a): the start and end date and time of each use, the reference database checked, the input data that matched, and the identity of the natural persons who verified the results. Article 19(1) then requires providers to keep those logs for a period appropriate to the intended purpose, and of at least six months.
So the question — what does your runtime keep, and for how long — now has two answers that must be reconciled. A 90-day retention default and a six-month statutory minimum do not fit together. An execution that terminates at 51,200 events is not a lifetime record of anything. Ask both halves before you design the record.
Figure
Example
A 41% human-model gap on exactly the temporal question
Healthy retrieval shows itself in four ways, and a public benchmark now puts numbers on how hard each one is. LoCoMo is a dataset of 10 very long-term dialogues, averaging 588.2 turns, 27.2 sessions and 16,618.1 tokens each, running up to 32 sessions. Its authors open by saying what was being measured before: “Existing works on long-term open-domain dialogues focus on evaluating model responses within contexts spanning no more than five chat sessions.” Five sessions was the old horizon. LoCoMo runs to 32.
The QA benchmark on top of it carries 1,986 questions. Of those, 321 (16.1%) require temporal reasoning and 446 (22.4%) are adversarial. Long-context LLMs and RAG improved QA by 12-20% and still lagged human levels by 36% overall, and by 41% on temporal reasoning. That 41% falls on precisely the judgement that decides whether a retrieved episode is still current. On the adversarial questions long-context models scored 65% lower than the base model. That is what Signal 3 looks like when it fails: more history retrieved, worse discrimination about which of it applies.
- Signal 1: Retrieved episodes retain their original time, policy, and environment context — the property LoCoMo's 321 temporal-reasoning questions (16.1% of 1,986) exist to test, and where the human-model gap is 41%.
- Signal 2: A summary links back to raw events and verified outcomes. Across 10 dialogues averaging 588.2 turns and 16,618.1 tokens, a summary nobody can trace back to the turns beneath it is unfalsifiable by construction.
- Signal 3: Obsolete or exceptional episodes do not silently become default behavior. On LoCoMo's 446 adversarial questions (22.4%) long-context models scored 65% lower than the base model, so retrieving more history is not the same as retrieving the right history.
- Signal 4: Human corrections can be located and applied to related future tasks. Long-context LLMs and RAG improved QA by 12-20% overall and still trailed humans by 36%, so this is tested across repeated cases rather than declared once.
Visual
Of an episode's four parts, only reflection is interpretation
An episode worth storing has four parts — Episode identity, Event sequence, Outcome, and Reflection — plus the retrieval metadata that decides when it comes back. Only Reflection is an interpretation. The cleanest demonstration that these are genuinely separable is a system that separates them, then removes one to see what breaks.
That system is 25 generative agents living in a sandbox town, built by Park and colleagues in 2023, with episodic memory as a memory stream of timestamped memory objects. Retrieval is a weighted sum of three terms. Recency is an exponential decay with factor 0.995. Importance is an LLM-assigned 1-10 poignancy score. Relevance is cosine similarity to a query memory. All three weights are set to 1. That is the retrieval-metadata layer written out as arithmetic.
Reflection sits above the raw observations without replacing them: “Reflections are higher-level, more abstract thoughts generated by the agent. Because they are a type of memory, they are included alongside other observations when retrieval occurs.”
The ablation then prices each part. Rated for believability by TrueSkill, the full architecture came first at mu = 29.89, sigma = 0.72. Removing reflection dropped it to 26.88. Removing reflection and planning, to 25.64. The human crowdworker condition scored 22.95, and the baseline with no memory, planning or reflection scored 21.21 — a standardised effect size of d = 8.16 between that baseline and the full architecture (Kruskal-Wallis H(4) = 150.29, p < 0.001). Nobody should own both Reflection and Retrieval metadata. Neither is covered by the other's test.
- 1
Episode identity
A task or event with clear start, participants, and environment version.
- 2
Event sequence
Ordered observations, actions, approvals, and results.
- 3
Outcome
Verified success, partial result, failure, or unresolved state.
- 4
Reflection
A scoped interpretation kept separate from raw events.
- 5
Retrieval metadata
Time, domain, entities, policy version, and relevance features.
Key idea
Power Peg had been unused since 2003 and was still callable in 2012
Two episodes worded alike may still differ in authority, system version, user identity, or business policy. An obsolete episode is persuasive precisely because it contains a complete story. The most expensive documented case of a dormant record becoming live default behaviour sits in a regulator's own findings.
Routing code called "Power Peg" had not been used at Knight Capital since 2003. Nobody removed it. The SEC's order puts it in one sentence: “Despite the lack of use, the Power Peg functionality remained present and callable at the time of the RLP deployment.” On 16 October 2013 the SEC ordered Knight Capital Americas LLC to pay a $12,000,000 civil money penalty.
What triggered the old code was a retrieval key, not a decision. On 1 August 2012 a flag repurposed for the new Retail Liquidity Program reached it on one of eight SMARS servers. In approximately 45 minutes, 212 incoming parent orders produced 4 million executions in 154 stocks for more than 397 million shares. Knight was left with an approximately $3.5 billion net long position in 80 stocks, an approximately $3.15 billion net short position in 74 stocks, and a realised loss of $460 million.
Nine years of disuse did not make the record unreachable. Nothing in the system recorded that its validity window had closed. Filter episodes by validity conditions and retrieve the underlying evidence before copying an action. Then delete, or hard-gate, whatever no longer has a condition under which it should ever fire.
A complete story is the easiest thing to trust and the hardest thing to check, which is how a 2003 routine becomes 2012's default path in 45 minutes.
Steps
Design an episodic record
Episodic records are easiest to design for a workflow whose past incidents you can still read. The record earns its place when it makes an old run reusable without making it binding. Call up a case that worked once, and the record should still say when it happened, under which policy, and in what environment. That is what a reader needs to judge whether the outcome carries over to the task in hand.
- 1
Choose episode boundaries
Define when a task or incident begins and ends.
- 2
Preserve raw events
Store immutable observations, actions, and results with timestamps.
- 3
Add scoped summaries
Link interpretations to evidence and policy versions.
- 4
Define retrieval filters
Use entities, environment, date, authority, and task type.
- 5
Test stale precedent
Verify that changed policy or system versions suppress obsolete advice.
Keep events immutable and let readings of them change
Keep raw events immutable and interpretations revisable. This separation supports audit, improved reflection, and correction without rewriting history. In regulated systems it is not a preference. It is codified. The FDA wrote it into its electronic-records rule in 1997, and 21 CFR 11.10(e) states it in one paragraph: “Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.”
Read that as a specification for an episodic store and it gives you three clauses. The audit trail is computer-generated and time-stamped, so provenance is not something the agent narrates about itself. A change may not obscure what was previously recorded, so a revised reading is appended, never substituted. And the trail is retained at least as long as the record it describes — the clause that keeps an old episode auditable for exactly as long as it remains retrievable.
The habit worth carrying into review is caution about precedent. A retrieved success can be the wrong precedent, because the run behind it took place under conditions that may since have changed. So before an old run is reused, check two things. That its record still carries those conditions. And that they match the situation in front of you.
Let a later reading overwrite the event it came from and every review afterwards becomes an argument about memory instead of a look at the record.
Key takeaways
- Episodic memory represents particular events: a task, observation, action, result, approval, failure, or human correction. Reflexion keeps them in an episodic memory buffer rather than in the weights, and reaches 91.0% pass@1 on HumanEval Python against 80.1% for GPT-4.
- Past success is not a universal rule. On FreshQA's fast-changing questions GPT-4 never exceeds 15% in either evaluation mode, and refuses to answer them 60% of the time against ChatGPT's 16%.
- An episode needs identity — a task or event with clear start, participants, and environment version. Park and colleagues' 25 sandbox agents score retrieval on recency (decay factor 0.995), importance (a 1-10 poignancy score) and relevance, all three weighted 1.
- Ordered observations, actions, approvals, and results are the raw layer beneath any summary. Replaying the most recent trajectory alone was worth 8% less than storing a scoped self-reflection on 100 HotPotQA questions.
- Filter episodes by validity conditions and retrieve the underlying evidence before copying an action. Knight Capital's "Power Peg", unused since 2003 but still callable, produced 4 million executions in 154 stocks and a $460 million loss in approximately 45 minutes on 1 August 2012.
- Keep raw events immutable and interpretations revisable. 21 CFR 11.10(e) requires time-stamped audit trails whose changes "shall not obscure previously recorded information", and Article 19(1) of the AI Act requires high-risk AI logs to be kept for at least six months.