Indexed Fact Files
Semantic memory as flat files: one fact per file with dates and metadata, plus a one-line-per-fact index loaded every session. Fact bodies load only when relevant, keeping the context tax flat as memory grows.
When to use
Persisting project conventions, user preferences, environment facts, and hard-won gotchas across sessions without a database or vector store.
Specification
| Memory type | semantic |
|---|---|
| Storage | flat files, one fact per file, plus a one-line-per-fact index file loaded every session |
| Retrieval | index always loaded; fact bodies read on relevance |
| Update method | agent-written, with dedup-before-write and delete-on-contradiction rules |
| Decay / staleness handling | Facts carry dates; recall treats them as claims to re-verify; periodic consolidation passes merge duplicates and prune stale entries. |
| Risk level / maturity | low / established |
Privacy and safety
Facts can capture credentials or personal data if write rules don't forbid it; the write policy is the security boundary.
Failure modes
- Index bloat: every line costs context every session
- Stale facts recommending removed flags or files
- Duplicate facts drifting out of sync
Assessment
The dominant pattern in file-based agent memory, for good reason: human-inspectable, versionable, and cheap. Lives or dies on consolidation discipline; without it, the index becomes the context tax that slowly lobotomizes the agent.
Evaluation method: Repeated-mistake count across sessions; index size growth rate; staleness audit hit rate.
Benchmarks that test this
- Memory vs no-memory on a five-session simulated project (pre-registered)