Context, execution state, and memory need separate controls

Context is the information supplied for a model invocation. Execution state records where a workflow has reached. Retained memory is information stored for possible future use. An application can maintain all three without giving them the same scope, storage, or deletion behavior.

A retained record need not be active context

A customer preference might remain in a store while never being retrieved for the current request. Conversely, a document placed in the current prompt can influence an answer without becoming long-term memory. Storage and use therefore need separate records.

Consider an assistant that retains a delivery address, pauses before submitting an order, and later resumes. The address is retained data; the pending approval belongs to workflow state; the prompt assembled at resumption is context. Removing one does not demonstrate that the other two were removed.

Persistence has a scope and a backing store

The documented LangGraph example distinguishes thread-scoped checkpoints from application-defined stores shared across threads. Its in-memory checkpoint implementation does not survive a process restart. This illustrates a storage boundary; it is not a universal definition of every framework’s memory.

A recovery plan must identify what actually persists. A successful pause during a demonstration does not prove that the process can recover after its host disappears. Testing recovery requires the intended persistent store and a restart that loses process memory.

Deletion must follow the copies that matter

The design implication is to assign ownership separately to current inputs, resumable state, and retained records. A deletion operation needs to specify whether it affects one conversation, every thread, cached retrieval, or a shared store.

The same distinction matters for correction. Updating a stored address does not establish that an already paused order has replaced its old address. The workflow must decide whether to reload, invalidate, or reconfirm that state.

Calling all these objects “memory” conceals the control question. The useful description names the record, its scope, the store that holds it, and the operation that reads or changes it.