To make an AI remember user preferences across conversations, save each preference outside the model under a stable user ID, then load the relevant ones into the prompt at the start of every new conversation. You can build that store yourself, or use a memory layer such as supermemory, which keeps a profile for each user and returns it with one call.

Start with explicit, low-risk preferences such as a name, a language, answer length or output format. They're easy to verify, and they give you a clear test of whether the application remembers correctly.

Why does AI forget user preferences?

The model itself keeps nothing between conversations. Anthropic's Messages API is stateless, so your app sends the full conversation each time, and OpenAI describes each text generation request as independent and stateless. When a new conversation starts, the preference from last week is gone unless your application saved it and sends it back.

A longer context window doesn't change that. It holds more of one conversation and nothing of the next.

Keeping preferences current is hard even for products that do have memory. LongMemEval, a benchmark of 500 questions about long chat histories, tests knowledge updates as one of five core memory abilities, and found commercial chat assistants and long-context models showed a 30% accuracy drop when they had to remember information across sustained interactions (Wu et al., 2024).

Example: remember a preference with supermemory

Here's the whole loop with supermemory's v5 API. Each user gets a namespace, you save conversations into it, and the user's profile comes back on any later request:

import { Supermemory } from "supermemory" // npm i supermemory

const memory = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY })
const user = "user_123" // one namespace per user, derived from your own user ID

// Monday: the user mentions preferences in passing
await memory.add(user, {
  content: "user: Call me Sam, and keep answers short. I like bullet points.\nassistant: Will do, Sam.",
  id: "chat_monday",
})

// Friday, a new conversation about something else entirely
const { profile } = await memory.profile(user)
const aboutUser = profile.static.map((m) => m.memory)
// Put aboutUser in the system prompt, whatever the question is

// The user removes a preference from their settings page
const entry = profile.static.find((m) => m.memory.includes("bullet points"))
if (entry && !entry.id.startsWith("aggregated_")) {
  await memory.memories.forget(user, { ids: [entry.id] })
}

Why a profile rather than a search? A preference like a name or an answer style rarely shares words with the next question. The docs give this exact case: a request to plan a trip to Japan won't surface "call me Dhravya" through search, because it isn't relevant to the query, but the name is always in the profile (user profiles docs). Use search alongside the profile for details that depend on the question, like a decision from a particular project.

A few details from the docs worth knowing:

Memories form in the background after you save, so a brand-new namespace can look empty at first (quickstart).
Each profile entry's id is the memory's ID, so you can forget it directly. Entries whose ID starts with aggregated_ are summaries of older memories and don't map to a single one (profile API).
Forgotten memories are excluded from search but kept for audit (forget API reference).

Use a stable identity across conversations

A conversation ID identifies a thread. A user scope identifies the person or account whose context should persist between threads. Keep those roles separate.

In a multi-tenant application, resolve the tenant and user from the authenticated request. A user ID that is unique only inside one company is not enough to identify someone across the whole service.

The memory provider can apply a scope you supply, but your application must establish that the caller is allowed to use it. The isolation guide covers the read, write and cache checks involved.

Which software should store user preferences?

Use an application database for a fixed setting such as language or notification frequency. Use a memory layer when preferences come up in conversation and need source history, scope, corrections and retrieval. Keep the CRM or account system authoritative for business facts. These options work together.

For cross-channel personalization (web chat, email, a mobile app), first link the verified accounts on each channel to one stable user identity, then use that identity as the namespace everywhere. supermemory's profiles supply reusable user context, but the identity mapping is your application's job. The support-agent architecture covers ticket history and current account state in more detail.

Store the preference with enough context

"Use short answers" may be a general preference. "Keep this incident update short" may apply to one task. Don't turn every instruction into a permanent profile fact.

For each preference, keep or be able to recover:

The value and the user or workspace it applies to.
Whether it was stated explicitly or inferred.
The source conversation and time.
Its scope, such as a project or a single task.
Its current status, including replacement or deletion.

An explicit settings field may be the right answer for a small, fixed set of preferences. Use memory extraction when the useful context is broader or comes up naturally across conversations. You can combine both.

Distinguish current preferences from history

If a user says "I now prefer email," update the current preference. If they later ask which contact method they used last month, the older value may still matter, subject to your retention rules.

Event time and ingestion time can differ. Importing an old conversation today shouldn't make its preference newer than a correction received yesterday.

When a statement is ambiguous, keep the uncertainty or ask. Confidently inventing a preference is worse than asking a small clarifying question.

Retrieve only what helps the current task

A profile can supply language and communication preferences. A targeted search can supply a prior project decision or a detail from one conversation. Combine the two without sending the whole history by default.

Keep profile content separate from trusted system instructions. A remembered request doesn't override access controls or authorize an unrelated action. Saved text that changes the model's behavior is the risk OWASP lists as indirect prompt injection, LLM01 in its Top 10 for LLM applications (OWASP).

Give the user a way to correct the memory

Provide a clear route to inspect, update or remove important preferences. Show the source where it helps explain why the application believes something. A user shouldn't have to repeat a correction in five separate conversations.

Apply changes to derived context and caches as well as the visible record. Check that a delayed job or a later transcript import can't immediately recreate a preference the user removed.

Don't keep every inference forever. Choose retention and refresh rules based on what the application needs and what the user expects.

Test continuity and correction

Create two users with conflicting preferences. For user A, save "brief bullet points"; for user B, save "detailed explanations." Start fresh conversations and check that each gets the intended style without crossing over.

Then have A ask for detail on one task. Confirm that a task-specific exception doesn't overwrite the general preference unless the user meant it to. Finally, change the general preference explicitly and check that future conversations use the correction.

Include a user with no saved preference. The application should use a default or ask, not claim to remember something that was never said.

Start with a measurable behavior

The first milestone is that an explicit preference survives a new session, stays with the right user, and can be corrected or removed. Track how often users have to repeat or correct it.

The AI SDK integration guide shows one implementation path. For support-specific context such as attempted fixes and unresolved issues, use the customer support memory guide. To go beyond single preferences, the user-profile guide covers selective extraction and current goals, and the long-term memory guide covers the broader storage design. The product page explains how supermemory builds and updates profiles.

If you're configuring an existing assistant rather than building one, see Claude Code memory for repository context or Perplexity Memory for consumer settings.

How to Make AI Remember User Preferences Across Conversations