Memory is not idempotency. If your agent takes the same action twice because the same request hit your endpoint twice, the fix is an idempotency key. The agent doesn\u2019t need to remember; the system needs to recognize the duplicate. Memory is not a workflow state. If your agent is mid-process, the fix is a state machine that records the current step and gates the legal transitions. Memory is not transactional consistency. If two agents are about to act on the same data, the fix is database-level isolation.<\/p>\n
All three are necessary. None of them is memory. They keep individual actions correct; they don\u2019t give the agent a sense of history.<\/p>\n
What memory actually is<\/p>\n
I\u2019ve come to think of agent memory as having five capabilities that have to work together. Persistent storage is one of them, and it\u2019s the easy one. The others are where most production agents fall short.<\/p>\n
Persistence: the agent\u2019s history survives session ends, process restarts, and deployments. Solved by writing to a database.<\/p>\n
Selection: the agent decides what is worth remembering. Storing every token of every conversation forever is both expensive and counterproductive. It dilutes the signal at recall time.<\/p>\n
Compression: raw history is summarized into something useful. A two-hour conversation becomes a paragraph plus structured facts. Without compression, retrieval cost grows linearly with interaction time.<\/p>\n
Decay and forgetting: old memories matter less than recent ones, and some should be forgotten. Without decay, stale information weighs the same as fresh information, which is exactly how RAG pipelines lie to you, the topic of my last article<\/a>.<\/p>\n Contamination prevention: incorrect memories are worse than no memories. Bad facts, once stored, pollute every future decision. A real memory system flags uncertain memories, downgrades them when they are contradicted, and quarantines them when they are proven wrong.<\/p>\n Most discussions of agent memory collapse all five into the first. They argue about which database to use to store agent state, and call it solved. But persistence without selection gives you a slow agent. Without compression, an expensive one. Without decay, a confidently wrong one. Without contamination prevention, an agent that gets dumber over time. All five are necessary, and the substrate beneath determines which architectures you can build.<\/p>\n \u201cPersistence without selection gives you a slow agent. Without compression, an expensive one. Without decay, a confidently wrong one. Without contamination prevention, an agent that gets dumber over time.\u201d<\/p>\n A useful taxonomy<\/p>\n Memory has structure. Borrowing from cognitive science gives me a vocabulary for diagnosing where agent architectures fail<\/a>.<\/p>\n Working memory is the context window: current task, current turn. Fast, ephemeral. This is what most agents have today and confuse with memory in general.<\/p>\n Episodic memory is the history of specific past interactions, with rich metadata: who, what, when, and outcome.<\/p>\n Semantic memory is distilled knowledge. \u201cThis customer prefers morning flights.\u201d \u201cThe finance API returns amounts in cents.\u201d Queried by meaning, not by time.<\/p>\n Procedural memory is learned behavior: which tool sequences work better than others. Almost nobody has this in production yet. It\u2019s a topic for another article.<\/p>\n Working memory is a prompt string. Episodic memory needs structured time-series queries. Semantic memory needs vector search<\/a>. The rest of this article focuses on episodic and semantic, where the real production gap lies.<\/p>\n Why single-purpose stores fall short<\/p>\n The first thing most teams reach for is Redis. Fast, familiar, perfect for working memory. The problem is that key-value stores give you exactly one access pattern: get by key. That fails for episodic recall, which needs queries like \u201cevery successful refund I\u2019ve issued for users in this region in the last 30 days.\u201d That\u2019s a relational query, not a key lookup.<\/p>\n The second thing teams reach for is a vector database. Embed past interactions, search by similarity. Useful for semantic memory, but it falls short for episodic recall, which often needs exact predicates: a specific user, a specific time window, a specific outcome. Cosine similarity doesn\u2019t help when you need WHERE clauses. And vector stores typically can\u2019t join against your application data, which means the agent can\u2019t reason about memory in the context of who the user is.<\/p>\n Then there\u2019s contamination handling. When a memory is found to be wrong, you need to update or invalidate it. In a vector store, that\u2019s re-indexing. In a key-value store, mass cache invalidation. In a relational database with vector support, it\u2019s an UPDATE. Memory systems live or die by how reliably bad memories get cleaned up.<\/p>\n The schema, with the honest caveats<\/p>\n Here\u2019s a reference schema for a layer that handles episodic and semantic memory in a single database.<\/p>\n — Episodic memory: what happened, with outcomes A few details that the simpler schema I\u2019d have written a year ago didn\u2019t have:<\/p>\n Both summary and raw_payload columns. Compression isn\u2019t optional. The agent reads summary at recall time; raw_payload is kept for audit and re-summarization.<\/p>\n confidence and superseded_by. Memories aren\u2019t immutable. superseded_by is a soft-delete pointer for contamination. When memory A is contradicted by memory B, A points to B and is excluded from recall. The original isn\u2019t deleted; audit matters.<\/p>\n source_count and last_confirmed_at. A fact confirmed by ten interactions is more reliable than one confirmed once. A fact last confirmed two years ago should weight less than one confirmed yesterday. These feed a decay function applied at recall time, not at write time.<\/p>\n The data stays; its weight changes. This is the principle running through all of the above. Memory records aren\u2019t rewritten or deleted. They\u2019re annotated, decayed, or superseded.<\/p>\n Recall queries that reflect real memory behavior<\/p>\n With this schema, recall queries express harder behaviors than \u201cfind similar things.\u201d This includes measures such as similarity weighted by recency and confidence, while excluding contaminated memories.<\/p>\n — Semantic recall with decay and contamination filtering The decay term EXP(-days\/90) is a half-life of about 60 days. Customer preferences decay slowly. Inventory facts decay quickly. A real memory system tunes this per memory type.<\/p>\n These queries are doing real memory work. They\u2019re not just retrieving rows. They\u2019re modeling how confidence decays, how contamination propagates, how recency interacts with relevance. The database is the substrate. The intelligence lives in the query, not the row.<\/p>\n Updating memory: optimistic and pessimistic patterns<\/p>\n Memory isn\u2019t write-once. Confidence updates as new evidence arrives. Memories get superseded. These updates can occur concurrently, so we need to be deliberate about concurrency control. Two patterns are common, and the difference matters because they\u2019re often conflated.<\/p>\n Pessimistic locking takes the lock first and holds it for the duration of the operation. Use this when contention is expected, and the operation is short:<\/p>\n — Pessimistic: lock the row, then update SELECT confidence, source_count — Application computes new confidence<\/p>\n UPDATE semantic_memory COMMIT;<\/p>\n Optimistic concurrency control takes a different approach. No lock at read time; instead, you record the version of the row you read, and at write time you assert the version hasn\u2019t changed. If it has, the update fails and the application retries. Use this when contention is rare and readers vastly outnumber writers:<\/p>\n — Optimistic: read with version, write conditionally<\/p>\n SELECT confidence, source_count, version UPDATE semantic_memory — If 0 rows affected, another transaction won the race; retry.<\/p>\n Both are valid. Memory updates from human reviewers (low-frequency, high-care) fit pessimistic locking. Memory updates from background summarization jobs across millions of records (high frequency, low contention) fit optimistic concurrency. Mixing them carelessly within a single transaction (FOR UPDATE plus a version check on the same row you just locked) does redundant work and signals confusion about which model you\u2019re committing to.<\/p>\n The point isn\u2019t which to use. It\u2019s that the database supports both, that they\u2019re both ACID-correct, and that the agent doesn\u2019t implement either in application code.<\/p>\n State persistence is not memory, but memory needs it<\/p>\n Let me close with a distinction that matters more than most architecture discussions acknowledge.<\/p>\n What I\u2019ve described in most of this article is a state-and-knowledge persistence layer. It\u2019s the substrate. By itself, it\u2019s not memory in the full sense. Memory is what happens when an intelligent system uses that substrate well: choosing what to remember, summarizing what to keep, weighing old against new, recognizing when something it believed was wrong, and bringing the right recollection to the right moment. The substrate doesn\u2019t do those things. The agent does. But the agent can\u2019t do those things without a substrate that supports them.<\/p>\n \u201cThe substrate doesn\u2019t do those things. The agent does. But the agent can\u2019t do those things without a substrate that supports them.\u201d<\/p>\n The question I\u2019d ask any team building production agents is not \u201cwhich vector database\u201d or \u201cshould we use Redis.\u201d It\u2019s whether the substrate underneath your agent supports the full set of memory behaviors you\u2019ll need within twelve months. Persistence, yes. But also: structured queries against episodic history. Vector recall over compressed summaries. Confidence decay computed at read time. Contamination invalidation as a first-class operation. Both pessimistic and optimistic concurrency. Horizontal scale as the agent<\/a> fleet grows.<\/p>\n This is what we\u2019ve been thinking about as we\u2019ve evolved TiDB<\/a> to support agent workloads. Not \u201ca vector database that also does SQL,\u201d and not \u201ca relational database with vectors bolted on.\u201d But a substrate that handles all the storage patterns a real memory system needs, with the consistency and scale properties of distributed SQL. The schema is the easy part. The patterns the substrate enables are where the agent\u2019s actual memory lives.<\/p>\n The workload is new. The discipline is older than that.<\/p>\n
\nCREATE TABLE episodic_memory (
\n id BIGINT PRIMARY KEY AUTO_INCREMENT,
\n agent_id VARCHAR(64) NOT NULL,
\n user_id BIGINT NOT NULL,
\n session_id BIGINT NOT NULL,
\n action_type VARCHAR(100) NOT NULL,
\n summary TEXT, — compressed form
\n raw_payload JSON, — full detail, kept for audit
\n outcome ENUM(‘success’,’failure’,’pending’),
\n confidence FLOAT DEFAULT 1.0,
\n superseded_by BIGINT NULL, — contamination invalidation
\n created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
\n embedding VECTOR(1536),
\n INDEX idx_agent_user_time (agent_id, user_id, created_at),
\n INDEX idx_embedding USING HNSW (embedding)
\n);
\n— Semantic memory: distilled knowledge, with decay metadata
\nCREATE TABLE semantic_memory (
\n id BIGINT PRIMARY KEY AUTO_INCREMENT,
\n agent_id VARCHAR(64) NOT NULL,
\n user_id BIGINT,
\n fact TEXT NOT NULL,
\n confidence FLOAT DEFAULT 1.0,
\n source_count INT DEFAULT 1,
\n last_confirmed_at DATETIME NOT NULL,
\n contradicted_at DATETIME NULL,
\n created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
\n embedding VECTOR(1536),
\n INDEX idx_embedding USING HNSW (embedding)
\n);<\/p>\n
\nSELECT fact,
\n confidence
\n * EXP(-DATEDIFF(NOW(), last_confirmed_at) \/ 90.0) AS effective_weight,
\n VEC_COSINE_DISTANCE(embedding, @task_vec) AS distance
\nFROM semantic_memory
\nWHERE (user_id = @user_id OR user_id IS NULL)
\n AND contradicted_at IS NULL
\n AND VEC_COSINE_DISTANCE(embedding, @task_vec) < 0.30
\nORDER BY distance, effective_weight DESC
\nLIMIT 10;<\/p>\n
\nBEGIN;<\/p>\n
\nFROM semantic_memory
\nWHERE id = @memory_id
\nFOR UPDATE;<\/p>\n
\nSET confidence = @new_confidence,
\n source_count = source_count + 1,
\n last_confirmed_at = NOW()
\nWHERE id = @memory_id;<\/p>\n
\nFROM semantic_memory
\nWHERE id = @memory_id;<\/p>\n
\nSET confidence = @new_confidence,
\n source_count = source_count + 1,
\n last_confirmed_at = NOW(),
\n version = version + 1
\nWHERE id = @memory_id
\n AND version = @read_version;<\/p>\n
![](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/05\/00b4347d-cropped-44729a2f-ed-huang.png\"\/)
<\/p>\n