Memory prompts: correct stale preferences without erasing history

Last updated: 7 Oct 202611 min read

tutorial

Memory recall is a candidate aid to the present task, not a vote against the user speaking now. When a current statement conflicts with a saved preference, first determine whether it is a one-time override or a durable correction. An explicit future-facing change should update the identified memory item through the trusted store and preserve a revision record; a temporary instruction should affect only the present work. Avoid keeping two active contradictory memories and asking the model to pick one. If the requested change is ambiguous, clarify before rewriting a durable fact. Record the new value, source turn, timestamp, and write result so later sessions can explain what changed.

Operational case

Parcel Desk remembers that U-47 wants email delivery notices. During a shipment review, U-47 says, 'Text me about this shipment only.' That instruction changes the current shipment channel but leaves the durable preference intact. A week later U-47 says, 'From now on, send delivery notices by text.' This is a durable correction. The assistant identifies the old email preference, proposes a targeted update, and checks the memory service receipt before saying the setting is saved. If the message had said only 'text me next time,' the scope would be unclear; the assistant should ask whether it means one shipment or all future notices.

Stored M-51: delivery notices by email.
Current task: text for shipment S-47 only -> no memory update.
Later direct statement: text for future delivery notices.
Update M-51 to text; retain revision and source turn.
No write receipt -> describe current task behavior, not saved future state.

Performance and operating cost

Finding an existing item by stable key is O(1) average in an indexed store; searching M loosely matched memories can be O(M). A targeted update avoids duplicate active preferences and reduces future retrieval ambiguity. Clarification adds one conversation turn but prevents a wrong durable change from affecting many later tasks. Keep revision metadata small and controlled, and make the current request's scope explicit in the final answer. A model can draft the update request; only the store response confirms that the revision exists.

Common Mistakes

Do not overwrite a durable preference because of a one-time request.
Do not leave contradictory active items for the model to reconcile later.
Do not claim a memory update succeeded without its store receipt.

Connected lessons

prompt engineering

memory lifecycle