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

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."

What memory actually requires

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:

1. Persistence — history survives restarts. Most teams have this.
2. Selection — deciding what's worth keeping. Most don't.
3. Compression — summarising raw history into something queryable.
4. Decay — old memories should matter less. Without this, stale data weighs the same as fresh data.
5. Contamination prevention — wrong memories are worse than no memories. They need to be flagged, downgraded, and quarantined.

Why single-purpose stores keep failing

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.

The schema that handles both

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 point

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.