intermediate · Interactive lab
Memory and Context
A memory feature is a database with a friendly name. Four different decisions hide inside the word "remember", and two of them are refusals.
By the end: Tell durable memory from context, from a re-fetch, and from something that must not be stored at all.
Your challenge
Start here. This lab opens with everything remembered, which is the wrong starting point and what an agent with a memory feature does by default. Two of these must never be written to a store at all, one goes off within the conversation, and one should be fetched rather than kept — while two genuinely belong in memory and dropping them makes the agent look like it was not listening.
See it happen
What survives this turn
- This turn → What survives
- What survives → The source
- What survives → The system of record
Four decisions, one word
Everything in This turn is about to end. What survives is a store — with backups, with readers, and with no expiry of its own — and deciding what goes into it is four decisions rather than one.
Learn more
Why this pattern exists
Ask what an agent should remember and the answer sounds like a product feature. It is not: it is a retention decision, a staleness decision and a cost decision, all taken at once and usually by accident. Four things separate them. Where the item came from — a system that owns it can be asked again, and a person who said it cannot. How long it stays true — an account ID holds indefinitely, an order status holds for minutes. How sensitive it is — a memory store outlives the conversation, gets backed up, and is read by whoever can read the store. And how often it is needed, because fetching an unchanging fact on every single turn is a call and a wait that buys nothing. Seven items here, and the right answers include two different ways of saying no.
An agent is midway through a customer-service conversation, and each of these is something it could carry into the next turn. Every row shows what it is, where it came from, how long it holds and how often it is needed. Three turns later, the consequence of the decision is shown.
- Tell durable memory from context, from a re-fetch, and from something that must not be stored at all.
- Weigh how long an item stays true against the fact that memory has no expiry of its own.
- Keep what cannot be fetched again, and stop fetching what never changes.
The rule this lesson applies: Memory is not a capability, it is a store — and everything that is true of a database is true of it. Anything sensitive written there is written there for good: backed up, replicated, and readable by whoever can read the store, long after the conversation that produced it. A credential should never be in it, and personal data belongs wherever that organisation's personal data already belongs, under the retention rules that already exist, rather than in an agent's notes. The second half is staleness. Memory has no expiry of its own, so anything with a shelf life becomes a quiet lie a few turns later: the order status that was true when it was written is used as though it were true now, and nothing in the conversation says otherwise. Those are the two refusals. The two positives matter as much for whether the agent is usable at all: something the person said and no system holds must be carried, or the agent asks for it twice and looks like it was not listening; and something that never changes and is needed on every turn should be held rather than fetched each time, which is latency and quota for an answer already known.