Your team is building a customer support chatbot where individual customer sessions can span days. Users return after 48-hour gaps and expect the conversation to resume contextually. The system stores conversation history in a database. What is the correct strategy for managing message history across sessions of arbitrary length?
Select an answer to reveal the explanation.
Short Explanation
You need a bounded live messages array plus a persistent customer context record that you update by summarizing each session. That lets the chatbot resume days later without dumping the whole transcript into every call, and it keeps token use predictable.
Full Explanation
The correct strategy is the rolling context window with server-side summarization: after each session, distill the conversation into a persistent customer context record that is injected as context in future sessions, keeping the live messages array bounded. This provides continuity across multi-day gaps while keeping token consumption predictable, because Claude receives the relevant summarized history without needing the full raw transcript. The approach of storing the full message history and passing the complete array on every API call is wrong because the history will eventually exceed the context window and cause API errors, and automatic truncation is not guaranteed in a way that preserves semantic coherence. The approach of capping each session at 20 messages by design is wrong because it creates an unacceptable customer experience for complex support issues and is not a scalable architectural decision. The approach of using the Anthropic Conversations API endpoint to natively persist and manage conversation history server-side is wrong because Anthropic does not provide a native Conversations API that manages server-side history; conversation state management is the developer's responsibility.