A user asks for a warmer tone once. They change a timezone for one event. A manager corrects a recommendation.
A one-time correction can quietly become a rule nobody agreed to. Should the warmer tone apply to every message now? Does the timezone change belong to one event or all of them? Who can see what was kept? Saving context is never neutral.
Remembering is an action
AI memory is often described as storage: save a preference, retain context, recall a correction.
But remembered information changes future behavior. That makes memory a form of permission.
The system isn’t merely remembering a fact. It’s deciding where that fact is allowed to act.
Scope is the core design problem
Useful memory has boundaries:
- Current interaction.
- Selected object.
- Project or workspace.
- Personal preference.
- Team standard.
- Organization policy.
- Temporary exception.
- Lasting correction.
A product that flattens these into “memory on” and “memory off” forces users to choose between repetition and overreach.
Scope should be visible at the moment a correction could persist. “Change for this incident” and “use as my default” are different commitments. Users should never discover the scope of an edit through future surprise.
Fill-in card
Memory scope
Build the scope choices, then let the person choose where each remembered value may affect future work.
- Remembered value
- what the system would keep: a preference, context, or a correction.
- Created by
- who created it.
- Could reach
- how far it could affect future work.
- User-selected scope
- the boundary the person chooses before the system uses it again.
Example
Memory scope: a tone, a timezone, a recommendation
A one-time tone request, a timezone change, and a manager’s correction can each affect later work. The product needs to let the person choose the boundary before it uses the change again.
| Remembered value | Created by | Could reach | User-selected scope |
|---|---|---|---|
| A warmer tone, asked for once | The user | Every future customer | Not known yet: Should the warmer tone apply only to this request or every future customer? |
| A timezone, changed for one event | The user | A new global default | Not known yet: Should the timezone change apply only to this event or become a global default? |
| A correction to a recommendation | A manager | The current account, the team, or the model’s broader policy | Not known yet: Should the correction affect the current account, the team, or the model’s broader policy? |
Memory needs provenance
When memory affects an output, the user should be able to see why.
A trust token—a reusable rule for how an AI state behaves—can show that the result used a project rule, team standard, personal preference, or prior correction. The user should be able to inspect the source, freshness, and owner and decide whether it applies here.
Fill-in card
Memory provenance
Show why memory affects an output, and let the user inspect it.
- Memory used
- what the trust token shows: a project rule, team standard, personal preference, or prior correction.
- Source
- where it came from.
- Freshness
- how current it is.
- Owner
- who owns it.
- Applies here
- whether it applies to this output, for the user to decide.
- Change it
- how to correct, narrow, or exclude it.
Without provenance, personalization feels uncanny. “Personalized for you” gives the user no way to diagnose a bad result.
Corrections aren’t all preferences
A user may correct an AI because:
- The current data is wrong.
- This case is exceptional.
- The user has a personal preference.
- The team rule changed.
- The agent misunderstood the job.
- The underlying policy is unsafe.
Treating every correction as a preference creates drift. Treating none of them as learning creates repetition: the fixes stay trapped in the last run. One longer meeting, formal email, or different export doesn’t establish a durable rule. Ask before promoting an exception into future behavior.
Ask or infer carefully what kind of correction occurred, and show the resulting scope.
Forgetting is part of trust
Users need ways to inspect, edit, narrow, pause, and remove remembered context.
“Forget this” should be as real as “remember this.” The product should also explain what forgetting changes. Does it remove a personal preference, delete a project rule, or only stop using the information in this workflow?
Retention and privacy are part of the permission model too.
A memory audit
For each remembered value:
0 of 8 done
