AI Memory: When Archives Become an Obstacle to Intelligence

The Problematic Persistence of AI Memories

In the field of artificial intelligence, memory management is often seen as a simple issue of storage and retrieval. However, this approach can lead to unexpected malfunctions. For example, an AI assistant retained a memory with an importance score of 8/10 regarding a survey on Bun.js, a project that was never pursued. This memory remained active for six months, influencing the AI's recommendations despite its obsolescence.

This case illustrates a fundamental problem: current AI memory systems are not designed to manage the evolution of information. They merely store and retrieve data, without considering changes in context or the relevance of information over time.

Nick Lawson wrote an excellent article on TDS where he describes how he implemented an AI memory system. His storage and retrieval architecture is particularly well thought out, but it raises questions about managing memories over time. When should a memory disappear? Which memory is more reliable than another? How many overlapping memories should be combined into one?

The Limitations of Current Systems

Traditional AI memory systems operate on a two-step model: write and read. This may suffice for simple tasks but becomes problematic for applications requiring long-term reliability. A memory recorded at the beginning of a project can remain prioritized weeks later, even if the initial decision has been revised.

This lack of dynamic updating leads to situations where the AI relies on outdated data, thereby compromising the quality of decisions made. The real challenge lies in the ability to forget or update information that has become irrelevant.

What does this look like in practice? A memory you wrote during the first week remains, eight weeks later, as fresh and prioritized as the day you created it, even if the decision you made was reversed two weeks prior. The other memory, which contradicts your previous decision, has been shelved without ceremony and simply never had the time to become a priority because it did not receive enough access to rise in the queue.

Thus, without hesitation, your assistant presents a decision you have canceled. It is only on the third attempt that you finally realize your assistant has been relying on outdated information all along. The problem is not remembering; it is not knowing how to let go.

Towards a More Human-Like AI Memory

The goal is to develop an AI memory that functions more like a human brain than a database. This involves integrating mechanisms for degrading and replacing memories. For example, each memory could be associated with a decay_score that decreases over time, based on its usage.

Some memories are not very reliable from the start. Others expire after a certain period. The brain manages all of this automatically and without you having to do anything. That was my goal.

The Foundation (Promise, It's Brief)

Let's quickly set the context. Instead of encoding your memories and executing cosine similarity searches, you keep them in plain text in an SQLite database, which the LLM can consult for a concise index at each request. There is no need for an embedding process, a third-party API, or additional files. The linguistic understanding of the LLM performs the retrieval task. This seems too simple. But it actually works surprisingly well on a personal level.

My schema is based on this with lifecycle fields:

# memory_store.py
from datetime import datetime
from pathlib import Path
from contextlib import contextmanager
DB_PATH = Path("agent_memory.db")
conn = sqlite3.connect(DB_PATH)
conn.row_factory = sqlite3.Row
with _db() as conn:
    conn.execute("
    CREATE TABLE IF NOT EXISTS memories (
    id              INTEGER PRIMARY KEY AUTOINCREMENT,
    content         TEXT NOT NULL,
    summary         TEXT,
    tags            TEXT DEFAULT '[]',
    -- Lifecycle fields — this is what this article adds
    importance      REAL DEFAULT 5.0,
    confidence      REAL DEFAULT 1.0,
    access_count    INTEGER DEFAULT 0,
    decay_score     REAL DEFAULT 1.0,
    status          TEXT DEFAULT 'active',
    contradicted_by INTEGER REFERENCES memories(id),
    created_at      TEXT NOT NULL,
    last_accessed   TEXT,
    expires_at      TEXT
    ")

The interesting columns are those you do not see in a standard memory schema: confidence, decay_score, status, contradicted_by, expires_at. Each answers a question about the health of a memory that "does it exist?" cannot.

The first problem is quite simple: old memories do not clean themselves. Each memory in the database is assigned a decay_score from 0 to 1. It starts at 1.0 at the time of its creation and degrades over time, based on the last time the memory was accessed.

Memories that you continue to reference remain fresh. Meanwhile, memories that are not accessed for several months fade towards zero. Once they fall below the relevance threshold, they are archived, not deleted, because fading does not mean they were false, just less useful.

from datetime import datetime
from memory_store import _db, log_event
HALF_LIFE_DAYS = 30  # adjust this — 30 works well for conversational memory,
# push to 90+ if you are tracking long-term projects
def _decay_score(last_accessed: str | None, created_at: str, access_count: int) -> float:
    ref = last_accessed or created_at
    days_idle = (datetime.now() - datetime.fromisoformat(ref)).days
    # Standard exponential decay: e^(-ln2 * t / half_life)
    # (In practice, the score halves every HALF_LIFE_DAYS.)
    score = math.exp(-0.693 * days_idle / HALF_LIFE_DAYS)
    # Frequently accessed memories gain a small freshness bonus.
    # Cap at 1.0 — this is not meant to inflate beyond fresh.
    return min(1.0, score + min(0.3, access_count * 0.03))

Contradiction Detection

This is the part that no one builds and the one that causes the most damage when missing. Let's take this scenario: you tell the AI that you are using PostgreSQL. Then, three months later, you migrate to MySQL, briefly mentioning it in conversation.

Now, you have fourteen memories related to PostgreSQL with high importance, while your single memory regarding MySQL has low importance. So, when you ask for information about your database setup six months later, the AI confidently says "you are using PostgreSQL," and you spend ten minutes confused before realizing what is happening.

I encountered this myself. I had stopped using poetry and started using uv as a dependency manager; I mentioned it once, without triggering a high importance score, and spent a week wondering why the assistant kept suggesting poetry commands. The old memory was not false; it simply had not been replaced.

The solution: when a new memory is created, check if it contradicts something already stored and actively mark the old ones as replaced.