LONG-TERM MEMORY · THREE SESSIONS LATER
Long-term memory: retain previous sessions
A user mentioned her city, diet and allergy across three sessions over 200 days. Choose what memory keeps and see what the agent knows on day 230.
Your experiment
On day 1 Priya says she lives in Pune and is vegetarian; on day 40 she mentions a peanut allergy; on day 200 she has moved to Berlin. On day 230 a new session asks for a dinner recommendation near her, which needs all three facts. The opening agent stores raw transcript chunks and retrieves the three most similar.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional sessions with fixed similarity scores. Facts are assumed to be extracted correctly; real extraction misses and invents facts. When two values conflict the agent uses the higher-ranked chunk, or for appended facts the first stored. ADK Java leaves when to write memory to your code; no memory service or model is called.
What to keep after a session ends
When a session ends, your code decides what the next session can know. Memory written as stores raw transcript chunks, extracted facts such as city = Berlin, or nothing. Chunks retrieved (top k) sets how many of the most similar chunks the new session loads. A new value for a known fact either sits next to the old one or replaces it. Retention deletes anything older than the chosen number of days. On day 230 the agent needs three facts: Berlin, vegetarian and the peanut allergy.
The opening run: the most similar is not the most current
The three chunks most similar to “recommend a dinner place near me” are a request for thali places in Pune (0.74), her introduction mentioning Pune (0.62) and her diet (0.58). The move to Berlin scores 0.55 and the allergy 0.49, so neither is retrieved. The agent recommends restaurants in a city she left a month ago and could suggest satay to someone allergic to peanuts: 1 of 3 facts right, and one wrong.
More chunks, or better memory
Raise Chunks retrieved (top k) to 5: the allergy and the Berlin chunk are now loaded, but two Pune chunks outrank one Berlin chunk, so the city is still wrong (2 of 3). At 1 chunk only Pune remains. Set Memory written as to “Extracted facts”: five small facts are stored and all are loaded, but Pune and Berlin are both live and the older one wins. Set A new value for a known fact to Supersedes the old one: Berlin replaces Pune, and all 3 facts are correct from 4 stored items.
Failure boundary: forgetting on a timer
Keep extracted, superseding facts and set Retention to 180 days: the day-1 diet and the day-40 allergy are deleted before day 230, and only Berlin remains, 1 of 3. The same happens with transcripts. Nothing gives 0 of 3. A retention limit that is right for chat transcripts is wrong for durable facts such as an allergy; facts need their own lifetime, and a safety fact should only change when the user changes it.
Reading the run and its limits
Play replays the three sessions, the day-230 recall, the answer and the outcome over sixty inspection seconds; the table lists every stored item, whether it expired and whether it was used. Next event, Restart, Speed and Inspection time control the replay. Similarities are fixed and extraction is assumed perfect; real extractors drop and invent facts, so keep the source session id with each fact and let users see and correct what is remembered.