An AI assistant can keep a research outline, latest edits and supplied sources in view during one conversation, then lose that continuity a week later in a new chat. The difference is not intelligence but architecture: active memory holds what the model uses now, while persistent memory holds what the application saved for later. Understanding that boundary determines whether a system can resume work, apply a preference or correct an outdated assumption.
How active context and saved state differ
The source defines active context as the information supplied to the model for its current response, including instructions, messages, selected tool outputs and retrieved material. Active task state is broader and can include a plan, checklist or variables the application maintains without yet inserting them into context. Active memory is used as a practical umbrella for this working set, while persistent memory means retained information that survives a response or session boundary, such as preferences, project notes, event records or checkpoints.
A key exception is that short-term state can also be saved. LangChain documentation distinguishes thread-scoped state persisted through checkpoints from longer-term memory organized into separate namespaces. A support agent waiting for a receipt upload can checkpoint that case to a database and resume after interruption. That checkpoint is durable, yet it should not automatically become a general fact about the customer or appear in unrelated requests.
The assembled input is the model’s immediate evidence, and anything excluded from it cannot be reliably recovered by the model. A tool can extend access by fetching a project file on demand, so the archive was available to the application before it became active evidence. Internal transformer caches improve inference efficiency but should not be confused with an editable, permission-aware record of preferences or history. Evaluating any feature therefore requires asking about lifetime, scope and availability to the current model call.
What this means for companies using AI assistants
A larger context window does not solve memory, because it only lets an application supply more material at once. The Lost in the Middle study showed tested models performed differently depending on where evidence appeared in long inputs, which warns against treating advertised capacity as guaranteed recall. If forty discussions mention a launch date and only the last one contains the approved change, supplying all forty creates an authority problem. A maintained current-status record linked to the approved change is more reliable.
Durable memory starts with a write decision, and the source distinguishes explicit instructions from inferences and observations. "For Project Cedar, use metric units" is an explicit preference, while "the user seems to prefer metric" is an inference and past usage is an observation. A useful record adds project identifier, owner, source interaction, timestamp, validity status and exceptions. Immediate writes can serve the next request, while background processing can deduplicate or summarize later, but confirming a save before it succeeds creates a continuity failure.
Retrieval is a sequence of eligibility, relevance and evidence decisions, beginning with identifying which user, tenant, project or task records may be consulted. For buyers, this means asking vendors where a fact came from, what scope it covers and whether its status can be corrected. Small teams feel failures as lost preferences across chats, while large firms face permission leakage and conflicting versions. The news itself does not establish a universal standard, only an illustrative schema for verification.
