Conversation History vs Agent Memory: What Should Survive a Session?

Conversation history preserves messages. Agent memory selects information to make available in later work. An application can implement both, but storing the transcript alone does not decide which earlier facts should shape a new conversation.

That distinction helps diagnose “forgetting.” The history may still exist while the new session never loads it. A selected memory may exist while its original source has been removed. Treat those as separate storage and retrieval paths.

Decide what a session owns

A session typically groups one conversation or execution thread. Its message order can be important for tool-call correctness and follow-up references. A durable history store can preserve those messages across process restarts.

Cross-session context needs a different decision: which facts should travel to another thread for the same authorized user? Reusing the entire old transcript can carry obsolete instructions and unrelated material. Selecting a preference or decision requires its scope and provenance to remain explicit.

The OpenAI Agents SDK sessions documentation describes a native history mechanism. It is useful on its own; adding another memory service should address a demonstrated requirement beyond that session boundary.

Keep three identities distinguishable

A tenant identifies the customer organization. A user identifies the person or account within that organization. A conversation identifies one interaction thread. The retrieval policy may use more than one, but they should not be interchangeable strings chosen by the model.

A new conversation ID should not create a new person. Conversely, two people asking about the same project should not receive each other's private notes unless the application explicitly permits that shared scope.

Define deletion across both paths

Clearing a conversation can leave extracted records intact. Forgetting an extracted record can leave its source messages intact. A resumed session might therefore supply information that ordinary memory search no longer returns.

Map the sources used for the answer and apply the operation that matches the product promise. If the user expects complete removal from active answer paths, test history, selected memories, and caches rather than one endpoint.

Choose a small cross-session contract

Start with one preference that should persist and one temporary request that should not. Save both in a conversation, start another, and inspect which context is supplied. Then revise the preference and repeat after a process restart.

For implementation choices, see three ways to add long-term memory. If selected user context is the missing layer, try Supermemory alongside your existing history store and keep each system's lifecycle explicit.