Memory for agents

Three memories, not one

The scratchpad is the agent’s state for the current run: the plan, the observations, what has been tried. It is discarded when the run ends and it is the only memory the loop actually needs.

The transcript is the conversation with the user. It outlives the run and grows, so it needs trimming. The long-term store is facts worth keeping across conversations: preferences, identifiers, decisions. It is retrieved, not replayed.

A support run shows the split. The scratchpad holds the current ticket, the policy passages retrieved for it, and the draft answer. The transcript holds the customer’s messages across the session. The long-term store holds the fact that this customer prefers email and has a team plan. None of those belongs in the other two, and moving one is how the run gets slower or the answer gets stranger.

Mixing them is the usual bug

Putting the whole transcript in the scratchpad makes every step expensive and buries the current observations. Putting the scratchpad in the transcript leaks internal reasoning to the user and to the next turn.

Keeping a fact only in the transcript means it disappears when the window trims. Keeping everything in the long-term store means retrieving noise forever. Each memory has a job; assign the data accordingly.

The scratchpad should be rebuilt for each run, not accumulated across runs. A cached observation from yesterday is stale evidence for today’s question, and it is exactly the kind of thing that makes an agent answer a question nobody asked. Start clean, load only what the current task needs, and let the long-term store supply the durable facts through retrieval.

Writing a memory worth keeping

memory = {
    "user_id": user,
    "fact": "prefers email over phone",
    "source": "conversation 2026-10-29",
    "confidence": 0.9,
    "expires": None,
}

store.put(key=f"{user}:contact-preference", value=memory)

Write less, retrieve better

A memory is useful in proportion to how precisely it can be found. “The user likes email” is a fact; “contact preference: email, source: conversation on 29 October, confidence 0.9” is a fact you can rank, expire and explain. The extra fields are not bureaucracy — they are what lets retrieval prefer the recent, sourced item over an old guess.

A common mistake is storing a model-written summary as if it were an observation. The summary says “the user seems to prefer email”, the store records “prefers email”, and three months later the agent states it as a settled preference. The symptom is a memory that is confidently wrong and impossible to trace. Store the source beside the claim, and treat model-written text as a claim.

Retrieval beats replay

A long-term store is only useful if you can find the right item. Replaying everything is the same as having no store; it just costs more. Retrieve by relevance to the current task, with recency and confidence as tie-breakers.

That means the store needs the same machinery as RAG: an index, a query, a cutoff. A memory system without retrieval is a log file with optimistic branding.

Forgetting is a feature

Memories expire. A preference from two years ago may be wrong; an order number from last month is noise. Store a timestamp and a confidence, and let old low-confidence items fall out of retrieval.

Users also need a way to see and delete what is remembered. That is a product requirement in most jurisdictions and a trust requirement everywhere.

Set the expiry by the kind of fact, not by a single global number. A contact preference might last a year, an order number a month, a session detail a day. A single TTL is easier to configure and almost always wrong for at least one kind of memory. Write the rule down beside the store, so the next person knows why an order number vanishes after thirty days and a preference does not.