Working memory vs durable memory

Keep temporary reasoning context separate from durable state that must survive compaction, retries and new sessions.

Mental model

Working memory helps with the current step; durable memory is application state with an explicit write, read, update and expiry policy.

Why it matters

Calling every retained piece of text 'memory' hides different engineering responsibilities. A scratch note can be disposable, while a user preference, workflow checkpoint or verified external identifier may need to survive restarts and remain correct after the current prompt is gone.

Two lifecycles, not one storage bucket

Working memory stays close to the current task and can be summarized or dropped when its local purpose is complete. Durable memory lives outside the prompt, is selected back into context when relevant, and needs policies for ownership, validity, privacy, update and deletion.

Example: resume after a crash

An agent writes 'step 4 looks complete' into chat and then crashes. That sentence is not proof that the side effect committed. A durable checkpoint records the operation identifier, verified external result and remaining verification work so the workflow can resume without guessing from prose history.

Common failure modes

Persisting raw model reasoning as trusted long-term memory.
Treating chat history as a recovery checkpoint.
Never expiring preferences or facts after their source changes.

Engineering heuristics

Define which facts deserve durable storage before adding a memory database.
Store provenance and update time with durable facts.
Re-retrieve durable memory for the current task instead of replaying all history.

Takeaways

01Working memory serves the current decision; durable memory survives across decisions.
02Persistence needs a lifecycle policy, not only a storage layer.
03Durable memory should be verifiable and invalidatable.