The Memory Safety Model
The Memory Safety Model judges an agent memory system on six axes: relevance (recall helps the current task), freshness (facts are dated and re-verified), privacy (sensitive data is excluded by write rules), retrievability (the right memory surfaces when needed), editability (wrong memories can be corrected), and failure handling (bad recall degrades gracefully).
Key takeaways
- Memory safety for agents is distinct from the systems-programming term: it's about memories helping rather than harming.
- Freshness is the axis most systems fail: undated facts recalled verbatim convert one bad write into a permanent error.
- Privacy is a write-time property: redaction at read time is already too late.
- Editability separates memory from folklore: if nobody can correct a wrong memory, the system launders errors.
- Every Agentiquette memory-pattern page carries a mandatory privacy section and an assessment against this model.
The model
An agent memory system is safe when its memories help rather than harm. That property decomposes into six assessable axes. (The name deliberately echoes systems programming, but the concern is different: not pointers and buffers, but information quality over time.)
| Axis | Question | Characteristic failure when weak |
|---|---|---|
| Relevance | Does recall serve the current task? | Context stuffed with noise; the useful fact buried |
| Freshness | Are facts dated and re-verified? | Stale facts trusted; one change invalidates silently |
| Privacy | Is sensitive data excluded at write time? | Secrets and personal data recalled promiscuously |
| Retrievability | Does the right memory surface when needed? | The system knows, but not when it matters |
| Editability | Can wrong memories be corrected? | Errors laundered into permanent folklore |
| Failure handling | Does bad recall degrade gracefully? | One poisoned fact cascades through sessions |
Reading the axes
Freshness is the axis most systems fail. A fact is a photograph of a moment: "the staging DB is Postgres 16 at db-staging:5432" was true when written and becomes a trap the day after the migration. The defenses are mechanical: date every fact, treat recalled facts as claims to re-verify rather than truths to trust, and run consolidation passes that prune what no longer holds.
Privacy is a write-time property. Once a secret is in the store, every downstream control is remedial. The write policy is the security boundary: enumerate what may never be written (credentials, personal data, anything under NDA), and enforce it where writes happen. Redaction at read time is already too late.
Editability separates memory from folklore. If correcting a wrong memory is harder than adding a new one, wrong memories win by default. Deletion and correction must be first-class operations, as cheap as appending, and (for governance-grade systems) logged.
Failure handling is the composite test. Assume one fact in the store is wrong. What is the blast radius? Systems that re-verify on recall contain it to one check; systems that load memory verbatim into context propagate it into every decision that session makes.
Applying it
Audit an existing system by sampling: pull twenty random memories and ask, for each, is it dated, is it still true, should it have been written at all, could you correct it in under a minute? The sample rate of stale, unauthorized, or uncorrectable entries is your risk number.
Every memory-pattern page in the Patterns Library carries an assessment against this model and a mandatory privacy section. As a worked example, indexed fact files: strong on editability and relevance (files are grep-able, one fact each), freshness only as good as its consolidation discipline, privacy dependent entirely on write rules, and failure handling strong if recall is treated as re-verification. That "if" is the pattern's whole risk profile.
Design rule of thumb: date everything, write-gate secrets, make deletion cheap, and assume every fact will eventually be wrong, because it will.
Frequently asked questions
What is memory safety for AI agents?
The property that an agent's memory helps rather than harms, judged on six axes: relevance, freshness, privacy, retrievability, editability, failure handling.
What is memory poisoning?
A wrong or malicious write that later recalls as trusted fact. Defenses are dated facts, re-verification on recall, editable stores, and write rules that constrain sources.
How is this different from classic memory safety?
The systems-programming term is about pointers and buffers. Agent memory safety is about information quality over time: staleness, poisoning, leakage, and unbounded growth.
Summary
- Topic
- The Memory Safety Model
- Definition
- Six axes for agent memory quality: relevance, freshness, privacy, retrievability, editability, failure handling
- Best used for
- Designing or auditing an agent memory system
- Related concepts
- agent memory, semantic memory, audit log
- Common mistakes
- Undated facts, read-time redaction, unbounded growth, no correction path
- Recommendation
- Date every fact, write-gate sensitive data, make deletion as easy as addition