---
title: "Building an AI assistant that remembers users"
description: "An AI assistant that remembers users needs identity resolution, facts that update, and deletion that holds. The architecture, and the two calls that run it."
canonical: https://past.dev/guides/ai-assistant-that-remembers
last-updated: 2026-09-02
---
# Building an AI assistant that remembers users

Source: https://past.dev/guides/ai-assistant-that-remembers

An AI assistant that remembers users keeps information outside the context window and retrieves it on the next session. Remembering decomposes into four capabilities: recognizing the returning user across channels, storing facts with dates so preferences can change, retrieving only what the current question needs, and deleting what a user asks to remove. Each capability fails independently, which is why an assistant can feel attentive in one conversation and a stranger in the next.

## What remembering actually decomposes into

- **Recognition.** The returning user must resolve to the same identity whether they arrive by email, chat or app. This is [identity resolution](/guides/identity-resolution), and without it every channel meets a stranger.
- **Durable facts.** Preferences, situations and history stored as dated facts. [Session memory](/glossary/session-memory) evaporates by design; remembering means [cross-session memory](/glossary/cross-session-memory).
- **Change.** "I moved to Berlin" must supersede Amsterdam rather than coexist with it. Assistants that append forever contradict themselves; see [facts that change over time](/guides/facts-that-change-over-time).
- **Forgetting.** "Delete what you know about me" must actually hold, including derived facts. See [the right to be forgotten](/guides/gdpr-memory-deletion).

## The failure users actually notice

Users rarely report a memory architecture. They report symptoms. The assistant asked for the account number again. It recommended the plan they already rejected in March. It congratulated them on a move that fell through. Each symptom maps to one missing capability: recognition, retrieval, or supersession. The repeated-question symptom is usually a split identity. The rejected-plan symptom is retrieval that ignored a stored fact. The stale congratulation is an unsuperseded update; the store still carries the old fact as current, which [memory staleness](/glossary/memory-staleness) defines.

The diagnosis order matters because the fixes differ. Test recognition first with the three-identifier protocol in [testing entity resolution](/guides/testing-entity-resolution), then retrieval, then supersession, using the five tests in [choosing a memory system](/guides/choose-memory-system).

## The architecture, in two calls

The write path stores what each session produced, with its time. The read path retrieves what the current question needs. Everything else (extraction, resolution, supersession) belongs to the memory layer rather than to prompt engineering.

```writeafterasessionreadonthenextone
POST /api/v1/ingest
{ "content": "Call with dana@northsea.io, 2026-09-02: prefers annual billing, asked to drop the weekly digest.",
  "timestamp": "2026-09-02T14:30:00Z" }

POST /api/v1/recall
{ "query": "How does Dana want to be billed?" }
```

Recall returns the billing preference with its date and the call it came from, and an explicit [evidence status](/glossary/evidence-status) when the store cannot answer. The assistant's prompt then carries a few hundred tokens of relevant, dated evidence rather than the full history; the cost shape of that difference is covered in [context window](/glossary/context-window) terms.

## Privacy is part of the feature

An assistant that remembers is also a system that stores personal data, and users know it. Three practices keep the feature trustworthy. Show what is remembered: an inspectable list beats an inference. Scope what is recalled: a support agent and a billing agent should see different slices, which audience-scoped recall enforces. Honor deletion completely: removing the source must remove the facts only it supported, verified by asking again. The [forgetting policy](/guides/forgetting-policy) guide covers what should never be stored at all.

## Running it on past.dev

past.dev implements the layer as an API: ingestion takes each session's text with its timestamp, entity resolution joins the user's identifiers across sources, changed preferences supersede their predecessors with validity windows, recall is filtered by audience, and deleting a source erases what only it supported. The [quickstart](/docs/memory-api/quickstart) shows the calls above end to end, and the [benchmarks](/benchmarks) page documents recall evaluation, including preference questions.

## Frequently asked questions

### How do I make my AI assistant remember previous conversations?

Store each conversation's durable facts outside the model with their dates, then retrieve the relevant ones at the start of the next session. The model itself is stateless; remembering is a storage and retrieval layer around it.

### Why does my AI assistant forget users between sessions?

Model context ends with the session, so anything worth keeping must be written to external memory before the session closes and recalled on return. If some users are remembered and others are new every time, identity resolution across their channels is usually the gap.

### Can an AI assistant remember a user across different channels?

Yes, when their identifiers are resolved to one identity: the email address, the chat handle and the app login must map to the same person. Recall then returns one timeline regardless of the channel the user arrives from.

## Related

- [Identity resolution](https://past.dev/guides/identity-resolution)
- [Facts that change over time](https://past.dev/guides/facts-that-change-over-time)
- [Choosing a memory system](https://past.dev/guides/choose-memory-system)
- [Cross-session memory](https://past.dev/glossary/cross-session-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)