Give every remembered interaction setting a clear contract
Do not set AI companion memory with one broad switch and hope its meaning stays obvious. Write a small contract for each interaction setting: what the item is, who supplied it, whether it applies only to this turn, one project, or future conversations, when it expires, and how to correct it. Keep preferred names separate from role, tone, notification frequency, and topic limits. Also list fields that the companion must never infer from silence or casual wording. The practical acceptance test uses a harmless marker, starts a fresh chat, and checks that only settings assigned to that scope return. This article is about predictable interaction behavior, not where data is stored or how deletion systems work.
Choose one of three scopes before saving anything
Use turn-only for a request such as “keep this answer brief.” Use project scope for a bounded activity such as planning one event across several chats. Use persistent scope only for a choice intended to return in unrelated future conversations, such as a confirmed preferred name. Display the active scope beside the input and preview where it will appear. A setting does not inherit a wider scope merely because it was repeated. OpenAI’s current Memory FAQ distinguishes ongoing memory controls from a temporary chat that neither uses nor creates memory. Product labels differ, so verify the current control rather than assuming identical behavior. If no project scope exists, use turn-only until the person explicitly chooses persistence.
Give each remembered item an object, source, correction, and expiry
“Likes concise replies” is incomplete. A usable entry says: object—reply length; value—brief; source—explicit instruction on a stated date; scope—this project; correction—editable from the answer and settings; expiry—at project close. Show the source beside any response that relies on it. OpenAI currently documents a memory summary, source indicators, and correction controls, while the NIST Privacy Framework describes granular control and reliable dialogue about data processing. Use those ideas narrowly: the person should understand why the companion acted a certain way and which control changes it. Do not convert a joke, a rejected suggestion, a late-night message, or a one-time role-play instruction into a durable preference.
Separate the preferred name from role and tone
Store a preferred form of address as its own field with pronunciation or script only when the person supplies them. Do not infer title, relationship label, gendered form, or level of familiarity from a name. Role and tone are separate controls: practical planner, playful idea partner, neutral note-taker; concise, detailed, direct, or gentle wording. Each role needs a visible scope and an off state. A project nickname should not become the account name. A playful tone in one fictional exercise should not change ordinary chats. Read back the contract before saving: “Use River in this project; keep future unrelated chats unchanged.” This makes correction precise instead of forcing a full reset whenever one word is wrong.
Declare fields that may never be inferred
Add an explicit non-inference list. Useful entries include relationships, beliefs, identity, location, availability, spending intent, and whether a repeated activity is a lasting preference. The list is not a biography; it is a rule that missing information stays missing. If a task needs one field, the companion asks a narrow optional question and accepts “leave unset.” Google PAIR notes that implicit feedback is ambiguous and recommends adjustment or reset. Apply that principle to silence, clicks, repeated prompts, and notification opens. Frequency is also explicit: never, on request, once per day, or at a chosen time. No answer must not become permission for reminders.
Set cadence, notifications, and boundary repair independently
Interaction cadence, notification permission, role, and tone should be separate toggles. Someone may want an energetic chat style without any unsolicited notification, or a weekly reminder in a neutral voice. Show channel, timing, quiet window, trigger, and stop condition before activation. When the companion crosses a boundary, offer three repairs: correct one value, reset the current project, or reset all interaction settings. Explain the exact reach and when the change takes effect. PAIR recommends communicating both scope and timing of feedback effects. A reset that changes the current screen but leaves a new chat unchanged is incomplete; label it unresolved rather than repeating the reset silently.
Verify the contract with one harmless marker
Choose a marker with no personal meaning, such as “blue bookmark.” Assign it turn-only and ask for it in the next turn; it may appear there, then must disappear in a fresh chat. Repeat with project scope: it may return inside that project but not outside. Finally set a persistent test name, open a new unrelated conversation, and confirm only that name returns. Correct the name, disable notifications, reset the role, and repeat on another device if cross-device behavior is promised. Record expected, observed, and unresolved for every surface. Remove the marker when finished. Passing means the scopes behave as declared, corrections replace old values, reset reaches its stated surfaces, and prohibited inferences remain empty; it does not certify storage security.
Common questions
Should a preferred name always be persistent?
No. A project nickname may stay inside one project; persistence requires a separate, explicit choice.
Does turning off notifications reset tone or memory?
It should not. Notifications, tone, role, and remembered items are separate controls unless the interface clearly states otherwise.
What is a safe memory-scope test?
Use a meaningless marker, test it across the declared boundary, then remove it. Do not use private or consequential information.