Memory systems for agents: Worked examples — AI-ML deep dive

Before any formula appears, one reminder of the two numbers everything depends on.

The scenario matrix

Every question a memory system throws at you falls into one of these cells. The worked examples below are labelled with the cell they cover.

#	Cell (case class)	What breaks / what to watch	Example
A	Fits in window (working memory, normal)	budget arithmetic, positive slack	Ex 1
B	Overflow (working memory, degenerate)	slack goes negative — must evict	Ex 2
C	Boundary (slack = exactly 0)	zero-slack: keep or drop the last turn?	Ex 3
D	High similarity retrieval (cosine near 1)	correct recall of a past episode	Ex 4
E	Orthogonal / zero similarity	unrelated query, cosine = 0, must NOT recall	Ex 5
F	Redundancy limit (cosine > 0.95)	near-duplicate → merge/delete	Ex 6
G	Forgetting: recency vs importance	two policies disagree on same episode	Ex 7
H	Word problem (support agent over days)	end-to-end episodic pickup	Ex 8
I	Exam twist (units / limiting value)	tokens-per-turn → how many turns survive; $T_{window} \to \infty$	Ex 9

Working-memory budget: cells A, B, C

We use one formula from the parent for all three: $slack = W_{ctx} - P_{sys} - B_{out} - H_{hist}$ where $W_{ctx}$ is the context-window size, $P_{sys}$ the system prompt, $B_{out}$ the reserved output buffer, and $H_{hist}$ the history we want to carry. Slack is what is left for the new user turn. Its sign is the whole story.

Worked example Ex 2 — Cell B: overflow (negative slack)

Same model, but a long transcript: $P_{sys} = 1000$ , $B_{out} = 500$ , $H_{hist} = 7000$ , new turn $600$ .

Forecast: will the raw slack be positive or negative?

Slack $= 8000 - 1000 - 500 - 7000 = - 500$ . Why this step? A negative slack means the history alone already overflows the window.
We are $500 + 600 = 1100$ tokens over once the new turn arrives. Why this step? The turn cannot even start; we must evict before writing.
Evict oldest exchanges until slack $\geq 600$ . Need to free $1100$ tokens: drop history down from $7000$ to $7000 - 1100 = 5900$ . Why this step? Sliding-window eviction removes the least recent turns first (they are least likely relevant — see the forgetting rule).

Verify: new slack $= 8000 - 1000 - 500 - 5900 = 600$ , exactly enough for the $600$ -token turn. Total $= 8000 \leq 8000$ . ✓ This is the red zone in the figure.

Retrieval by cosine: cells D, E, F

For episodic retrieval we embed the query and each stored episode, then rank by cosine. We use tiny 3-dimensional vectors so the arithmetic is visible.

Forgetting policies: cell G

Worked example Ex 7 — Cell G: recency vs importance disagree

Two policies from the parent, applied to one episode $e$ : it is old (age $45$ days, window $T_{window} = 30$ ) but frequently used and user-starred. Importance $= w_{1} \cdot AccessCount + w_{2} \cdot Recency + w_{3} \cdot Feedback$ , with $w_{1} = 0.5, w_{2} = 0.2, w_{3} = 0.3$ , and $AccessCount = 20$ (normalised to $1.0$ as the top item), $Recency = 0.1$ (old), $Feedback = 1.0$ (starred).

Forecast: recency says delete; will importance override?

Recency policy: $Keep = 1$ iff $t_{now} - t_{e} < T_{window}$ . Here $45 < 30$ is false ⇒ Keep = 0 (delete). Why this step? The sliding window sees only age; it does not know the episode is valuable.
Importance policy: score $= 0.5 \cdot 1.0 + 0.2 \cdot 0.1 + 0.3 \cdot 1.0 = 0.5 + 0.02 + 0.3 = 0.82$ . Why this step? A weighted vote lets access and feedback outweigh staleness.
With a keep-threshold of $0.5$ , $0.82 \geq 0.5$ ⇒ Keep. The two policies disagree; a production system runs importance after recency so valuable-but-old items survive. Why this step? This is the classic corner case where a naive recency prune throws away your best memory.

Verify: $0.5 + 0.02 + 0.3 = 0.82$ , and $0.82 \geq 0.5$ . Recency alone would have deleted it. ✓

Word problem end-to-end: cell H

Worked example Ex 8 — Cell H: support agent picks up across days (see

Vector Databases) Day 1 the user reports a double charge; an episode is stored with embedding $e_{1} = (0, 3, 4)$ . Day 5 the user asks "is my refund processed?" with query embedding $q = (0, 6, 8)$ . Also stored: a chit-chat episode $e_{2} = (5, 0, 0)$ . Which episode is retrieved?

Forecast: guess which of $e_{1}, e_{2}$ wins the ranking.

Cosine to $e_{1}$ : dot $= 0 \cdot 0 + 6 \cdot 3 + 8 \cdot 4 = 18 + 32 = 50$ ; lengths $∥ q ∥ = 36 + 64 = 10$ , $∥ e_{1} ∥ = 9 + 16 = 5$ ; $cos = 50/50 = 1.0$ . Why this step? Refund query is the same direction as the billing episode.
Cosine to $e_{2}$ : dot $= 0 \cdot 5 + 6 \cdot 0 + 8 \cdot 0 = 0$ ⇒ $cos = 0$ . Why this step? Chit-chat is orthogonal; it must not surface.
Rank: $1.0 > 0$ ⇒ load $e_{1}$ into working memory. Agent responds without asking the user to re-explain. Why this step? This is the whole payoff of episodic memory — continuity across sessions.

Verify: $cos (q, e_{1}) = 1.0$ , $cos (q, e_{2}) = 0.0$ , so $e_{1}$ ranks first. ✓

Exam twists: cell I (units + limiting value)

Worked example Ex 9 — Cell I: how many turns survive, and the

$T_{window} \to \infty$ limit Part (a) — units. Working memory has $6500$ tokens of slack. Each conversation turn averages $325$ tokens. How many recent turns fit?

Forecast: integer answer — round up or down?

$\frac{6500 tokens}{325 tokens/turn} = 20 turns$ . Why this step? Tokens cancel tokens, leaving pure turns — a units check.
Since a partial turn is unusable, we floor: $⌊ 20 ⌋ = 20$ turns exactly. Why this step? You cannot keep half a message; capacity is a whole-turn count.

Part (b) — limiting behaviour. In the recency policy $Keep = 1$ iff age $< T_{window}$ . What happens as $T_{window} \to \infty$ ?

As $T_{window} \to \infty$ , the condition age $< T_{window}$ is true for every episode ⇒ nothing is ever forgotten ⇒ memory grows unboundedly and cost explodes. Why this step? This is exactly the failure the parent warned about — the reason importance/redundancy pruning exists.

Verify: (a) $325 \times 20 = 6500$ tokens, exact fit. (b) limit of the keep-set is "all episodes". ✓

Recall Self-check

A history uses 7100 tokens in an 8000 window with 1000 system + 500 buffer. Fits? ::: Slack $= 8000 - 1000 - 500 - 7100 = - 600 < 0$ → overflow, must evict 600+ tokens. Two embeddings have dot product 0. Recall or skip? ::: Cosine $= 0$ , orthogonal → skip, unrelated. Cosine of new vs old episode is 0.97. Action? ::: $> 0.95$ → merge/delete the duplicate. Recency deletes an old but starred, heavily-used episode. Right call? ::: No — run importance policy; its weighted score keeps it.

Connections: Memory systems for agents · Vector Databases · LM Context Window Management · Knowledge Graphs · Prompt Engineering · Agent Planning and Reasoning · Multi-Agent Systems