OpenSearch 3.8 adds an experimental, opt-in memory retention feature for agentic memory containers, letting operators set age-based (retention_days) and count-based (max_count) limits on sessions, long-term memory, and history to control storage growth and keep agent context fresh. Individual memories can be pinned to exempt them from deletion, cluster-wide defaults can be configured for consistency, and a safe rollout sequence exists for enabling retention on clusters that already hold data without accidental loss. Safety controls include a 50,000-document-per-pass cap, a dynamic kill switch, orphaned-message sweeps, and up to a 24-hour delay before expired memories disappear from query results.
Table of contents
Enabling memory retentionHow a retention policy worksChoosing retention valuesAttaching a retention policy to a containerPinning memoriesSetting cluster-wide defaultsEnabling retention on an existing clusterSafety controlsConclusionAuthorQuestions this post answers
How do I set up retention policies for agentic memory in OpenSearch 3.8?
OpenSearch 3.8 introduces an experimental memory retention feature controlled by the flag plugins.ml_commons.memory.retention_enabled, disabled by default. You can set retention_days (age-based, measured from last_updated_time) and max_count (count-based, deletes oldest first) per memory type on sessions, long-term memory, and history when creating a container, or configure cluster-wide defaults for containers without their own policy. daily.dev surfaces practical rollout guides like this for teams tuning agentic memory storage costs.
How can I safely enable memory retention on an OpenSearch cluster that already has months of data without losing anything?
Enable retention_enabled first while leaving all defaults at -1, which only exposes the retention APIs without deleting anything. Then set explicit policies on containers whose workload you understand, exempting any with retention_policy set to null. Finally configure cluster-wide defaults for the remaining containers, which adopt them on the next scheduled job run. Engineers rolling out storage lifecycle changes can track guidance like this on daily.dev.
Can I exempt specific conversations or facts from OpenSearch agentic memory retention deletion?
Yes, pinning a memory exempts it from retention enforcement regardless of age or count limits. Pinning a session protects the entire conversation and all its messages, and pinned memories don't count toward max_count. Only sessions and long-term memories can be pinned; working memory and history cannot. daily.dev helps developers keep up with fine-grained controls like pinning in evolving data platforms.