Personal Assistant That Remembers You

The assistant has to remember enough to feel personal and forget enough to stay fast, correct and private.

A memory system is not one database with a bigger context window. It is four scopes of state, each with its own key, its own write rule and its own way to go wrong. This page turns this case into one read for the day before.

The source is short. Section 6 of the memory study guide gives a prompt, a rubric and seven bullets, about 25 lines in all. It has no diagram, no sizing and no cost. Everything beyond those 25 lines is built from this site's other memory material, and anything those sources do not say is marked (own construction). Sizing figures are stated assumptions, not measurements.

The prompt, verbatim from the source:

"Design the memory layer for a personal assistant used daily by the same users over months. It needs to hold a live conversation, recall stable preferences from weeks ago, remember what tasks it did recently, and never mix up two users' data. Keep p95 added latency from memory under 300ms."

Ask what the user expects the assistant to remember before drawing a box. "Remembers you" hides four different promises. Hold the conversation. Keep preferences for good. Recall what it did last week. Keep one user's life out of another's view. Each promise needs a different store with a different lifetime.

The clarifying questions (own construction):

Answer the last one for the interviewer if they will not: the budget is for reads on the critical path. Writes run after the reply is sent (own construction).

A requirement that cannot fail a test is a preference. "Remembers preferences" is a preference. "Recalls a preference stated 30 days ago in a new conversation" is a constraint.

The functional requirements (own construction, from the prompt):

The non-functional requirements, stated so each can fail a test:

Every requirement then needs an owner (own construction).

Say the arithmetic aloud, because it shows why an index and a pruning policy are not optional. Every number is an assumption for the whiteboard (own construction). The method is what gets scored.

Three conclusions follow. The episode cap is what bounds the index, because without it 5M writes a day grow without limit. The read rate is modest, so latency depends on the index, not on throughput. The summary calls are a real line on the bill, so the threshold is a cost lever and not just a quality setting.

The organising rule is resolve, read, assemble, reply, then write. Identity comes first, because every key depends on it. Reads fan out in parallel inside the budget. Writes happen after the reply, off the critical path.

The whole system (own construction):

 ╔═════════════════════ CONTROL PLANE (changes are releases) ═════════════════════╗
 ║ memory policy: what may be stored, per category · retention and caps per scope ║
 ║ summary threshold (~15 turns) · episode cap (100/user) · session TTL           ║
 ║ extraction prompt (versioned) · residency map · eval gates                     ║
 ╚══════════════════════════════════════╤═════════════════════════════════════════╝
                                        │ configures every box below
 ╔═════════════════════ DATA PLANE (calls are requests) ══════════════════════════╗
 ║                                                                                ║
 ║ client (web, phone, chat) ──> GATEWAY ──> IDENTITY SERVICE                     ║
 ║                                          user_id from the auth session         ║
 ║                                                  │                             ║
 ║                                                  v                             ║
 ║                      ┌──────── MEMORY READ FAN-OUT (parallel) ────────┐        ║
 ║                      │ thread checkpoint   key: thread_id             │        ║
 ║                      │ session state       key: session_id, TTL       │        ║
 ║                      │ semantic facts      ns: (semantic, user_id)    │        ║
 ║                      │ episodic search     ns: (episodic, user_id)    │        ║
 ║                      │                     vector index, user filter  │        ║
 ║                      │ episode digest      ns: (digest, user_id)      │        ║
 ║                      └───────────────────────┬────────────────────────┘        ║
 ║                                              v                                 ║
 ║                        CONTEXT BUILDER: system prompt + facts + digest         ║
 ║                        + top-k episodes + summary + recent turns + message     ║
 ║                                              │                                 ║
 ║                                              v                                 ║
 ║                        ASSISTANT MODEL + TOOLS (calendar, mail, booking)       ║
 ║                                              │ reply streams to client         ║
 ║                                              v                                 ║
 ║                        CHECKPOINT the turn (thread_id)                         ║
 ║                                              │ enqueue                         ║
 ╠══════════════════════════════════════════════╪═════════════════════════════════╣
 ║ ASYNC WRITE PATH (after the reply)           v                                 ║
 ║   MEMORY WRITER: extract candidate facts → policy filter → stable-key upsert   ║
 ║                  (previous value kept one version back)                        ║
 ║   EPISODE WRITER: one append per completed task → embed → index               ║
 ║   SUMMARISER: fold buffer into running summary past ~15 turns                  ║
 ║   PRUNER: keep newest 100 episodes, fold older into the rolling digest         ║
 ║   DELETION JOB: "forget X" and account deletion across every store and index   ║
 ║                                                                                ║
 ║ OBSERVABILITY: read latency per store, hit counts, writes by category — no text║
 ╚════════════════════════════════════════════════════════════════════════════════╝

The same flow for viewers that render Mermaid (own construction):

Read the components in request order. The failure column is own construction.

Point at three boundaries while the diagram is up (own construction). The isolation boundary is the identity service, because every namespace below it carries a user_id it supplied. The latency boundary is the parallel fan-out, because the slowest store sets the turn's added latency. The write boundary is the queue, because nothing after it can slow a reply.

Give each kind of memory its own scope, because each answers a different question. A thread_id answers "which conversation". A user_id namespace answers "which person". A system that has only the first forgets everyone between conversations. A system that confuses them leaks memory across users.

The study guide's taxonomy maps directly onto the prompt's four promises.

Procedural memory, meaning instructions that change the assistant's behaviour, is the fifth kind in the taxonomy. Keep it out of scope for a personal assistant unless asked. If it appears, gate every change behind human approval. The study guide's gotcha is that an approval passed as a tool argument lets the model approve itself.

"Short-term" describes scope, not lifetime. A durable checkpointer keeps thread history on disk across restarts, which is the point here. Handbook Module 07 doc 5 records a real deployment with thread checkpoints in a table, 30-day retention, chosen so conversations survived an endpoint restart and stayed auditable.

Keep enterprise knowledge out of memory entirely. Handbook Module 03 doc 2 makes the distinction: a stale preference fails as mildly wrong personalisation, while an outdated policy fails as a wrong answer. They refresh on different cadences, so they live in different stores.

Store every turn, and send the model only what this turn needs. Replaying the full history makes tokens and latency grow linearly with turns. The source answer summarises once the buffer crosses ~15 turns, so cost stays flat on long chats.

The study guide compares three options.

Pick summarisation with a window of raw recent turns. Volunteer its failure mode before the interviewer does: the summariser can drop something it judged unimportant that matters later. The semantic store is the safety net, because a preference extracted into a stable key no longer depends on the summary keeping it.

Two gotchas separate a practitioner from a reader. Trimming the prompt does not trim the stored checkpoint; only an explicit removal or a retention policy shrinks storage. A running-summary field with no merge rule can be reset by a stray input on the next call, so the summary appears never to accumulate.

The context builder assembles in a fixed order (own construction): system prompt, semantic facts, episode digest, top-k episodes, running summary, recent turns, then the new message. Stable parts go first, so a provider's prefix cache can reuse them across turns.

Derive a fact's key from what the fact is, and an event's key from nothing at all. Re-stating "call me Sam" should update one row, not add a second. A fresh random key per write guarantees nothing ever overwrites.

The study guide states the rule as a pair. If a fact can change, its key must be stable. If a fact is a fresh event, a fresh key is correct. Mixing them up is how semantic memory quietly turns into a pile of duplicate facts.

Handle a conflict explicitly. The source answer overwrites the existing key and keeps the previous value one version back. That makes "you told me X last month, now Y" answerable instead of silently lost. Add a timestamp and the source turn to each value, so the assistant can say when it learned something (own construction).

Name what is not persisted. The source answer keeps raw intermediate tool outputs and one-off task details in short-term or episodic memory only. They are promoted to semantic memory only when the user restates them as a standing preference. "Book me a window seat this time" is an episode. "I always want a window seat" is a fact.

Decide who chooses what to write (own construction). A hard-coded rule is predictable but misses facts it did not anticipate. A model-driven writer, in the style of MemGPT's self-editing memory tools, catches more but can misjudge what is durable. Use a model extractor behind a policy filter. The model proposes; the policy decides which categories may be stored at all. Run the extractor on the write queue, never on the reply path.

Cap episodic memory per user, because nothing else will. Every completed task is a fresh append with no natural ceiling, so a year-long user's row count only climbs. The source answer keeps the most recent 100 per user and folds older ones into a rolling digest rather than deleting them outright.

The digest keeps the gist of older activity at a fixed size. "Booked four trips to Lisbon this year" survives even after the four booking episodes are pruned (own construction). The pruner runs as a background job on the write path, so pruning never costs a reply any latency.

Session memory needs the same discipline in a different form. A TTL (time to live) marks entries for expiry, and sliding expiry extends the session on activity. The gotcha is that, in the LangGraph store, expiry is enforced by a sweep, not checked on every read. An expired entry can still be returned until the sweeper runs. That is true of SqliteStore and of PostgresStore by default; Postgres can set omit_expired to hide expired rows on read, and InMemoryStore has no TTL at all (checked Sep 2026). Schedule the sweeper, or check the entry's age if a few seconds of staleness matter.

Search long-term memory by relevance, because a scan's cost grows with how much has been stored. An unfiltered scan over a namespace is invisible at 5 facts and slow and noisy at 500. The source answer puts an embedding index on the semantic and episodic namespaces. Recall at 1,000+ saved items then becomes a vector query, not a full scan, and that is what keeps p95 under 300ms as history grows.

Many simple memory demos skip this. Their long-term search is an unfiltered scan or a similarity check by the model, with no real embedding index. That is the difference between working with 10 memories and working with 10,000.

Use each search shape for what it does best (own construction):

Semantic facts for one user are few, about 50 in the sizing, so fetch them all by key. Search is for episodes. Graph memory earns its extraction cost only when answers chain facts never stated together, so mention it and do not build it by default.

Budget memory like any other dependency, because a slow memory read can dominate p95 as easily as a slow retriever. The prompt allows 300ms added at p95. Spend it on reads in parallel and move every write after the reply.

A budget that fits (own construction; figures are assumptions):

A fact said in this thread is already in the checkpoint, so the long-term write can lag by seconds without anyone noticing. That is why every write can leave the critical path. The only freshness promise that matters is cross-conversation, and a queue that drains in seconds meets it.

Put timeouts on each read. When episode search misses its timeout, answer without it and log the miss rather than blowing the budget (own construction).

Read the isolation key from the server-side session on every request, because anything the model can set, a prompt can set. The source answer states it plainly: user_id comes from server-side session or auth config, never from a tool-call argument the model could set. Every namespace tuple includes it.

The study guide's debugging advice follows. When two users see each other's memories, audit namespace derivation first. The usual cause is a user_id sourced from the wrong place. A thread_id used by mistake as the long-term namespace causes the opposite bug: memory collapses back to per-conversation.

Channels have to agree on identity before memory can be shared. A web app and a chat bot both need to resolve to the same user_id at the identity layer. The memory system does not care which channel wrote a fact.

Governance follows from the same design (own construction, building on the FDE (Forward Deployed Engineer) track questions):

Measure whether the assistant remembers, not whether it sounds as if it does. A fluent answer that invents a preference is worse than one that asks again. Few worked examples cover memory-quality evaluation, so building it is the strong move.

The harness comes straight from the study guide's take-home. Plant a fact early in a long synthetic conversation. Ask for it 20 turns later. Score full history, sliding window and summarisation against each other on recall and cost. Extend it across conversations for this design: plant in thread A, ask in thread B a simulated week later (own construction).

Every metric except the last two is own construction built on the study guide's recall harness. Gate changes to the extraction prompt, summary threshold or cap on this suite, because each one changes what the assistant remembers.

Volunteer how the design breaks, because a design with no failure modes has not been examined. Most of these come from the study guide's gotchas and FDE questions; the rest are (own construction).

Use the source's rubric as the checklist for the answer, because it is the only scored artefact the source gives for this prompt. Each line points to where this page answers it.

The source's strong answer, compressed to one line per point with its figures intact:

Spend the time on scopes, bounds and isolation, because those are what the rubric scores. The model choice is a sentence.

The two-minute spoken answer (own construction, built on the source answer):

I would split memory into four scopes, because each answers a different question. The live conversation is checkpointed by thread ID and folded into a running summary past about 15 turns, so prompt size stays flat. Session context sits under a session ID with a TTL (time to live). Stable facts like time zone live in a semantic namespace keyed by user ID, under stable keys that overwrite in place, with one prior version kept so contradictions are answerable. Completed tasks are appended to an episodic namespace, capped at the newest 100 per user, with older ones folded into a rolling digest. Episodes are searched through an embedding index filtered by user, so recall stays fast past a thousand items. On each turn, the reads fan out in parallel and fit well inside the 300 millisecond budget; every write, extraction and pruning step runs on a queue after the reply. User ID always comes from the auth session, never from the model. I would prove it with a recall harness that plants a fact and asks for it 20 turns and one conversation later, plus a false-memory rate and cross-user isolation tests.

The lines that carry the round:

1. "Thread ID answers which conversation; the user namespace answers which person." (study guide)
2. "If a fact can change, its key must be stable; if it is an event, a fresh key is correct." (study guide)
3. "Store everything in the thread, send the model a summary and the recent turns." (own construction)
4. "A scan is fine at five memories and wrong at five hundred." (study guide)
5. "Reads on the critical path, writes after the reply." (own construction)
6. "User ID comes from auth. Never from the model." (source)
7. "Enterprise knowledge is not memory; it is retrieval." (Handbook Module 03)

The follow-ups, including the study guide's "skeptical staff engineer" prompts:

The pivot is usually "memory made the bill go up; what do you cut?" Answer with the cost-drill card (own construction, built on the cost study guides).

The cost study guide's first driver explains most surprises here. Input tokens grow with context: teams count the user's question and ignore the system prompt and hidden history, so the bill rises while traffic stays flat. Its fix list reads like this design: trim prompts, compress context, summarise history and cache static prompt parts. The study guide's FDE (Forward Deployed Engineer) answer is the non-engineer version: cost scales with how often memory is written and searched, not with how much is stored.

Every strong cost answer follows four verbs in order. Measure tokens per prompt section first. Route extraction and summarising to a small model. Bound episodes, summary length and top-k. Cache safely, with the stable prefix first and the user's scope in every key.

For this assistant, the levels separate on how far the answer goes past the four memory scopes into identity, deletion and proof that recall holds.

• Clarify the four promises hidden in "remembers you" and settle that the 300ms budget is for reads.
• Requirements are testable: recall 20 turns later, zero cross-user reads, flat prompt size, deletion everywhere.
• The sizing shows the 100-episode cap bounds the index and the ~15-turn summary is a cost line.
• One diagram shows resolve, read in parallel, assemble, reply, then write from a queue.
• Four scopes with four keys: thread, session, semantic and episodic, each with its own write rule.
• Store every turn, and send a running summary plus recent turns; trimming the prompt does not trim storage.
• Key facts by what they are, append events, keep one prior version, and never persist transient details as facts.
• Cap episodes at 100 and fold older ones into a digest; sweep expired sessions on a schedule.
• Fetch facts by key and search episodes through an index filtered by user.
• In my budget, reads fit in about 115 ms in parallel; every write leaves the critical path.
• user_id comes from auth on every request, and governance follows from the namespaces.
• Measure recall of planted facts and false memories, not fluency.
• Volunteer the failure modes: random keys, unbounded episodes, scans, model-supplied identity, memory poisoning.
• The source rubric has eight lines, and each maps to a section.
• The 45 minutes go to scopes, bounds and isolation.
• Memory cost is writes and read-back tokens: retrieve a few, summarise in steps, extract small and late.

1. What four promises hide in "remembers you"? Hold the conversation, keep preferences, recall past tasks, and keep users apart.
2. Why does the 100-episode cap matter for latency, not just storage? It bounds the index each user's search runs over, which keeps the vector query fast as tenure grows.
3. Why is summarising every ~15 turns a cost decision? Each fold is an extra model call; at the assumed 30 turns a day it adds about 7% more calls.
4. What key does each scope use? thread_id for the conversation, session_id with a TTL for the session, (semantic, user_id) plus a stable key for facts, (episodic, user_id) plus a fresh key for tasks.
5. Why does trimming the prompt not shrink the database? Trimming filters what the model sees; only an explicit removal or a retention policy deletes stored history.
6. "Call me Sam" is said twice. One row or two? One, if the key is preferred_name; two, if each write gets a random key.
7. What happens when a new preference contradicts an old one? Overwrite, keep the old value one version back with its date, so the change is answerable.
8. "Book a window seat this time." Semantic or episodic? Episodic; it becomes semantic only if restated as a standing preference.
9. Why can every memory write leave the critical path? The fact is already in the thread checkpoint, so only the cross-conversation copy lags, by seconds.
10. Where must user_id come from, and why? The server-side auth session; anything the model can set, a prompt can set.
11. How would you test that memory works? Plant a fact, ask 20 turns later and in a new conversation; score recall, false memories and cost.
12. What is the sixty-second cost answer? Storage is cheap; the model calls to write memory and the tokens to read it back are not. Retrieve a few memories, summarise in steps, extract with a small model after the reply.

Fact-check sources (checked 27 Sep 2026)

• LangGraph TTLConfig source — refresh_on_read gives sliding expiry; omit_expired defaults to off; sweeping deletes expired items
• LangGraph SqliteStore source — get does not filter expired rows; sweep_ttl and start_ttl_sweeper delete them
• LangGraph PostgresStore source — optional omit_expired read filter; the sweeper must be started explicitly
• MemGPT: Towards LLMs as Operating Systems — the model edits its own memory through function calls