Skip to content
Engineering

Memory is a product decision, not a storage one

Everyone asks how much an agent remembers. The better question is what it should forget, and who gets to decide.

8 min read

Ask how an agent's memory works and you will get an infrastructure answer: embeddings, a vector store, a retrieval step. All true, and none of it explains why one agent feels like it knows you and another feels like it is taking notes on you.

The difference is not capacity. It is editorial: what gets kept, what gets surfaced, and what quietly ages out.

Remembering everything is a failure mode

An agent that retains every message will eventually recall the wrong thing at the wrong moment: a preference you changed, a project you abandoned, an offhand comment you would not want repeated. Perfect recall in a system that acts on your behalf is not a feature, it is a liability with good uptime.

The value of memory is not what it can retrieve. It is what it chooses to bring up.

Three questions worth answering first

Before tuning any retrieval, we found it more useful to settle these:

  • What is durable? Stable facts about you: how you work, what you care about, who matters.
  • What is disposable? The transactional middle of a task, which is noise a week later.
  • What is off limits? Things said in passing that should never resurface as context.

Answer those and the storage design mostly falls out of them. Skip them and you get an agent with a large, undifferentiated pile that it dips into unpredictably.

You should be able to read it

Any memory an agent keeps about you should be something you can look at, correct and delete. Not as a compliance checkbox, but because you are the only one who knows which of its conclusions about you were wrong.

We treat that as the real test. If a memory system cannot be shown to the person it is about, it is not a memory, it is a profile.

Get started

Stop reading about it, build one

Set up an agent, pick a channel, and have it working inside the app you already keep open.