An AI support agent remembers customers across conversations when every ticket, chat and call is saved under one stable customer ID, and the relevant history is loaded before the agent replies. With a memory layer such as supermemory, that means one namespace per customer: you save each interaction into it, and before each reply you load the customer's profile and search their past tickets.

Saving transcripts is the start. The harder work is telling current facts from old ones, keeping accounts isolated, and giving the agent evidence it can use without inventing a history.

Consider a customer returning about a failed integration. A useful agent knows which steps already failed, whether the issue is still open, and what the previous agent promised. It checks current account permissions and service status against their authoritative systems, not against memory.

Why do support bots forget returning customers?

The model keeps nothing between conversations. Anthropic's Messages API is stateless, so anything the agent knows about last week's ticket has to be loaded into this conversation. Long threads have the opposite problem: OpenAI's cookbook on session memory uses a multi-issue customer service chat as its example, and notes that carrying too much history distracts the model, while trimming too much makes the agent forget promises midway (OpenAI, Sep 2025).

Memory solves both by keeping the history outside the conversation and loading only what the current ticket needs.

Example: per-customer memory with supermemory

Each customer gets their own namespace, and metadata tracks ticket-level fields like channel and status. Filtering by status inside one customer's namespace can never return another customer's tickets, because a request only reaches one namespace (multi-tenancy examples).

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

const memory = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY })
const customer = "org_customer_442" // one namespace per customer

// After each interaction: save it with ticket-level metadata
await memory.add(customer, {
  content:
    "Customer reports the webhook returns 401. Rotating the signing secret did not fix it. " +
    "We promised to check their endpoint configuration.",
  id: "ticket_8812",
  metadata: { channel: "support_ticket", status: "open" },
})

// Before the next reply: a profile built only from support tickets,
// plus the open tickets that match the new message
const { profile } = await memory.profile(customer, {
  filter: { field: "channel", operator: "eq", value: "support_ticket" },
})
const openTickets = await memory.search(customer, {
  query: "Any update on the webhook issue?",
  filter: { field: "status", operator: "eq", value: "open" },
  limit: 5,
})

The profile filter keeps the customer's profile built from support tickets only, even if the same namespace also holds synced documents (user profiles docs). Two controls matter for enterprise support:

Per-customer keys. A scoped API key can be limited to one namespace, or a fixed list of them, and requests outside it get a 403 (API keys docs). Writable scoped keys can still update and delete inside their namespace, so give read-only keys to anything that only reads.
Forgetting with an audit trail. Forgetting a memory removes it from search while keeping it for audit (forget API reference). Deleting a document removes it permanently, and the memories derived from it are forgotten.

How can an AI agent remember a customer across channels?

Map authenticated channel identities to the same customer record before retrieving memory. An email thread and an in-app chat can share context once the application has verified that they belong to the same customer. Similar names or matching text aren't proof. If identity is uncertain, keep the histories separate until the customer links the accounts through a verified flow.

A CRM or help desk stays the record of ticket and account state. A memory layer adds selected interaction context to the agent's next answer. If your team also wants a summary of each conversation in the CRM, write it there too, and keep the CRM authoritative for account facts. supermemory supplies profiles and retrieval. It doesn't identify a person across channels on its own or replace the support platform. For preference-specific behavior, see remembering user preferences across conversations.

Keep three kinds of context separate

Context	Example	How to use it
Current business state	Subscription, permissions, open incident status	Fetch from the system of record when the answer depends on it
Interaction history	Error code, attempted fix, unresolved question	Retrieve relevant events with timestamps and source references
Customer preferences	Preferred language or level of technical detail	Apply a current preference within its intended scope

A shared store can hold all three if the data model and authorization rules preserve their different roles.

Follow one customer across two tickets

In ticket A, a customer reports that a webhook fails with a 401 response. Rotating the credential doesn't fix it. The agent promises to follow up after checking the endpoint configuration.

In ticket B, the customer writes, "Any update on the webhook issue?" A useful memory result contains the failed step, the unresolved status and a reference to ticket A. It doesn't claim the issue is fixed because an unrelated customer solved a similar error.

For an initial implementation, keep a compact record with:

Tenant and customer identifiers derived from the authenticated application context.
Ticket identifier and event time.
The reported problem and the actions actually attempted.
The confirmed outcome, or an explicit unresolved state.
Commitments and their status.
A source reference that a human can inspect.

Treat inferred preferences separately from explicit statements. "Sounded frustrated during an outage" shouldn't become a permanent customer trait.

Build the write and read paths

On the write path, select the parts of a conversation that are useful for future support. Record the source, and distinguish an attempted action from a completed one. Use a stable ticket ID so a retry doesn't quietly create duplicate records.

On the read path, authenticate the request, establish its allowed scope, and retrieve context for the current issue. Load a small profile when it helps, then search the relevant ticket history. Keep retrieved text separate from application instructions: a sentence in an old ticket shouldn't gain authority over the agent's tools or access controls. OWASP lists this as indirect prompt injection, where content from an outside source changes the model's behavior (OWASP LLM01:2025).

Handle corrections and stale information

If a customer changes their contact preference from phone to email, the agent should use email from now on. It may still need the earlier preference when explaining a past interaction. Keep the difference between "the current value" and "what was true at the time." Memory benchmarks test these as separate skills: LongMemEval scores knowledge updates and temporal reasoning on their own (Wu et al., 2024).

Account tier, integration configuration and product version change. Don't keep them as unquestioned facts. Attach a source and a freshness rule, or fetch them live when needed.

For temporary workarounds, record the condition under which they hold. Close or supersede the workaround when the underlying issue is resolved.

Make access and deletion testable

A stable customer identifier supports continuity. It doesn't prove the caller is entitled to use that identity. Enforce authorization before memory reads, writes, exports and deletion, and include the tenant scope in caches and background jobs as well as live searches.

Define retention separately for transcripts, summaries, extracted facts, logs and backups. A deletion workflow should cover the copies your system actually keeps. Removing a result from search doesn't necessarily remove its source or every derived copy.

Use the memory isolation guide to build negative tests for these boundaries.

Evaluate the support workflow

Create cases where a returning customer refers to an earlier ticket, changes a preference, asks about a resolved issue, or gives too little information. Add a different customer with a similar problem to test isolation.

Measure whether the agent recalls the right prior step, avoids repeating failed advice, checks current status and admits missing evidence. Track resolution quality alongside memory latency and token use.

For a small pilot, start with 40 cases: 15 returning-customer cases, 10 corrections, 5 missing-evidence cases, 5 isolation attempts and 5 deletion checks. Use them to find failure patterns, then add examples from real support work.

Compare against the same agent without memory. A higher benchmark score on its own doesn't show better resolution time or customer satisfaction in your product.

Start with one repeat-contact problem

Choose a support flow where customers currently repeat information. Add scoped history and source references, run the two-ticket test, and inspect the failures. The AI SDK walkthrough shows one implementation path, the user profiles guide covers what belongs in a customer profile, and the product page explains how supermemory turns saved conversations into memories.

The first useful outcome is concrete: a returning customer can continue an unresolved issue without repeating the steps that already failed.

For voice support, the call-to-memory pipeline covers accepted transcripts, speaker identity, revisions and cross-call retrieval.

AI Memory for Customer Support Agents: A Practical Architecture