AI News Hub Logo

AI News Hub

Your agent doesn't remember anything. Persistence isn't memory.

DEV Community
Andrew Kew

A customer support agent that forgets a user's billing conversation from two days ago isn't broken — it's just missing memory. Not persistence. Not idempotency. Memory. And they're not the same thing. That's the argument Ed Huang (CEO of PingCAP) makes in a sharp piece on The New Stack, and it's worth paying attention to. "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." Most teams conflate three things with memory that aren't: Idempotency — prevents duplicate actions. Not memory. Workflow state — tracks where a multi-step process is. Not memory. Transactional consistency — prevents race conditions. Not memory. All necessary. None of them gives an agent a sense of history. Real agent memory has five layers: Persistence — history survives restarts. Most teams have this. Selection — deciding what's worth keeping. Most don't. Compression — summarising raw history into something queryable. Decay — old memories should matter less. Without this, stale data weighs the same as fresh data. Contamination prevention — wrong memories are worse than no memories. They need to be flagged, downgraded, and quarantined. Redis is fast but only gives you one access pattern: get by key. Episodic recall needs queries like "every successful refund I've issued for users in this region in the last 30 days." That's a relational query. Vector databases are useful for semantic memory but fall short when you need exact predicates — a specific user, a specific time window, a specific outcome. Cosine similarity doesn't help when you need WHERE clauses. Huang's reference schema keeps episodic and semantic memory in the same database, with contamination and decay baked in: -- Episodic memory: what happened, with outcomes CREATE TABLE episodic_memory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, agent_id VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, summary TEXT, -- compressed form raw_payload JSON, -- full detail for audit outcome ENUM('success','failure','pending'), confidence FLOAT DEFAULT 1.0, superseded_by BIGINT NULL, -- contamination invalidation created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, embedding VECTOR(1536), INDEX idx_agent_user_time (agent_id, user_id, created_at), INDEX idx_embedding USING HNSW (embedding) ); -- Semantic memory: distilled knowledge, with decay metadata CREATE TABLE semantic_memory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, agent_id VARCHAR(64) NOT NULL, fact TEXT NOT NULL, confidence FLOAT DEFAULT 1.0, source_count INT DEFAULT 1, last_confirmed_at DATETIME NOT NULL, contradicted_at DATETIME NULL, embedding VECTOR(1536), INDEX idx_embedding USING HNSW (embedding) ); The superseded_by pointer handles contamination — wrong memories aren't deleted, they're annotated and excluded from recall. The originals stay for audit. source_count and last_confirmed_at feed a decay function applied at read time, not write time. At recall, this means queries that actually model memory behaviour: -- Semantic recall with decay and contamination filtering SELECT fact, confidence * EXP(-DATEDIFF(NOW(), last_confirmed_at) / 90.0) AS effective_weight, VEC_COSINE_DISTANCE(embedding, @task_vec) AS distance FROM semantic_memory WHERE (user_id = @user_id OR user_id IS NULL) AND contradicted_at IS NULL AND VEC_COSINE_DISTANCE(embedding, @task_vec) < 0.30 ORDER BY distance, effective_weight DESC LIMIT 10; The decay term EXP(-days/90) gives a ~60 day half-life. Customer preferences decay slowly. Inventory facts decay quickly. A real system tunes this per memory type. The substrate doesn't make an agent intelligent. But an agent can't implement real memory without a substrate that supports structured episodic queries, vector recall, confidence decay at read time, and contamination invalidation as a first-class operation. "The substrate doesn't do those things. The agent does. But the agent can't do those things without a substrate that supports them." Huang's pitch is TiDB as that substrate — distributed SQL with native vector support. The framing is vendor-backed, but the underlying diagnosis about why agent memory keeps breaking in production is worth reading regardless of what you're building on. Source: The New Stack — Ed Huang ✏️ Drafted with KewBot (AI), edited and approved by Drew.