Foundations · Explore this field ↗ · Architecture · 2 min read
State is not memory
Design session state, user profile, retrieval context, and long-term memory as separate promises.
See the source / a related case
Four things called memory
Session state tracks the current job: the order number already supplied, the selected plan, the step in a return flow. A user profile stores durable, explicit preferences. Retrieval context supplies material from documents or records for this answer. Long-term conversational memory summarizes past exchanges. These stores have different owners, retention periods, and deletion requirements. Combining them in one transcript makes consent and debugging nearly impossible.
Remember decisions, not atmosphere
Persist information because it improves a named job, not because personalization sounds appealing. A support bot may need the customer’s language preference and open case number. It rarely needs an impressionistic summary of frustration from six months ago. Store typed facts with provenance and timestamps where possible. Let the user inspect and correct durable memory; make absence and uncertainty explicit.
State transitions should be visible
When the system moves from browsing to authentication, from advice to action, or from bot to human, mark the transition. Summarize what carries forward. Reset stale fields when the task changes. A compact state model prevents the model from treating every previous sentence as equally relevant and reduces accidental action based on an obsolete request.
Operator note
Create a data table with fields for value, source, scope, retention, user control, and downstream access. Test session expiry, account switching, deletion, and handoff. A memory feature is unfinished until operators can answer ‘why did the bot know that?’ and the user can make it stop knowing it.
A deletion rehearsal
Create a test account, complete several conversations, save one preference, open a case, and then request deletion. Trace the request through transcript storage, analytics, embeddings, summaries, caches, backups, and the human help desk. Record what disappears immediately, what ages out, and what must remain for a documented legal or operational reason. Repeat after account switching and session expiry. The rehearsal often shows that the visible memory control governs only one store. Fix the whole path before promising that a user can make the system forget.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.