A paper argues that agent memory should not be treated as a database with CRUD operations, proposing Governed Evolving Memory (GEM) with state-level operators and a topic graph data model to address issues of integration, propagation, relevance, and adaptation.
**Is agent memory a database?** We spent a paper answering that question. The answer is no. Every AI agent you use has the same problem. ChatGPT remembers your preferences but surfaces outdated facts as current. Cursor learns your codebase but loses earlier decisions as context grows. You re-explain things the system already knows. You pay rising inference cost for the privilege. The root cause is older than LLMs. Agent memory inherits CRUD from traditional databases. Create, read, update, delete. These operate on individual records. But memory correctness is not a property of any single record. It lives in how the whole state evolves over time. CRUD breaks down in four specific ways. **#Create\_cannot\_integrate**. New facts get appended next to old ones instead of merged. **#Update\_cannot\_propagate**. Change a deadline and every dependent fact drifts out of sync. **#Delete\_cannot\_regulate\_relevance**. Memory evicts by age, so your most-used fact ages out while "discussed lunch preferences" survives. **#Read\_cannot\_adapt**. Retrieval returns a fact but never reinforces it, so frequently accessed knowledge competes with stale clutter on equal terms. Bigger context windows do not fix this. Better retrieval does not fix this. The gap is in the operations themselves. So we replaced them. Governed Evolving Memory (GEM) swaps record-level CRUD for four state-level operators. **#Ingestion** integrates new input into existing memory instead of blindly appending. **#Revision** reconciles overlapping facts and propagates changes along typed dependencies. **#Forgetting** attenuates content by relevance, not age, while keeping history recoverable. **#Retrieval** becomes a write. Every read reinforces what you access, so important facts stay prominent and stale ones fade. Six correctness conditions govern how the state evolves. We prove no CRUD-based system can satisfy them, regardless of storage model. Then we build **#MemState**, a working prototype on a property-graph engine, to show it is feasible today. At the center is a new data model: a graph of topics. Each topic is a self-contained unit holding every field of one concept, and each field keeps a full value history, so an updated deadline supersedes the old one instead of erasing it. Topics connect through typed edges. Extension edges carry real dependencies, so revision propagates only where a change actually entails one. Association edges link related topics for context without forcing propagation. Entity-grain graphs scatter one concept across many nodes; the topic graph keeps it whole and the dependencies explicit. Long-term agent memory is not a database problem. It is a new data-management workload. It deserves its own foundations.
This paper rethinks the data foundations for long-term AI agent memory, arguing that current database paradigms fall short. It introduces Governed Evolving Memory (GEM), a formalization with state-level operators and correctness conditions, and presents a prototype called MemState built on a property graph backend.
A developer reconsiders agent memory as more than storage, proposing a living graph with roles and activation fields to give past information appropriate authority and context.
The article argues that simple RAG-based agent memory systems fail in production due to issues like stale preferences, missed keywords, and prompt injection, and advocates for a layered memory architecture with active selection, deterministic fallback, governance, and testing.
A reflection on agent memory as primarily an infrastructure/data-management problem rather than an AI problem, focusing on practical complexities like permissions, scopes, and revision history.
This paper presents a systematic experimental study of agent memory systems from a data management perspective, decomposing memory into four core modules and evaluating 12 representative systems across 11 datasets, finding no single architecture dominates and highlighting cost-performance trade-offs.