AI, usefully · 4 min read · Sep 27, 2026

AI should remember what matters—and let the rest expire

You tell an assistant, “I don’t feel like spicy food tonight.”

A week later, it rules out every spicy restaurant. It has remembered your words and misunderstood their lifespan.

Now imagine telling it, “When you explain SQL, use MySQL syntax.” That instruction should carry forward. Repeating it every time would be irritating.

Both statements describe a preference. One belongs to an evening; the other may remain useful for months. An assistant that treats them identically will either forget too much or assume too much.

A conversation contains several kinds of memory

Before saving anything, I would separate three types of information.

This distinction matters because behaviour has many possible explanations. Someone who chooses the quickest route once may have been late. Someone who declines a restaurant may dislike its location, price or reservation time rather than its cuisine.

The system should be able to say “I’m unsure” instead of turning every interaction into a personality trait.

Research on time-aware user profiles distinguishes short-lived context from longer-term preferences. Another study found that bringing irrelevant personal memories into an answer can interfere with understanding the person’s current request. Those findings support a practical design principle: remembering more is useful only when the right memory is used at the right time. Read the temporal-profiling research and the personalized-memory evaluation.

Give each memory a reason to exist

A useful memory record needs more than a sentence. It should carry a little context:

Statement: Prefers concise explanations.
Source: The person said so directly.
Scope: Explanations in this workspace.
Recorded: September 2026.
Review: Keep until corrected.

Compare that with:

Statement: Wants a quiet dinner.
Source: The current request.
Scope: Tonight’s restaurant choice.
Review: Expire after the decision.

Those labels help prevent a temporary need from becoming a permanent rule. They also distinguish what someone explicitly said from what the assistant merely inferred.

A stored memory is not the same as teaching the underlying model a new fact. In many assistant designs, it is a record retrieved and supplied as context when relevant. That is why retrieval matters: a perfectly accurate note about last month’s dinner can still make today’s answer worse.

Correction has to be easy

Preferences change. Sometimes the assistant simply gets them wrong.

If you say, “I’m open to longer explanations for technical topics,” the system should update the earlier “always concise” preference, not retain two conflicting instructions and choose whichever it happens to retrieve.

The person should be able to see what has been saved, correct its wording and remove it. An assistant could also ask before saving an uncertain inference:

“You’ve chosen a quieter place several times. Should I treat that as a general preference, or was it specific to those evenings?”

That is a better question than silently deciding the person never enjoys a lively room.

Test for useful remembering

There are two simple tests for an assistant’s memory.

First, ask whether it remembers a clear standing instruction in a relevant task. If you requested MySQL syntax, does it use MySQL when you next ask for SQL?

Second, check whether it can set aside that instruction when the current request changes: “Show me the PostgreSQL version this time.” The new, explicit request should win.

The same principle applies outside technical work. “I usually like unplanned afternoons” should help with a travel suggestion. It should not prevent the assistant from making a timed itinerary when you specifically need one.

Good memory supports a person’s next decision. It does not insist that the person remain who they were in an earlier conversation.

The point of memory is to save you from repeating yourself. It should also leave you free to change your mind.