🤖 AI

Is Agent Memory a Database? Rethinking Data Foundations for Long-Term AI Agent Memory

This paper argues that current database paradigms are insufficient for long-term AI agent memory due to their record-level focus, and proposes "Governed Evolving Memory" (GEM) as a new state-level data management workload defined by four operators and six correctness conditions to address recurring failure modes like unregulated growth and missing semantic revision.

Original authors: Abdelghny Orogat, Essam Mansour

Published 2026-05-27

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Abdelghny Orogat, Essam Mansour

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to teach a very smart but forgetful robot assistant how to manage your life. You want it to remember your preferences, your project deadlines, and your conversations so it can help you better tomorrow than it did today.

Currently, most AI "memory" systems work like a giant, messy pile of sticky notes. Every time you tell the robot something new, it just sticks a new note on the pile. It never throws anything away, and it never updates an old note if you change your mind.

This paper argues that this "sticky note" approach is broken. The authors, Abdelghny Orogat and Essam Mansour, say: "No, AI memory shouldn't be a database of records; it should be a living, breathing state that evolves."

Here is the breakdown of their idea using simple analogies:

1. The Problem: The "Sticky Note" Disaster

The paper identifies four specific ways current AI memory fails, which they call "failure modes." Imagine your robot assistant has a stack of notes:

📉 Unregulated Growth (The Pile Gets Too Big):
- The Issue: The robot keeps adding notes without ever cleaning up. If you tell it "My meeting is at 2 PM" on Monday and "My meeting is at 3 PM" on Tuesday, it now has two notes. It doesn't know which one is the real one.
- The Result: The pile gets so huge that the robot gets confused and slows down because it has to read through thousands of redundant notes to find the answer.
🔄 Missing Semantic Revision (The "Edit" Button Doesn't Work):
- The Issue: Current systems treat memory as "append-only." If you change a deadline, the robot doesn't fix the old note; it just adds a new one saying "Deadline changed."
- The Result: When you ask, "What is the deadline?" the robot might pull up the old note from last week instead of the new one, giving you the wrong answer.
🗑️ Absence of Selective Forgetting (The "Trash Can" is Broken):
- The Issue: When the robot's memory gets full, it deletes the oldest notes first, regardless of how important they are.
- The Result: It might delete your critical project deadline (because it's a week old) but keep a note about "discussed lunch preferences" (because it's newer). It forgets what matters and remembers what doesn't.
👀 Read-Only Retrieval (The Robot Doesn't Learn from Attention):
- The Issue: When you ask the robot a question, it just looks up the answer and tells you. It doesn't "mark" that note as important.
- The Result: If you ask about your project deadline every day, the robot treats it the same as a note you asked about once six months ago. It doesn't realize you care about this topic, so it might delete it later.

2. The Solution: "Governed Evolving Memory" (GEM)

The authors propose a new way to think about memory. Instead of a database of static records, imagine memory as a living garden.

In a garden, you don't just plant seeds (add notes). You also:

Prune: Remove weeds (forgetting irrelevant things).
Graft: If a branch grows in a new direction, you tie it to the main tree (updating facts).
Water: If you water a plant often, it grows stronger (retrieving a fact makes it more "salient" or important).
Check the Soil: You have rules (policies) about how the garden grows.

They call this Governed Evolving Memory (GEM). It has four main "gardeners" (operators) instead of the standard database commands (Create, Read, Update, Delete):

Ingestion: When new info comes in, it doesn't just stick a note on the pile. It finds the right "plant" and updates it. If the deadline changed, it updates the plant's growth ring, keeping the old ring as history but showing the new date as the current truth.
Revision: If one part of the garden changes (e.g., the deadline moves), the system automatically checks connected plants (e.g., "Do we need to reschedule the team meeting?") and updates them too.
Forgetting: Instead of deleting the oldest things, the system "prunes" the least important things. If you haven't talked about "lunch preferences" in months, that plant gets smaller and hidden, but not destroyed. If you talk about "project deadlines" daily, that plant grows huge and is protected.
Retrieval: When you ask a question, the system doesn't just read the answer; it updates the memory. Asking about the deadline makes that note "glow" brighter, telling the system, "Keep this one safe!"

3. The Prototype: "MemState"

To prove this isn't just a theory, the authors built a prototype called MemState.

The Analogy: Think of it as a smart filing cabinet built on top of a standard graph database (like a map of connections).
How it works: Instead of storing single facts, it stores "Topics" (like a folder for "Website Redesign"). Inside that folder, it keeps a history of every change (who changed the deadline, when, and why).
The Rules: It has a set of rules (policies) that run automatically. For example: "If the deadline changes, automatically flag the 'Team Meeting' folder for review."
The Result: They showed that this system can actually do what the "sticky note" systems can't: it keeps the memory clean, consistent, and focused on what the user actually cares about.

4. The Big Conclusion

The paper concludes with a bold statement: AI Memory is not a database problem; it is a new type of data management workload.

Just as we invented "Stream Processing" to handle data that flows in real-time (like stock markets), we now need a new kind of engine specifically for AI Agents that can:

Evolve over time.
Forget selectively based on importance.
Update itself when you ask a question.

The authors argue that until we build a "native engine" designed specifically for this kind of living memory, AI agents will continue to get confused, forget important things, and give outdated answers. They are calling for a new era of database technology that treats memory as a dynamic state rather than a static list of records.

Technical Summary: Is Agent Memory a Database? Rethinking Data Foundations for Long-Term AI Agent Memory

1. Problem Statement

Current AI agent memory systems and database paradigms treat memory as a static storage mechanism, relying on record-level CRUD (Create, Read, Update, Delete) operations. This abstraction fails to support the requirements of long-running AI agents, which must maintain, revise, and reason over information across multiple sessions. The authors identify four recurring failure modes inherent in current "append-only" or "capacity-driven" approaches:

Unregulated Growth: New information is blindly appended, causing redundant and low-relevance entries to accumulate, crowding out useful content and increasing inference costs.
Missing Semantic Revision: Updates are stored as new records alongside outdated ones rather than being integrated. This leads to contradictions where an agent may retrieve obsolete facts (e.g., an old deadline) instead of the current state.
Absence of Selective Forgetting: Eviction is typically driven by age or capacity (FIFO) rather than relevance to the user. Critical facts may be discarded while trivial data persists.
Read-Only Retrieval: Retrieval operations return facts without updating the memory state. Consequently, frequently accessed information does not gain "salience" or protection from forgetting, competing equally with stale content.

The paper argues that these are not implementation bugs but structural limitations of treating memory as a collection of records. Correctness in long-term memory is a property of the state trajectory (how the memory evolves over time), not the correctness of individual records.

2. Methodology: Governed Evolving Memory (GEM)

The authors propose Governed Evolving Memory (GEM), a new data-management abstraction that shifts the focus from record-level operations to state-level operators.

2.1 The GEM Abstraction

Memory is formalized as a global state $M_t = (D_t, S_t, P_t)$ at time $t$ :

$D_t$ (Content): Semantic units (e.g., topics) that hold value histories and salience signals, rather than isolated records.
$S_t$ (Structure): The structural organization connecting semantic units via typed edges (e.g., "extension" edges for dependency propagation, "association" edges for context).
$P_t$ (Policies): Declarative rules $\langle \text{event}, \text{condition}, \text{action} \rangle$ that govern how the state is allowed to change.

2.2 State-Level Operators

GEM replaces CRUD with four operators that act on the global state under policy constraints:

Ingestion: Integrates new input into existing semantic units, appending value histories rather than creating duplicate records.
Revision: Reconciles overlapping units and propagates updates along typed edges (dependencies) while preserving provenance of superseded values.
Forgetting: Regulates content influence based on relevance signals (salience) rather than age. It employs a graded attenuation ladder (compression $\to$ hiding $\to$ archiving) rather than binary deletion.
Retrieval: A state-modifying operation that returns output and simultaneously updates the salience of accessed units, reinforcing important facts.

2.3 Correctness Conditions

The paper defines six correctness conditions (C1–C6) that govern the memory trajectory:

C1 (Query Soundness): Returns the most recent non-archived value.
C2 (Transition Soundness): Ensures no superseded value is returned as current after a revision.
C3 (Dependency Consistency): Updates propagate along typed edges to dependent units.
C4 (Provenance Preservation): Forgetting and revision preserve the history chain of reachable units.
C5 (Bounded Active State): Active memory size is bounded by policy-defined relevance, not just capacity.
C6 (Retrieval-Induced Adaptation): Every retrieval updates the salience of accessed units.

2.4 Structural Observations

The authors present three structural observations proving that no record-level system (regardless of storage model) can satisfy these conditions:

Retrieval: A pure-function retrieval cannot satisfy C6 (salience updates) because the state-modifying step is decoupled from the query.
Forgetting: Relevance-driven retention (C5) is unenforceable over CRUD engines if retrieval is read-only.
Ingestion/Revision: Append-only storage without semantic units cannot satisfy C2 (soundness) or C3 (dependency propagation) because the engine lacks mechanisms to select between co-existing values or traverse semantic dependencies.

3. Implementation: MemState Prototype

To validate feasibility, the authors built MemState, a prototype implemented on Kuzu, an embedded property graph engine.

Data Model: Memory is represented as a graph of "topics" (semantic units). Each topic contains fields with value histories (tuples of value, timestamp, provenance) and embeddings.
Operators:
- Ingestion: The LLM selects a host topic and appends new values to field histories.
- Revision: Detects conflicts and propagates changes along "extension" edges.
- Forgetting: Applies graded attenuation based on salience scores (rising on access, decaying on disuse).
- Retrieval: Routes queries to topics and increments salience for accessed units within the same transaction.
Policy Enforcement: Policies are evaluated against the proposed state transition ( $M_{t+1}$ ) before commit. Violating transitions are aborted, ensuring C2 (Transition Soundness) by construction.

4. Results and Findings

Feasibility: MemState demonstrates that GEM can be realized on commodity infrastructure (property graphs) by reconstructing field histories, propagation edges, and policy checks from generic primitives.
Gap Identification: The prototype reveals that while GEM is feasible, current engines are merely a "compatibility layer." They lack native support for:
- First-class bitemporal attributes for field histories.
- Schema-attached propagation semantics.
- Unified indexing for semantic similarity and temporal predicates.
- Retrieval-as-a-write primitives that unify search and salience updates.

5. Significance and Research Agenda

The paper reframes long-term agent memory not as a database problem, but as a new data-management workload defined by state trajectory correctness. The authors outline three specific research directions required to build a native engine for this workload:

A Native Engine for Governed Memory: Requires co-locating topics, histories, and embeddings on pages; unified indexing for semantic and temporal queries; and operators that treat retrieval as a write operation.
Correctness and Evaluation: Calls for "trajectory benchmarks" that measure state evolution (C2–C6) rather than just answer-level recall. It also proposes a declarative policy language for conflict resolution and constrained learned controllers.
Privacy and Multi-Tenancy: Addresses the novel challenge of "retrieval-induced information leakage," where salience updates in a shared memory instance can leak information between tenants, and the difficulty of "verifiable erasure" in an evolving state with provenance chains.

Conclusion: The paper concludes that for long-term AI agents to function reliably, memory must evolve from a passive storage layer into an active, governed data-management workload where correctness is defined by the trajectory of the state, not the integrity of individual records.