Question bank — Memory systems for agents

False. Working memory is the active text inside the context window for the current step; conversation history on disk is episodic storage that must be retrieved into working memory to be used.

False. A bigger window delays the ceiling but doesn't remove it — it's finite, costs grow with tokens, and stuffing everything in adds retrieval noise; you still want to select what matters.

False. That's episodic — tied to a timestamp and an event. Semantic memory holds the timeless distillate, e.g. "user_123 had a billing dispute," not the specific conversation turn.

False. High similarity flags candidate redundancy, but two near-identical queries can have different outcomes; you merge/delete only when the stored value is genuinely duplicated, not just the query text.

False. Pruning stale, low-importance items reduces retrieval noise and cost, so the relevant memories rank higher and responses stay sharp — forgetting is an optimisation, not just a loss.

Partly false. Update is logically Read-then-Write on the same key, and Forget is a Write of "nothing"; they're grouped separately because their policies (dedup, decay, privacy) differ, not because they're mechanically unrelated.

False. Pure recency deletes an old-but-frequently-used fact (e.g. the user's home address) just because it's old; importance-based scoring using access count and feedback protects such items.

False. Semantic search answers "what is about this topic?"; temporal lookup answers "what happened when?" — an agent asked "what did we discuss last Tuesday?" needs time, not meaning.

False. Vector DBs excel at approximate similarity; an exact key like user_123 is better served by a key-value index. Use the right store for the query type.

Wrong return type. With $m$ the memory store, $k$ the key and $v$ the value, Write returns a new memory state $m^{\prime }$, not a value; it's Read$(m,q)$ that maps memory + query → value.

Broken logic. The closest episode is the most relevant one to retrieve, not to delete. Redundancy pruning compares stored episodes to each other, never a live query to the store.

Overflow error. That blows the budget ($\text{working}\le \text{window}-\text{prompt}-\text{output}$) and buries the relevant turn in noise; retrieve the top-$k$ (say $k=5$) relevant episodes instead.

Miscalibrated confidence. A hard rule ("Python is 0-based") deserves $1.0$; a learned preference should carry lower confidence (e.g. $0.85$) so newer contradicting evidence can override it.

Scaling error. Raw transcripts bloat storage and retrieval; each episode stores a summary + key facts + outcome so retrieval returns compact, usable context.

Wrong retrieval mode. Keyword match misses paraphrases; embedding the query and using cosine similarity catches "Is my money back?" against a "refund" episode.

Missing dedup. Blind appends leave contradictory duplicates ("Alice prefers 9am" AND "Alice prefers 2pm"); Update must merge or replace so retrieval doesn't surface stale values.

Because the layers answer different questions with different lifetimes — concretely, working holds "the search results I'm filtering right now", episodic holds "the billing chat from Day 1", and semantic holds "pandas reads CSVs". One flat store forced to serve all three would either overflow the window or drown the right item in noise (see the flow sketch above).

Cosine compares direction (meaning) and ignores vector length. In the embedding sketch, "refund" and "money back" point the same way and score high even if one text is far longer — length shouldn't change relevance.

Repeated episodes reveal timeless patterns — three separate "billing error" episodes distil into the one durable fact "user is billing-sensitive," moving event data into general knowledge and freeing episodic space.

Turns vary wildly in length; "last 5 turns" could be 200 tokens or 5000. As the budget sketch shows, only tokens count against the window, so a token budget directly respects the hard context window limit while a turn count can silently overflow.

A graph encodes relations (pandas —function_for→ CSV_reading), letting the agent hop from "pandas" to the related "import pandas as pd" fact during answer construction, which isolated key-value pairs can't express.

Each catches a different kind of value — a frequently-read address (access), a fresh appointment (recency), a user-starred note (feedback). Any single factor alone would wrongly discard items the others would save.

Retrieval returns nothing, so the agent runs on working memory alone (a clean stateless call) and seeds the stores by writing this interaction — degenerate but correct behaviour.

High access count suggests importance, but low intrinsic value and staleness (last-year weather) mean these should be pruned; importance policies weight feedback and semantic value, not access count alone, so noise doesn't survive.

The newer/higher-confidence fact should override via Update+pruning; keeping both breaks retrieval, so the system must resolve contradictions rather than store both.

Semantic similarity isn't enough — retrieval must filter by entity/user_id first, else the agent leaks or misapplies another person's context (a privacy and correctness failure).

Working memory size goes to zero or negative — the task can't fit; the agent must summarise/compress prior context or offload to episodic memory before it can proceed at all.

No. Similarity is only meaningful within one embedding space. Concretely, if the old model mapped "refund" to $[0.9,0.1]$ but the new model maps the same word to $[0.2,0.8]$, the old vector and a new query vector are in different coordinate systems, so cosine similarity returns nonsense — the store must be re-embedded.

Forget must cascade across all layers — working (drop on session end), episodic (delete by user_id), and any semantic facts derived from them — a single-layer delete leaves recoverable traces.