Conversation memory, durable memory, and context engineering
Models are stateless unless the provider or application carries context. Spring AI chat memory stores message history; it is not automatically a durable user-memory system.
Memory types
- working context: current request, retrieved evidence, tool results;
- conversation history: recent user/assistant turns;
- summary memory: compressed older history;
- durable profile: explicit facts/preferences with provenance and consent;
- episodic memory: past outcomes retrieved for a similar task.
Spring AI
MessageChatMemoryAdvisor adds conversation history.
Supply ChatMemory.CONVERSATION_ID on each call. Choose a
repository, bounded window, retention, and deletion design.
Spring AI 2.0 tool calling maintains intermediate tool messages inside the loop; default memory advisors load once and store the final exchange. Advisor order changes semantics.
Memory safety
Never allow one tenant or user to retrieve another's history. Do not infer and store sensitive traits casually. Show users what is remembered, why, and how to correct/delete it.
Summarization risk
A summary is generated data and can distort commitments. Preserve immutable source turns for regulated decisions or attach summary provenance. Rebuild summaries when the summarizer changes.
Context budgeting
Rank memory by relevance, recency, importance, and authority. Current system policy outranks old conversation content. Drop low-value history before retrieved evidence required for the answer.
Feynman check
Conversation memory is yesterday's chat transcript; durable memory is a carefully maintained profile. Neither should be a mystery notebook the user cannot inspect.