mem0

but incorrect context — especially harmful for agents that act over long horizons. memU takes a different approach. Instead of trying to make embedding search smarter, we ask: what should not be retrieved via embeddings at all? Retrieval in memU starts at a Memory Category Layer: - memory is organized into semantically stable categories - each category is stored as a readable Markdown file - these files act as long-term, canonical memory When a query arrives, the LLM reads the relevant memory files directly, using semantic understanding rather than vector similarity. Only when this layer is insufficient does memU fall back to item-level retrieval, optionally using embeddings for speed. This design treats the LLM as what it’s increasingly good at: reading, reasoning, and maintaining structured knowledge, not just ranking vectors. Using Markdown files is deliberate — similar to ideas like `skills.md` — making memory explicit, inspectable, and stable over time. Compared to existing approaches: - [mem0](https://github.com/mem0ai/mem0) is fast and simple with classic RAG, but can struggle with temporal accuracy and precise state changes. - [Zep](https://github.com/getzep/graphiti) uses graphs, which handle structure well but add complexity and maintenance overhead. - [memU](https://github.com/NevaMind-AI/memU) uses non-embedding retrieval to address RAG’s structural limits in accuracy, stability, and long-term consistency — without replacing RAG entirely. For long-running agents, retrieval needs to provide reliable premises for reasoning, not just relevant text. In those settings, direct LLM reading over structured memory often aligns better with how models actually reason.

o the same issue: Agents starting the conversation from scratch (no context). We wanted something lightweight but powerful, a memory layer that lives locally on your machine, works with any MCP client over SSE, and lets you store, search, and control long-term memory without shipping your data to the cloud. It acts as a middle layer between your LLM-powered client and a vector database, storing and recalling arbitrary chunks of text called “memories” across sessions. Under the hood, it uses Qdrant for semantic search and relevance-based retrieval, while running entirely on your own infrastructure via Docker, Postgres and Qdrant with zero data leaving your system. A built-in Next.js & Redux dashboard lets you inspect which apps are reading or writing memories, along with a full audit trail of state changes. So happy to share learnings and get insights from your experiences. looking forward to comments!

very prompt. When we were building Embedchain (an open-source RAG framework with over 2M downloads), users constantly shared their frustration with LLMs’ inability to remember anything between sessions. They had to repeatedly input the same context, which was costly and inefficient. We realized that for AI to deliver more useful and intelligent responses, it needed memory. That’s when we started building Mem0. Mem0 employs a hybrid datastore architecture that combines graph, vector, and key-value stores to store and manage memories effectively. Here is how it works: Adding memories: When you use mem0 with your AI App, it can take in any messages or interactions and automatically detects the important parts to remember. Organizing information: Mem0 sorts this information into different categories: - Facts and structured data go into a key-value store for quick access. - Connections between things (like people, places, or objects) are saved in a graph store that understands relationships between different entities. - The overall meaning and context of conversations are stored in a vector store that allows for finding similar memories later. Retrieving memories: When given an input query, Mem0 searches for and retrieves related stored information by leveraging a combination of graph traversal techniques, vector similarity and key-value lookups. It prioritizes the most important, relevant, and recent information, making sure the AI always has the right context, no matter how much memory is stored. Unlike traditional AI applications that operate without memory, Mem0 introduces a continuously learning memory layer. This reduces the need to repeatedly include long blocks of context in every prompt, which lowers computational costs and speeds up response times. As Mem0 learns and retains information over time, AI applications become more adaptive and provide more relevant responses without relying on large context windows in each interaction. We’ve open-sourced the core technology that powers Mem0—specifically the memory management functionality in the vector and graph databases, as well as the stateful memory layer—under the Apache 2.0 license. This includes the ability to add, organize, and retrieve memories within your AI applications. However, certain features that are optimized for production use, such as low latency inference, and the scalable graph and vector datastore for real-time memory updates, are part of our paid platform. These advanced capabilities are not part of the open-source package but are available for those who need to scale memory management in production environments. We’ve made both our open-source version and platform available for HN users. You can check out our GitHub repo (https://github.com/mem0ai/mem0) or explore the platform directly at https://app.mem0.ai/playground. We’d love to hear what you think! Please feel free to dive into the playground, check out the code, and share any thoughts or suggestions with us. Your feedback will help shape where we take Mem0 from here!