Files, rows, and retrieval collections remember *work*. This lesson is about memory *about the person* — and the line between helpful and invasive runs straight through it.

Preferences are not personal data

Start with the distinction everything else hangs on:

• Preferences are choices the user asks the agent to keep for convenience: response language, bullet-style summaries, metric units, "always include sources." They are low-sensitivity, easy to state, easy to correct, and their only purpose is to save repetition.
• Sensitive personal data is information that could harm, embarrass, or expose the user if leaked or misused: health details, finances, exact location, identity documents, private relationships, credentials, or anything the user revealed while solving one problem and never asked to be kept.

Preferences want persistence. Sensitive data wants minimization — kept only when necessary, for as short as needed, under explicit agreement. Confusing the two is how products end up with a permanent profile built from throwaway remarks.

A test: if the user would be surprised to hear "we saved that forever," it was never a preference. Preferences are declared. Sensitive data is often merely mentioned.

The helpful agent that profiles you is a bug

Consider a support-style assistant. Over a month, a user mentions their medication schedule (to explain availability), their salary band (in a benefits question), and their child's school (in a scheduling request). A "smart" agent could stitch these into a profile: health, income, family — and then use it unprompted, or worse, leak it into a shared summary, a retrieved passage, or a handoff file another agent reads.

Nothing the user said was wrong to say. The failure is architectural: the agent silently turned every conversation into permanent profile memory without asking, without showing, and without a way back.

Teach this as a rule, not a vibe: a helpful agent does not silently accumulate a dossier. Memory about the user must be explicit, visible, and revocable. That is not just politeness — it is what keeps retrieval stores, handoffs, and logs from becoming accidental surveillance archives.

What explicit control looks like

A defensible user-memory design has five properties. Each one is checkable:

1. Explicit capture. The agent asks or the user opts in before a preference persists: "Want me to remember bullet-style summaries from now on?" Incidental mentions are not consent. 2. Visibility. The user can see everything stored about them in one place — a settings page, a "what you remember about me" command — stated in plain words, not embeddings or row IDs. 3. Correction. Any stored item can be fixed by the user in one step, and the fix propagates (the row updates; stale retrieved passages expire rather than lingering). 4. Deletion. Any stored item — or the whole profile — can be deleted on request, with a stated scope: what was removed, from which stores, and what traces remain (e.g., anonymized audit entries required for safety). 5. Scope. Each item carries boundaries: which product or agent may use it, for which purpose, and for how long. A preference for the writing helper is not permission for the analytics pipeline.

Behind these sits data minimization: store the smallest thing that does the job, for the shortest time, in the fewest stores. "Prefers morning briefings" instead of the full calendar. "Metric units" instead of the home address that implied it.

Worked example: two memories, two fates

A cooking assistant chats with two users:

• Ana says: "Remember I prefer metric and short ingredient lists." The agent confirms, stores two preference rows scoped to the cooking product, shows them in settings. Next session it loads them into context. Textbook user memory.
• Ben, mid-recipe, writes: "I need something soft — dental surgery yesterday, and money is tight right now." The agent helps with soft recipes and cheap ingredients *in this session*. It does not store a health flag or an income flag. When the chat ends, the run state notes "session complete" and the transcript archives under normal retention — but no preference rows are created, because none were declared or consented to.

Same session mechanics, opposite memory decisions. The difference is consent plus sensitivity, judged at capture time — not cleaned up after a leak.

Exercise: write a memory policy in plain language

Pick one product — real or imagined — with a user-facing agent.

1. Write what you will remember (2–4 preference examples) and what you will never store as memory (3+ sensitive categories for your domain). 2. State the user's powers in plain sentences: how they view, correct, and delete stored items, and the scope each item carries. 3. State one capture rule: what the agent does when the user mentions something sensitive but useful right now (use it this session; do not persist without asking).

Finish line: a half-page policy a non-technical user could read and trust — "what we remember, what we never keep, and how you stay in charge."

Verification: hand the policy plus one tricky transcript (a user mentioning health, money, or location mid-task) to someone else. Ask: "Which sentences become stored memory under this policy?" If two readers disagree, the policy is too vague — tighten the capture rule.

Common failure mode: writing the policy as legal padding ("we may collect data to improve experiences"). Name the actual items, the actual controls, the actual scope — or it is not a policy, it is a fog.

Check your understanding

• Why is an incidental mention of health or income not a preference?
• Which of the five control properties fails when memory is visible but cannot be deleted?
• Why does scope matter even between two features of the same product?

Next

You now know what may be kept and under whose authority. Lesson 34.4 turns to time: how all memory — work memory and user memory alike — stays fresh, gets forgotten on purpose, and survives handoffs between runs.