Add OpenSearch agentic memory blog post #3983
Conversation
dhrubo-os
requested review from
AMoo-Miki,
CEHENKLE,
elfisher,
kolchfa-aws,
krisfreedain,
natebower,
nateynateynate,
nknize and
peterzhuamazon
as code owners
|
Thank you for submitting a blog post! The blog post review process is: Submit a PR -> (Optional) Peer review -> Doc review -> Editorial review -> Marketing review -> Published. |
|
Hi @dhrubo-os, It looks like you're adding a new blog post but don't have an issue mentioned. Please link this PR to an open issue using one of these keywords in the PR description:
If an issue hasn't been created yet, please create one and then link it to this PR. |
dhrubo-os
force-pushed
the
opensearch-agentic-memory-blog
branch
from
acb3fe2 to
22a0e2f
Compare
dhrubo-os
force-pushed
the
opensearch-agentic-memory-blog
branch
from
22a0e2f to
7baa01f
Compare
|
@kolchfa-aws - Adding this to your queue for review. |
- Comprehensive guide to OpenSearch 3.3 agentic memory capabilities - Covers memory types, processing strategies, and integration patterns - Includes practical examples and best practices - Technical accuracy verified against official documentation Signed-off-by: Dhrubo Saha <[email protected]>
dhrubo-os
force-pushed
the
opensearch-agentic-memory-blog
branch
from
7baa01f to
b4c963f
Compare
arjunkumargiri
left a comment
arjunkumargiri
left a comment
There was a problem hiding this comment.
Thanks for the blog post! It does a good job of explaining about agentic memory and supported API's in OpenSearch.
Adding details around how an agent make use of these API's with an example of how to integrate with some popular agent framework will help increase adoption. Also showcasing an example of agent behavior with and without agent memory will clearly showcase agent memory benefits.
|
@dhrubo-os - Please make sure a blog issue is open for this. Without it, this blog can not be scheduled or published. |
|
|
@dhrubo-os Please let me know when this blog is ready for my review. Thanks! |
|
|
||
| Agentic memory is designed for seamless integration with external frameworks like Amazon Bedrock Agents, LangChain, LangGraph, and custom agent implementations, enabling developers to add sophisticated memory capabilities to their existing AI applications while leveraging OpenSearch's proven search and storage infrastructure. | ||
|
|
||
| In this blog post, we explore the specific s that agentic memory solves, introduce its core concepts, and demonstrate how to integrate it with your agent frameworks. |
| OpenSearch agentic memory consists of several key components that work together to provide both short-term context and long-term intelligence for your agents. | ||
|
|
||
| ``` | ||
| External Agent Frameworks (LangChain, LangGraph, Custom) |
There was a problem hiding this comment.
Use a architecture diagram ?
|
|
||
| In this blog post, we explore the specific s that agentic memory solves, introduce its core concepts, and demonstrate how to integrate it with your agent frameworks. | ||
|
|
||
| ## The memory problem in AI agents |
There was a problem hiding this comment.
Suggestion from AI
Heavy Duplication in Opening Sections
The introduction and "The memory problem in AI agents" section are almost entirely redundant:
Introduction says:
"Traditional LLMs process each conversation in isolation, lacking the persistent memory... forces developers to implement complex workarounds: manually managing conversation history, building custom databases..."
"The memory problem" section repeats:
"Current AI systems process each conversation independently, lacking the persistent memory... Developers building AI agents face several technical challenges... Token limit management, Custom infrastructure overhead..."
Recommendation: Merge these into one problem section OR make the intro much shorter (2-3 sentences) and move all problem discussion to the dedicated section.
|
|
||
| ## Integration with agent frameworks | ||
|
|
||
| OpenSearch agentic memory is designed to work seamlessly with external agent frameworks like LangChain, LangGraph, and custom implementations. The REST API interface enables straightforward integration without vendor lock-in, allowing you to add persistent memory capabilities to existing agents through standard HTTP requests. |
There was a problem hiding this comment.
Highlight it's "Framework-agnostic Design" and explain the REST API approach.
| - `{agent_id}`: Uses the agent identifier for organization | ||
| - `{org_id}`: Uses the organization identifier for granular level | ||
|
|
||
| These |
| - `/ecommerce-bot/product-catalog`: For shared product information accessible to all users | ||
| - `/ecommerce-bot/user-456/session-789`: For tracking support case progression | ||
|
|
||
| Dynamic namespace creation uses special placeholder variables in your namespace definitions: |
There was a problem hiding this comment.
Not sure if I understand this part correctly. But seems not so accurate. The namespace in Agentic Memory has no special placeholder. User can use any key/value pairs , not limited to these 4: user_id, session_id, agent_id and org_id.
Namespaces are defined as JSON key-value pairs with no predefined schema. You have
complete flexibility to design the structure that fits your use case. For example, user could use
{
"namespace": {
"department": "sales",
"region": "us-west",
"customer_tier": "enterprise"
}
}
| - `/ecommerce-bot/user-456/preferences`: For individual user shopping preferences | ||
| - `/ecommerce-bot/product-catalog`: For shared product information accessible to all users | ||
| - `/ecommerce-bot/user-456/session-789`: For tracking support case progression |
There was a problem hiding this comment.
Suggest not use this way to explain namespace, it's hard to map to our key/value pair style.
For example ecommerce-bot is a key , or value ? Should it be "agent_id": "ecommerce-bot" ? session-789 should be "session_id": "session-789"
|
|
||
| - **Organizational structure**: Separate different types of memories (preferences, summaries, entities) into distinct logical containers | ||
| - **Access control**: Control which memories are accessible to different agents or in different contexts | ||
| - **Multi-tenant isolation**: Segregate memories for different users or organizations with patterns like `/org_id/user_id/preferences` |
There was a problem hiding this comment.
Suggest not use this /org_id/user_id/preferences to avoid confusion, which looks misleading hierarchical implications.
|
|
||
| - **Text embedding models**: For semantic search capabilities across stored memories | ||
| - **Large language models (LLMs)**: For intelligent knowledge extraction and processing | ||
| - **Memory processing strategies**: For defining how memories are processed and organized |
There was a problem hiding this comment.
Clarify it's for long term memory
|
|
||
| ### Semantic search capabilities | ||
|
|
||
| Built on OpenSearch's powerful search engine, agentic memory provides sophisticated retrieval capabilities: |
There was a problem hiding this comment.
Agentic memory supports the full OpenSearch Query DSL, giving you complete
flexibility to search and retrieve memories using any query type. You can use
term queries, range filters, semantic search, aggregations, or any combination
of OpenSearch's powerful query capabilities.
| - Use **working memory** for immediate conversational context and temporary agent state | ||
| - Leverage **long-term memory** with inference for persistent knowledge and user preferences | ||
| - Implement namespace patterns that align with your application's user and session management | ||
| - Plan retention policies that balance functionality with privacy and compliance requirements |
There was a problem hiding this comment.
This part is not clear, how to implement retention policy
5 participants
Summary
This PR adds a comprehensive blog post about OpenSearch 3.3's agentic memory capabilities.
Issues Resolved
Resolves #3976
Content Overview
Target Audience
Developers and architects looking to implement persistent memory in AI agents using OpenSearch as the backend storage and processing platform.