Forget Total Recall. Give Your AI Agent Selective Memory with OpenSearch.

Amazon OpenSearch Service has introduced purpose-built APIs for agentic memory, enabling AI agents to store and retrieve persistent, semantically searchable conversation data. The system, built on the ml-commons plugin, organizes memory into sessions, working memory, long-term memory, and history, using LLM extraction and vector embeddings to surface relevant facts without overloading context windows.

Imagine handing an LLM the full text of Anna Karenina and asking what Levin thinks about farming. The model has the information somewhere in its window. Good luck getting a focused answer. The number of tokens you can pass to an LLM in a single call can grow to 200K and beyond, but the problem is not capacity. The problem is that LLMs diverge when there is too much information. Relevance degrades with volume. Past a threshold, adding more context makes answers worse, not better. This is why "just make the window bigger" is not a memory strategy. AI agents need memory that is selective, persistent, and searchable. Not a transcript. Not a sliding window. A system that extracts what matters, stores it durably, and retrieves only the right pieces when the agent needs them. This is a search problem, and Amazon OpenSearch Service now provides purpose-built APIs for exactly this: agentic memory that gives your agents persistent, semantically searchable recall across conversations. LLMs process text in a fixed-size window. GPT-4o gives you 128K tokens. Claude gives you 200K. That sounds like a lot until you try to use it as a memory system. A single week of customer interactions for one user might run 50K tokens. A month blows past any context limit. And even if the window were infinite, retrieval latency and cost scale linearly with token count. You are paying for every token you stuff in there, and most of it is irrelevant to the current question. The naive solution—append the last N messages—fails on both ends. If N is small, you lose information that matters. If N is large, you lose relevance. The agent drowns in a sea of context where the signal-to-noise ratio degrades with every turn. The customer said they prefer conservative investments six months ago, once. That single statement buried under 200 subsequent messages is invisible to a sliding-window approach. What you actually want is not a transcript. You want a system that extracts the important pieces, stores them persistently, embeds them for semantic retrieval, and hands back only the facts that matter for the current moment. You want the agent to know that this customer prefers conservative investments without needing to re-read six months of transcripts. That is a search problem, not a context-window problem. And search is what OpenSearch Service does. OpenSearch Service provides a purpose-built agentic memory system through its ml-commons plugin https://docs.opensearch.org/latest/ml-commons-plugin/agentic-memory/ . The system organizes memory into containers—one per agent or use case—and supports four distinct memory types that work together. Sessions track conversation metadata: who participated, when the conversation started, what state the interaction reached. Think of sessions as the filing system. Each session is a distinct interaction context, and the memory system tags all stored information with session identifiers so retrieval can scope to the right timeframe. Working memory holds the active conversation data and agent state during an ongoing interaction. Raw messages, execution traces, current task progress, and temporary data all live here. This is the short-term scratchpad your agent writes to during a session and reads from when the LLM needs immediate context. Long-term memory is where the real value accumulates. When inference mode is enabled infer: true , OpenSearch Service passes the conversation through an LLM that extracts key facts, preferences, and insights. Those extracted pieces are embedded as vectors and stored persistently. Six months later, when the same customer calls back, a semantic search against long-term memory surfaces "prefers conservative investments" without loading a single old transcript. History maintains an audit trail of every memory operation—adds, updates, and deletes—across the container. This gives you the ability to trace how an agent's knowledge evolved and debug unexpected behavior. Raw storage is only part of the system. OpenSearch Service offers three processing strategies that automatically organize memories as they arrive. The SEMANTIC strategy groups related memories by meaning—conversations about retirement planning cluster together even if the words used differ from session to session. USER PREFERENCE extracts explicit preferences "I prefer email," "don't call before 10am" into dedicated long-term entries. SUMMARY creates condensed versions of sessions so your agent can skim a six-month relationship in a few paragraphs rather than re-reading every message. These strategies run server-side. Your agent sends a conversation specifying infer: true , and OpenSearch Service handles the extraction, embedding, and organization. Your agent code stays focused on the conversation. You can swap embedding models or change strategies without touching agent logic. Memory containers support namespaces that partition information by user, session, or agent instance. A contact center serving 100K customers uses one memory container with customer id as the namespace. Every search is scoped to the current customer—logical isolation without the overhead of 100K separate indexes. The retrieval API combines semantic search with namespace filtering in a single call, so the agent gets back only memories that belong to the right customer and match the current query. Here is what happens during a live conversation. The agent receives a customer message. Before responding, the agent searches long-term memory with the customer's namespace and the current query "What did we discuss about retirement?" . OpenSearch Service returns the most semantically relevant memories. The agent includes those memories in its prompt alongside the current message. The LLM generates a response informed by real history, not a sliding window of raw text. After the session ends, the full conversation is stored back into the container with inference enabled, updating long-term memory for next time. The difference between an agent that remembers and one that does not is the difference between a service that builds relationships and one that processes transactions. A customer who has to re-explain their situation on every interaction feels unheard. An agent that picks up where the last conversation left off feels like a partner. OpenSearch Service provides the infrastructure that makes this possible: persistent, searchable, semantically organized memory that your agent can query in milliseconds. The APIs are available today in OpenSearch 3.3 and later. If you are building agents that talk to the same people more than once—and that is most agents worth building—give your agent a memory that outlasts the context window. The agentic memory documentation https://docs.opensearch.org/latest/ml-commons-plugin/agentic-memory/ covers the full API surface, and the contact center tutorial https://opensearch.org/blog/personalizing-your-contact-center-agent-using-opensearch-agentic-memory/ walks through a complete implementation.