---
title: "Memory for personalized AI assistants"
description: "How to store user preferences, history, changes and corrections for a personalized AI assistant, with temporal facts, evidence and deletion controls."
canonical: https://past.dev/use-cases/personal-assistants
last-updated: 2026-08-31
---
# Building a personalized AI assistant

Source: https://past.dev/use-cases/personal-assistants

A personalized AI assistant retains user preferences, current circumstances, history and corrections across sessions. Its memory system must decide what to store, update changed facts, preserve evidence, isolate each user's data and report insufficient evidence. This guide describes an API-based implementation.

## Information used for personalization

- **Stable preferences.** Dietary rules, tone, working hours, the format they want answers in. Slow-changing, high-value, cheap to store.
- **Situation.** Employer, city, projects, relationships. Changes occasionally, and being wrong after a change is worse than never knowing.
- **History.** Previous questions, decisions and commitments, with dates.
- **Corrections.** The user said it wrong, then fixed it. The fix must supersede, and the original must stop surfacing.

These records can change over time. When a user moves, changes jobs or reverses a decision, the existing entity receives new facts and [validity windows](/glossary/validity-window). Static profile fields need explicit update and history handling.

## Common personalization failures

- Re-asking. The assistant requests information the user has given three times. Users read this as not being listened to.
- Stale information. The assistant uses a previous office, employer or dietary preference after it changed.
- Unreported conflicts. The user's calendar and message disagree, but the assistant selects one without reporting the conflict.
- Unsupported familiarity. The assistant answers a personal question without supporting history.

An evidence model addresses conflicts and unsupported questions. Recall should return ranked, dated evidence with `Supported`, `Conflicted` or `NoKnownSupport` in the response status.

## Implementation sequence

1. Capture as things happen: after each session, the assistant writes durable observations, each with the time it happened, through `POST /api/v1/ingest`.
2. Structure records during ingestion: extraction, entity resolution and temporal storage link references to the same person across chat and email.
3. Recall before each task that depends on user state. Call `POST /api/v1/recall` with the question and add only the returned evidence to the prompt. [Context engineering](/context-engineering) covers prompt assembly.
4. Route on `status`: answer with dates when `Supported`, ask the user when `Conflicted`, and report insufficient evidence when `NoKnownSupport`.

```bash
curl -X POST https://api.past.dev/api/v1/recall \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "Where does Dana work now?"}'
# -> status: Supported, with dated evidence for the current employer.
#    The previous employer remains available for historical queries.
```

## Limits of larger context windows and vector stores

Resending the full history on every call increases input cost and does not identify the current statement. A vector store may retrieve both the previous and current employer with similar scores. [Supersession](/glossary/fact-supersession) marks the replacement as current and retains the previous value for historical queries. See [vector database vs memory](/vector-database-vs-memory) for the storage tradeoffs.

## Shipping it

The [quickstart](/docs/memory-api/quickstart) shows personalized recall in four calls. Integrations include a tool in the [Claude Agent SDK](/integrations/claude-agent-sdk), nodes in [LangGraph](/integrations/langgraph) and [HTTP Request nodes in n8n](/integrations/n8n). The [benchmarks page](/benchmarks) reports update and abstention tests. The [security page](/security) documents isolation and deletion.

## Frequently asked questions

### What should a personal assistant store, and what should it not?

Store information that changes assistant behavior: preferences, circumstances, decisions, commitments, and corrections. Extract durable facts from transcripts and retain each transcript as a source. Provide complete deletion for user memory.

### How is this different from ChatGPT-style built-in memory?

Built-in assistant memory is controlled by the assistant vendor. A memory API lets the application maintain its own user record across models, including dates, sources, supersession, and an insufficient-evidence status.

### Does personalization survive a model switch?

Yes. Memory remains behind the API as structured facts. A model switch does not require rebuilding the stored user record.

## Related

- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Context engineering](https://past.dev/context-engineering)
- [Fact supersession](https://past.dev/glossary/fact-supersession)
- [Vector database vs memory](https://past.dev/vector-database-vs-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)