Chapter CMemory & conversation statePage 8 of 8

Memory & conversation state

Mastery: connect the pieces

Turn understanding into a design: explain conversation memory by connecting a concrete decision to observable evidence.

~12 minMastery check

Before you start

Why this matters

Imagine you own a personal tutoring assistant and must explain one decision to a teammate who knows basic AI vocabulary but has never operated this feature. Write two sentences: what problem does conversation memory solve, and what evidence would show it is solving that problem? Do not name a vendor or model yet. This separates the enduring idea from one implementation.

1Learn the idea

Read

Synthesize the system

A complete explanation of conversation memory now has four connected claims. A chat model does not remember yesterday by itself. A memory system is a notebook managed by the application: decide what deserves writing, store it with provenance, retrieve the relevant notes later, and let the user inspect or erase them. After a turn, a policy extracts candidate facts, preferences, commitments, or summaries. Storage records scope, source, timestamp, confidence, and expiry. Before a later response, retrieval filters by user and relevance, resolves conflicts, and inserts selected memories into context. Chat history is raw recent turns; a summary compresses them; memory is selected state carried across sessions; retrieval fetches external records; fine-tuning changes general behavior. Memory should never be an invisible excuse for retaining everything.

Turn those claims into a design for a personal tutoring assistant. State the user job, data boundary, uncertain model contribution, deterministic controls, evaluation set, release gate, production signal, and failure response. If any item is missing, the concept is not yet operational.

Read

Architecture review

Use this spoken diagram:

authorized input -> scoped evidence -> learned operation
                 -> deterministic validation -> bounded action
                 -> outcome + trace -> evaluation and improvement

At every arrow ask: what representation crosses, who owns it, what can be lost, and how is it versioned? Choose memory types, write threshold, user scope, retention and expiry, retrieval top-k, recency weighting, confidence, conflict policy, confirmation prompts, sensitive-data exclusions, and deletion behavior. Separate durable preferences from temporary session state and derived summaries. The controls should be few enough to understand and complete enough to constrain the severe failures.

Read

Defend a tradeoff

More memory enables continuity but increases privacy risk and stale assumptions. Automatic writes reduce friction but capture mistakes; explicit confirmation is accurate but interrupts conversation. Summaries are compact while raw turns preserve evidence and consume more storage and context. Choose one tradeoff and defend it quantitatively. Name a hard constraint, a primary metric, and the cost you accept. Then name evidence that would reverse your decision. This last step protects the design from becoming identity or vendor loyalty.

A defensible statement sounds like: “We choose configuration B because it passes the privacy and severe-error gates, improves task success on the target slice, and stays within the p95 latency budget. We will reconsider if traffic or review cost crosses the recorded threshold.”

Read

Diagnose under pressure

The system stores a joke as a preference, leaks one user’s memory to another, preserves a corrected fact, infers sensitive attributes, or retrieves irrelevant notes that anchor the answer. Deleting the visible note without deleting indexes, backups, and caches creates false control. Pick the most consequential failure and walk through trigger, earliest signal, containment, owner, recovery, and prevention. Measure useful-memory precision and recall, contradiction rate, stale-memory rate, cross-user isolation, deletion completion, retrieval latency, and user correction frequency. Use longitudinal scenarios where preferences change and adversarial tests that attempt tenant crossover. Monitoring should reuse the evaluation construct where possible, while acknowledging that production labels may arrive late.

Read

Mastery questions

Answer without notes:

  1. What does this concept change: evidence, learned behavior, runtime state, coordination, or measurement?
  2. Which neighboring concept is commonly confused with it?
  3. Which intermediate artifact would you inspect first?
  4. Which knob has the largest quality/resource interaction?
  5. What hard gate cannot be traded for average quality?
  6. What baseline could disprove the need for the complex design?
  7. How would you detect harm hidden by an aggregate metric?
  8. What is the safe state during uncertainty?

Now explain the worked evidence: On Monday, Lina says, “For this week, quiz me at beginner level.” The extractor labels it temporary with a seven-day expiry. In August she says she passed the course. A durable “beginner” memory would now patronize her; the scoped note has expired, so the tutor asks for her current level instead. If you can identify the causal chain, calculate the consequential change, propose an alternative hypothesis, and choose a reversible response, you have moved from vocabulary to engineering judgment.

Read

A reusable decision record

End with one page containing: context, alternatives, assumptions, case-set version, configuration IDs, metric table, gates, selected option, rejected options, owner, rollout, rollback, and review date. This artifact makes future disagreement productive because teammates can challenge evidence or weights instead of reconstructing hidden reasoning.

Checking tutor…

Continue learning · glossary & guides