Memory that forgets on purpose

Agents that remembered too much

Our first memory system was simple: save everything the agent learned, and retrieve whatever looked relevant later. Within three months, it was the source of more bad decisions than any other component. An agent would recall that a customer preferred email, from a ticket two years old, and ignore the phone number they had given that morning. Another kept applying a discount code that had expired in March.

The problem was not retrieval quality. Old facts were retrieved accurately. They were just no longer true.

Three layers, three lifetimes

We rebuilt memory around a simple idea: every fact should have an expected lifetime, and the system should treat it accordingly.

• Working memory holds what the agent needs for the current task: the request, recent tool results and the plan. It is small, capped at about 8,000 tokens, and cleared when the task ends.
• Long-term memory holds facts that rarely change and are expensive to rediscover: account structure, documented policies, a customer’s legal entity name. It is searchable and versioned, and every entry points back to its source.
• Session memory sits in between. It holds facts that are useful for a while and then go stale: a stated preference, an open dispute, a temporary hold. Every entry here has an expiry date.

Forgetting is a feature. The question is not what to remember, but how long each thing deserves to be believed.

Choosing the expiry

Expiry dates are set by fact type, not by the agent. We started with a short table and adjust it from evidence.

1. Contact preferences: 30 days, refreshed whenever the customer confirms them.
2. Open issues and disputes: until the linked ticket closes, plus 7 days.
3. Prices, balances and availability: never stored. The agent fetches them from Payly or Bookwise every time.
4. Inferred facts, such as “seems to prefer short replies”: 14 days, and never used to make a decision on their own.

That third rule removed a whole class of bugs. If a fact can change between two steps, it does not belong in memory at all.

Writing to memory

Agents propose memory writes; they do not make them directly. Each proposal includes the fact, the type and the source. A small validator checks the type against the expiry table and rejects anything with no source. About 30% of proposals are rejected, mostly inferences dressed as facts.

What changed

Six weeks after the rebuild, decisions traced to stale memory fell from 4.1% of runs to 0.3%. Retrieval latency dropped by 40% because the long-term store shrank by more than half. And when an agent did act on old information, the trace showed exactly which entry it used and when that entry was due to expire.

Memory is one of the places agents feel most human, which makes it tempting to keep everything. We now treat it more like a cache with opinions. For more on how traces surface these decisions, see traces you can actually read.