Verifiable memory for agents: store less, prove more

Persistent memory looks simple until an old statement drives a new decision. Storing everything does not solve the problem: it increases noise, retrieval cost and the chance of reusing a conclusion that is no longer valid.

Useful memory must be verifiable. Every record should state where it came from, when it was observed, the scope in which it applies and what evidence can confirm or invalidate it.

What deserves to persist

A practical policy separates three classes:

• Project facts, such as test commands and architectural boundaries, linked to a file or commit.
• Decisions, with their context, rejected alternatives and review condition.
• Episodes, such as a failure and its fix, retained as history rather than a universal rule.

Intermediate discussion, untested hypotheses and transient responses should expire or remain clearly marked as unverified.

Retrieval is selection, not a dump

A sound query starts with inexpensive filters — project, topic, recency and keywords — and only uses costlier mechanisms when needed. Results should preserve provenance and explain why they were selected.

This design prevents two common mistakes: filling the context window with irrelevant memories and treating textual similarity as proof of truth.

What OmniCodex still needs

OmniCodex already contains compact-response rules and partial codebase-memory integration guidance. That is not yet validated persistent memory. The responsible next step is to define an evidence format, invalidation policies and repeatable-task tests before enabling automatic retrieval.

Reference and limits

This is an independent analysis published by MoroniGL.dev. The audit considered the free MEMORY — Self-Editing Agent Memory material from Flux Growth Agency, whose audited distribution included an MIT license. No package code or text was incorporated here; optional model services may have their own costs.