Memory management: the agent that remembered the wrong customer

A support agent has a memory store. After every conversation it writes a few notes: what the customer asked, what they prefer, what was promised. Before every conversation it searches that store and puts the hits in the prompt. This is a common design and it works well until the store has more than one customer in it.

On Thursday Dana wrote in about a keyboard that arrived with a cracked key. The agent searched memory for "refund preference damaged item", got back "Prefers store credit over refund, confirmed 2026-09-12", and opened with "I see you prefer store credit, as before." Dana had never spoken to the company. The note belonged to Priya. The agent issued store credit. Dana wanted her money back.

The trace below is the whole run. The search at line 2 has no customer id on it.

Memory here is a vector index. You write text in, you search with text, and you get back the nearest text by meaning. Nearest by meaning is not the same as belonging to this customer. Priya's note was the closest match in the whole store for those words, so it came back, and the model treated it as a fact about Dana. The model did nothing wrong. It was handed a memory with no owner and used it.

There is a second cause. The note had no provenance. It did not say who it was about, when it was written, or what it was based on. A memory that does not carry its own scope cannot be checked at read time.

Two more things make this class of bug common. Long contexts get worse at using what is in them: Liu et al. (2023) showed that models answer best when the relevant passage sits at the start or the end of the prompt and worst when it sits in the middle, for some models below the score with no documents at all. And appending every note forever means the store grows, the searches get noisier, and a wrong hit gets more likely each month.

Separate the three memories and give each one a rule.

Working memory is the prompt for this call. It holds the current message, the task, and whatever you fetched for it. It is rebuilt every call. Keep it small and keep it ordered: instructions, then the facts you retrieved, then the conversation, then the question.

Session memory is the state of this run: what has been done, what was promised, which step is next. It lives in a record outside the prompt (lesson 3.2) and gets summarised back into the prompt when the conversation gets long. Claude Code, for example, compacts the conversation when it nears the context limit and carries a summary forward (Anthropic, 2025).

Long term memory is what survives across runs. Every entry gets an owner key, a date, and a source: "customer said", "order system", "agent inferred". Every read filters by owner before it ranks by meaning. Searching across owners is a separate tool with a separate name, and the support agent does not get it. Entries expire: a preference stated once is not a fact for life, and personal data has a retention clock.

The fix for Dana's case is one argument: memory_search(q=..., owner=customer_id). The design change behind it is that the memory tool refuses a call without an owner.

Name the line, then the missing key. "Line 2. The memory search has no customer scope, so the nearest note by meaning came from another customer and the agent treated it as fact. I would key every memory by owner, filter by owner before ranking, and store the date and source with each note so it can be checked." Then, if they want more, talk about the three memories and what each one is allowed to hold.