Memory Architecture Spec Template

A one-page specification of an agent memory system: types, storage, retrieval, decay, and privacy, decided before the first write. Copy it below, fill the bracketed fields, delete what you don't need.

memory-architecture-spec.md
# Memory architecture: [system name]
Date: [date] · Owner: [name]

## Memory types in scope
- [ ] Episodic (what happened): [store / not stored]
- [ ] Semantic (facts): [store / not stored]
- [ ] Procedural (how-to): [skills directory / other]
- [ ] Working (task state): [per-task files, deleted on completion]

## Storage and retrieval
| Tier | Contents | Loaded | Store |
|------|----------|--------|-------|
| Hot | [index, digest] | every session | [flat file] |
| Warm | [fact bodies] | on relevance | [files / db] |
| Cold | [archives, logs] | explicit query | [store] |

## Write rules
- Written by: [agent / hooks / humans]
- Never written: credentials, personal data, [additions]
- Every fact carries: date, source

## Decay and staleness
- Facts are treated as claims to re-verify on recall: yes
- Consolidation pass cadence: [weekly / monthly]
- Supersession over deletion for decisions: yes

## Privacy and security
- Access control: [who/what reads each tier]
- Redaction happens at: write time

## Evaluation
- Repeated-mistake count tracked via: [method]
- Staleness audit: [sample N facts per month, measure still-true rate]

Field notes

FieldWhy it matters
Write rulesThe write policy is the security boundary. Deciding what may never be written, before the first write, is the cheapest privacy control you will ever implement.
Decay and stalenessThe section most systems skip and the reason most memory systems rot. If you fill in only one section honestly, make it this one.

Go deeper