Memory is not a database.

Here's the single most common architecture mistake I see in multi-agent systems, including in our own early work at GOGOGO LLC: treating an agent's memory as a database. Store every interaction. Index it. On the next turn, retrieve by similarity. Call it memory. Ship it.

It feels right because a database and a memory both 'hold things you can get back later.' But a database is built to remember perfectly and forget nothing — and that is precisely the wrong shape for a mind. A system that remembers everything equally has no memory at all; it has a log. This post is how we actually build agent memory, and why most of the work is deciding what to throw away.

What a database does that a memory must not

A database has four properties that are virtues for storage and defects for cognition. It is complete — every row you wrote is still there. It is flat — a row from a year ago is as retrievable as a row from a second ago. It is literal — it stores what happened, not what it meant. And it is queried — nothing surfaces unless you ask for it precisely.

A mind is the opposite on all four. It is lossy — most of what you experienced today is already gone, on purpose. It is graded — recent and important things are loud, old and trivial things are faint. It is interpreted — you remember the meaning of a conversation long after the words. And it is associative — memories surface unbidden because the current moment resembles them. An agent that needs to behave like it has a mind cannot get there by querying a table. The behavior you want is in the four things the database refuses to do.

The four layers we actually build

Our agent memory is not one store. It's four, each with a different lifetime and a different job.

1 · Working memory — the current run

What the agent is holding right now: the task, the last few steps, the immediate context. It is small, fast, and deliberately discarded when the run ends. Working memory is not persisted because persisting it is how you poison the next run with the noise of the last one. Most 'the agent got confused' bugs are working memory that should have been dropped and wasn't.

2 · Episodic memory — what happened

A record of specific past runs: this customer asked this, the system did that, the grade was this. Episodic memory is close to a database — but the critical part is that it decays. An episode carries a salience score; ordinary episodes fade and are pruned, surprising or high-consequence ones are kept. We don't keep every episode. We keep the ones worth learning from.

3 · Semantic memory — what it means

This is the layer teams skip, and it's the one that matters most. Semantic memory is not events — it's the distilled meaning of many events. 'This customer prefers terse answers.' 'Invoices from this vendor always need the tax field corrected.' It is produced by a background process that reads episodic memory and writes facts. Semantic memory is small, durable, and human-readable. It is what makes an agent feel like it knows you rather than like it searched you.

4 · Procedural memory — what works

The slowest, most valuable layer: learned procedure. 'For this class of task, this sequence of agents in this order produces the best grade.' Procedural memory is how a multi-agent system gets better at its job over time without a human re-tuning it. It changes rarely and only on strong evidence — it's the system's hard-won skill, not its notes.

Forgetting is the feature

Everything above has decay built in, and that is the design, not a limitation we apologize for. An agent that cannot forget has three failure modes, and we hit all three before we understood this.

1. It gets slow. Every turn retrieves against an ever-growing store. The agent that was snappy at 100 episodes is sluggish at 100,000.
2. It gets confused. Stale facts and current facts sit at equal weight. The agent cites something true six months ago and wrong today, because the database never told it the fact had aged.
3. It gets creepy. An agent that surfaces something the user mentioned once, in passing, a year ago, doesn't feel smart. It feels like surveillance. Graceful forgetting is also a courtesy.

So we score every memory for salience and we let low-salience memories die. Forgetting isn't data loss. It's the act that turns a log into a memory — and the design instinct here is the same one I wrote about in building agent worlds carefully: you are responsible for the shape of the mind you build.

“A database is judged by what it never loses. A memory is judged by what it correctly lets go. If your agent forgets nothing, you didn't give it a memory — you gave it a hoard, and a hoard gets heavier and less useful every single day.”

How to start

If your agent today has one undifferentiated vector store, don't rebuild everything. Do this in order. First, split working memory out and make sure it's discarded at end-of-run — this alone fixes a surprising number of 'confused agent' bugs. Second, add a salience score to stored episodes and a job that prunes the low end; now your store stops growing without bound. Third, add the semantic distillation pass — the background process that turns episodes into a few durable, readable facts. Procedural memory comes last, once you have grades to learn from. One layer at a time, and notice that three of the four steps are about removing things. That's not incidental. That's what memory is. More of how I think at atakanozalan.com.