Memory — the write decision

Read these first

• The agent loop implemented from scratch
• Reranking

What you will know

• Decide what is worth writing to memory, and who decides

  Use a concrete policy boundary: durable user preference versus transient context, including consent and deletion implications.

• Compare model-decided, heuristic, and user-explicit writes by measuring precision, recall, write rate, latency, and review burden

  The same candidate facts can produce very different noise and operational costs depending on which gate admits them.

• Show a memory system writing noise

  Seed repeated prompts, contradictions, and adversarial instructions, then inspect whether the polluted record changes later behavior.

• Trace a bad memory from proposal through approval, storage, retrieval, and correction, and identify where read-only retrieval would have avoided it

  Persistent state creates invalidation, provenance, and repair work that a one-off retrieval result does not.

• Build an evaluation showing a write policy beats re-retrieval on a stated workload after accounting for storage, invalidation, and latency costs

  Memory is justified only when durable reuse produces measurable value that repeated retrieval cannot provide more simply.

Chapters

1. 1

   Durable preferences and transient states need different write rules

   A user who always wants metric units and a user who is in Berlin this week are both stating facts about themselves, but only one survives the week. This chapter draws the admission boundary along durability, evidence strength and scope, and shows why a transient fact is either skipped or written with an explicit expiry. Consent and deletion ride on the same line: whatever you persist you must be able to show and remove.

   Read chapter
2. 2

   A bad write conditions every later session; a missed one costs a re-ask

   The two error directions are not symmetric, and that asymmetry is the whole argument for conservative admission. Missing a fact costs one clarifying question; storing a wrong one silently shapes every future conversation until someone finds it. From there follows the evidence rule: 'shorter please' after one wall of text is a situational correction, not a standing preference, and promoting it is how stores fill with confident fiction.

   Read chapter
3. 3

   Model-decided, heuristic and explicit gates trade recall for precision

   Run the same conversations past three admission gates and the results separate predictably: a model asked 'is this worth remembering?' catches the most and is wrong most often, a regex-and-rules heuristic sits in the middle, and a user pressing 'remember this' is almost always right and almost always silent. You will learn what each gate misses, and why the choice is a position on precision against recall rather than a preference.

   Read chapter
4. 4

   Write rate is a cost with an error rate attached

   A gate firing on 30% of turns is not a personalisation win, it is thirty writes per hundred turns whose precision nobody has measured. This chapter turns that number into the metrics that decide it: sampled precision on written records, recall against a labelled set, added latency per turn, and the human review burden the store creates. Those numbers, not taste, are what move you to a heuristic or an explicit gate.

   Read chapter
5. 5

   Seeding a store with noise until later behaviour shifts

   Reasoning about pollution is weaker than causing it. Feed the system repeated phrasings of the same claim, a pair of direct contradictions, and an instruction planted as if it were a user fact, then open a clean session and watch what the agent now believes. The exercise separates records that merely sit in the store from records that actually reach the model and change an answer.

   Read chapter
6. 6

   The repair work a stored fact creates and a retrieval hit does not

   Follow one wrong record from the turn that proposed it, through the gate that approved it, into storage, into a retrieval that surfaced it three weeks later, and finally into whoever has to correct it. Each stop is work that a read-time retrieval result never generates, because that result dies with the request. Naming the stops is also how you answer a product manager who wants everything remembered.

   Read chapter
7. 7

   Correcting a stored fact begins with finding it from the wrong answer

   The last stop on that trace is a mechanism, not a lament. Work backwards from the answer a user complained about to the record that produced it, establish who is authorised to change it, and choose between editing in place, writing a superseding record, and deleting outright, each of which leaves a different history behind. Then account for the outputs the bad record already shaped, which no correction retracts. The full machinery of supersession and of deletion through derived copies belongs to later topics; what the write decision needs is the obligation that admitting a fact commits you to a repair path someone can actually walk.

   Read chapter
8. 8

   A fact your system of record already holds does not belong in memory

   Subscription tier, open tickets, seat count: querying these at read time is always fresher and never needs invalidating, which makes them the wrong candidates for a write policy no matter how often they come up. This chapter builds the argument that a given workload should be re-retrieval only, and then names the workload that defeats it, namely facts with no system of record, learned from the user and expensive to re-elicit.

   Read chapter
9. 9

   Memory keeps its place only by beating a re-retrieval baseline

   The evaluation that settles the question runs held-out tasks twice, once with the write policy live and once with retrieval alone, and compares task success rather than write counts or store size. Cost belongs in the same table: storage, the invalidation work from the previous chapters, and the latency memory adds to every request. Anything short of a win on that comparison is a feature waiting to be removed.

   Read chapter