What should your assistant remember about a customer?

The thing it remembered was true in March

Here's a composite. In March, a customer of a small homewares shop asks the support assistant to send an order to her office because she won't be home that week. The assistant, which has a memory feature switched on, stores a note: "prefers delivery to office address."

In November she orders a gift. The assistant helpfully suggests the office address. She clicks yes without reading closely. Her office has since moved. The parcel goes back to the warehouse, and she writes in, confused about why the shop thought she wanted it sent there at all.

Nobody did anything wrong, exactly. The assistant remembered something true. It just didn't know it was only true for one week. Remembering is a promise to be right later. Most assistants make it without noticing.

Memory is now a standard feature in assistant tools and agent platforms, and it's often on by default. Before yours starts building a file on every customer, run each kind of memory through four questions. If it fails any of them, don't store it. Ask again next time.

1. Did the customer say it, or did the model guess?

There's a difference between "I'm vegetarian" and an assistant noticing that someone ordered two vegetarian meals and concluding they're vegetarian. The first is a statement. The second is an inference, and inferences are where memory goes wrong.

Stated facts can still be wrong or out of date, but at least the customer can recognize them. Inferred facts can be wrong in ways that feel personal. The assistant decides someone is on a budget, or has a baby, or is shopping for a sick relative, and starts acting on it.

Inferences also compound. A guess stored in spring becomes the starting point for the next guess in summer. By winter, the assistant is confidently acting on a picture of the customer that nobody, including the customer, ever confirmed. And because it was never said out loud, there's nothing for a person to check it against.

A simple rule works well. Store only what the customer said directly, and store it in their words, with the date. If the system wants to use an inference, it should ask instead: "Would you like this sent to the office again?"

2. Would they expect you to remember it?

Think about a good shop assistant who sees a regular customer. Remembering their name and their usual size is welcome. Remembering what they said about their divorce while choosing a gift is not, even if they said it out loud.

Some categories should almost never be stored by default: health, money troubles, family situations, anything a customer mentioned to explain why they needed help. They said it to get through one conversation. They didn't ask you to keep it. Many privacy rules also treat some of these categories more strictly, which is one more reason to leave them out.

The test is easy to run with real transcripts. Read twenty conversations and, for each thing the assistant would store, ask whether the customer would be pleased or uneasy to see it brought up next time. If you hesitate, they'd be uneasy.

3. When does it stop being true?

Every memory should come with an expiry, even a rough one. Delivery preferences change with jobs and homes. Sizes change. Dietary choices change. A temporary instruction, like "send it to the office this week," should expire when the week does.

Some things barely expire, such as a name or a preferred language. Others last a season. Some last a single order. A useful habit is to store the reason alongside the memory. "Office address, because she said she'd be away the week of March 9" is far easier to retire than "prefers office delivery." The reason carries its own expiry date, and anyone reading it later can tell whether it still applies.

Sort the kinds of memory you allow into those three groups. Then make the system either forget on schedule or ask the customer to confirm before using something old.

This is the same discipline as deciding when to delete a record before you store it. It's just applied to a different kind of record.

4. Can the customer and your staff see it, fix it and delete it?

If an assistant is going to act on what it remembers, the customer should be able to see what that is. A short "What we remember" page in their account, with an edit and a delete button, does more for trust than any privacy policy paragraph.

Your staff need the same view. When a customer says "why did it suggest that?", support should be able to see the stored memory, where it came from and when, and remove it. If they can't, every complaint about memory turns into a ticket to the engineering team.

Also ask who else can read it. Memory stored in a shared workspace may be visible to more people, and more tools, than you intended. We've written about assistants finding the folder everyone forgot was shared. The same thing happens with memory.

Put this into practice

List the things your assistant currently remembers, or would if you turned memory on. Most tools let you export or view stored memories. If yours doesn't, that's an answer in itself.

Run each kind of memory through the four questions. Keep the ones that pass, each with an expiry. Turn the inferences into questions the assistant asks. Delete the sensitive categories. Add a page where customers can see and change what's kept, and give support the same view.

Then test it the way a customer would. Come back three months later, with a changed address, and see what the assistant assumes.

Finally, decide who owns this. Memory settings tend to be switched on by whoever set up the tool and then forgotten. Give one person the job of reviewing what's stored every few months, the same way someone reviews who has admin access. It's a short meeting, and it catches the slow drift before a customer does.

This is the kind of judgment we build into AI applications and agents, so they help without overstepping. If your assistant's memory is on and nobody has looked at what's in it, talk to us.

Related work: Sutton|Place.