Write policies: remembering on purpose
Lesson 5 of 5 in Memory Architectures: Engineering the Context at Scale.
Retrieval gets the research attention, but the write path determines what there is to retrieve. A production memory system is defined less by its storage engine than by its write policy: what qualifies for remembering, who vouches for each record, and how long it lives. Skip the policy and every store from lesson 4 converges on the same end state — a mixture of trivia, contradictions, personal data nobody meant to keep, and, worst of all, attacker-supplied content wearing the credibility of “memory.”
The selection bar first. A candidate fact earns a write only if it is durable (still true next month), reusable (a future session will plausibly want it), and not cheaply re-derivable (if one tool call reproduces it on demand, retrieval-on-demand is the memory). Everything that clears the bar then flows through the same pipeline: tag it, trust-check it, date it, and only then write it.
The memory write pipeline
- Candidate fact emerges
From a user statement, a tool result, or the agent’s own inference — the three sources arrive with very different trust levels.
- Durable, reusable, not re-derivable?
The selection bar. Most candidates should fail it — a memory store that accepts everything is a landfill with an API.
- Don’t write it
It still exists in the episodic log if an audit ever needs it. Not writing is the default, not the exception.
- Tag provenance
Who or what asserted it (user, operator, agent inference, which tool), when, from what source, at what trust level. Untagged facts are unaccountable beliefs.
- Source trusted?
Direct user and operator statements are trusted. Content that arrived through the agent — webpages, emails, tool output — is not, however plausible it reads.
- Quarantine, pending review
Held with untrusted provenance; promoted to trusted memory only by explicit confirmation. Untrusted content never self-promotes.
- Set expiry: TTL or review date
Volatile facts (versions, prices, states) get short TTLs; stable facts get a review date. Nothing is written as permanent.
- Write, tags attached
Retrieval can now filter and rank by trust and age — and a poisoning cleanup can chase every record back to its source.
- Retrievable — with its provenance
Two of those pipeline steps deserve unpacking, because they are the ones teams skip.
Provenance is the tag set that makes memory accountable. Every record carries who or what wrote it, when, from which source, at what trust level. Retrieval uses the tags to filter and rank — trusted-and-recent beats untrusted-and-old regardless of similarity score. Deletion uses them to be real: “forget everything derived from that conversation” is only executable if derived records point back to their source. And incident response uses them as the search key: when poisoning is suspected, provenance is how you find every tainted record instead of guessing.
Expiry is the immune system. A TTL on volatile facts keeps the store from calcifying around last quarter’s truth — and it quietly caps the blast radius of every bad write, malicious or not. A poisoned record with a 30-day TTL is a bounded incident; a permanent one is an implant that fires until someone happens to notice. “Permanent” is not a memory tier. It is a bug report scheduled for later.
Interactive flashcard deck.
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.