Original link：https://memu.pro/blog/memu-1-0-0-release
memU has been open-sourced for nearly five months.
During this time, with strong support from the community and real-world users, we’ve gained substantial hands-on experience and deeper insights into what agent memory systems actually need to work in practice.
As more teams build increasingly complex agents, one thing has become clear: the demand for persistent, inspectable, and evolvable agent memory is growing rapidly — and most existing solutions fall short in real-world use.
With the new year kicking off, memU 1.0.0 is here. If you like what you see, a star on GitHub would mean a lot to us: https://github.com/NevaMind-AI/memU
This release is not only an upgrade to the system itself, but also a refinement of our direction. We listened closely to the feedback from developers and users, and shaped memU 1.0.0 around the real problems people face when building agents.
Our conclusion is straightforward:
memU 1.0.0 is a memory infrastructure built specifically for agents — evolvable, maintainable, and designed for long-term use.
It is not about larger context windows, nor about more complex RAG pipelines.
Instead, memU provides a long-term memory system that humans can manage, agents can understand, and agent capabilities can evolve over time.
From our perspective, a limited context window should be filled with distilled, retrieved, and precisely matched memory — not raw information stacked end to end.
Three-Layer Memory Architecture
In memU 1.0.0, we design a simple yet scalable three-layer memory architecture.
The design is inspired by layered storage systems in computer science: through step-by-step abstraction, messy and diverse data is turned into memory that an agent can understand, retrieve, and evolve over time.
The overall flow is: Resource Layer → Memory Item Layer → Memory Category Layer
Resource Layer. This is the raw data layer. It stores original multi-modal resources such as text, files, logs, conversations, code, images, and more. The focus here is completeness and traceability. No early abstraction is applied.
Memory Item Layer. This layer extracts discrete memory units from raw resources. Each memory item is the smallest meaningful unit that can be understood and referenced on its own. These items form the foundation for agent reasoning and retrieval.
Memory Category Layer (Memory Files). This is the aggregation layer. Multiple Memory Items are organized and merged into structured text memory files. Only these aggregated memory files are finally sent into the Agent’s context and used for decision-making and reasoning.
A Self-Evolving Memory Retrieval Loop
With this architecture, memory storage, organization, and retrieval are not isolated steps. They form a complete feedback loop across the three layers.
When new information enters the system, it is first stored in the Resource Layer in its original form.
From there, the system gradually extracts Memory Items with clear meaning and places them into appropriate Memory Category files based on the existing memory structure.
As memory moves upward, meaning becomes clearer and structure becomes more stable.
At the organization level, a Memory Category is not just a standalone file.
Different category files can reference or share Memory Items, forming connections that better reflect real-world task knowledge, rather than rigid and isolated classifications.
When an Agent performs a task, retrieval happens top-down.
The system retrieves memory at the Memory Category layer first. Each category corresponds to a complete aggregated memory file, and the entire retrieved file is injected into the context window.
When a memory has not been referenced for a long time, it may no longer appear at the category layer and is effectively “forgotten” at that level. In this case, the system falls back to retrieve from deeper layers. If the memory item is still not found, the original resource is always retrievable, since resources are never pruned or discarded.
This process does not rely on manually tweaking rules again and again.
Instead, continuous feedback from real usage allows the memory structure to gradually align with how the Agent actually works.
Through this cycle of store → retrieve → evolve, memory is no longer a static archive. It becomes a system that can correct itself and evolve, continuously supporting the Agent’s growth.
Two Retrieval Methods: LLM-Based and RAG
Built on top of this architecture, memU 1.0.0 provides two complementary memory retrieval methods:
LLM-based retrieval
The model directly reads memory files and original resources, enabling deep semantic understanding and reasoning.RAG-based retrieval
Fast vector embedding search, designed for high-performance and low-latency scenarios.
In memU’s design, RAG is an efficient baseline capability. However, for complex tasks, we recommend LLM-based deep retrieval.
Vector similarity retrieval is effective for surface-level relevance, but often fails to capture deeper semantics, structure, and relationships within memory files.
By allowing the LLM to directly “read” memory files, memU enables Agents to do more than just find memories — they can truly understand and use them.
Multi-Modal Support: Unified as Text Memory for Agents
memU’s three-layer architecture natively supports multi-modal data at the lowest level.
Text, code, logs, images, and other unstructured data are all ingested into the Resource Layer in their original form, fully preserved and traceable.
During later processing, this multi-modal data is gradually transformed into readable text memories and enters the Memory Item and Memory Category layers.
This is not a loss of multi-modal capability, but a deliberate engineering choice.
On one hand, today’s large models are strongest at understanding, reasoning, and generating text.
Unifying different modalities into text makes memory usage more stable during reasoning and decision-making.
On the other hand, a unified text format allows memory organization at higher layers to stay consistent.
Memory Category files can share the same structure without maintaining parallel systems for different modalities.
By preserving raw multi-modal data at the bottom, unifying memory as text at higher layers, and combining this with self-evolving retrieval and LLM-based reading, memU strikes a balance between completeness, clarity, and engineering simplicity.
This allows Agents to rely on a single, stable memory structure while learning from long-term experience across different modalities.
The memU Ecosystem Is Now Available
Alongside the core upgrade in memU 1.0.0, we have also open-sourced and released memU-server and memU-ui, completing the path from algorithms to real-world deployment.
memU: The core algorithm engine. It provides memory extraction, organization, and multi-strategy retrieval. memU can be used on its own or embedded into existing Agents or applications as the memory algorithm layer.
memU-server: A self-hosted backend service for memory data management. It supports full Memory CRUD operations, retrieval tracking, token usage and billing stats, user systems, RBAC permissions, and security boundaries. It is well suited for internal tools, research setups, and enterprise deployments.
memU-ui: A front-end dashboard designed to work with memU and memU-server. It offers visual memory browsing, data retrieval interfaces, and user management tools, making self-hosting and daily operations much easier for teams.
By combining memU, memU-server, and memU-ui, developers can either use only the core algorithms or quickly deploy a complete, self-hosted, and manageable Agent memory system.
This makes long-term memory a practical, maintainable part of real production systems.
Workflow Support and Task Execution Context
This release enhances memU’s built-in workflow support across the algorithm layer, backend, and frontend.
Tasks can be modeled as workflows with ordered steps.
At each step, memory can be written, updated, and retrieved in context, allowing memory to evolve alongside task execution rather than being stored as a flat final result.
Workflow support also allows prompts to be modified and highly customized per scenario, making it easier to adapt Agent behavior to different task structures and execution needs.
Each workflow maintains detailed execution logs, enabling developers to understand how a task progresses, inspect what happens at each step, and debug complex or long-running workflows more effectively.
Memory files can be associated with specific workflow steps and execution moments, supporting step-based inspection and clearer temporal understanding of how memory is produced and used.
By integrating workflows end to end, memU brings memory, execution context, and Agent behavior into a single structured process, instead of treating them as separate systems stitched together.
User Model and User Context Awareness
In the new version, memU now supports clear separation of user models and user context.
Developers can define different user models for different users, and memU keeps memory writing and retrieval strictly scoped to the current user.
This prevents memory from leaking across users and ensures that Agents respond using the correct personal history.
When memory is written, memU records which user it belongs to.
When memory is retrieved, the system always checks the active user context before returning results.
This is essential for multi-user products such as assistants, copilots, and internal tools, where memory must stay personal, predictable, and safe.
By handling user context explicitly, memU makes personalized long-term memory easier to reason about and easier to operate as the system grows.
Database Storage and Schema Evolution
This version improves memU’s database-backed storage for memory data, making it more robust for long-lived Agent systems.
memU uses PostgreSQL as its primary storage backend, with optional pgvector support for vector search.
Memory data is organized into structured tables covering resources, memory items, memory files, and their relationships, enabling clearer inspection and management.
A new internal schema evolution mechanism has been introduced.
As memU continues to add features and refine its memory model, the package now maintains its own upgrade strategy to ensure that existing memory data remains compatible across versions.
This makes version upgrades safer and more predictable, while allowing application developers to handle their own data transformations when needed.
With a more reliable storage layer and controlled internal upgrades, memU can now better support continuous iteration and production-scale Agent workflows.
Looking Ahead
memU 1.0.0 is not an endpoint — it is a new starting point.
What matters to us is not how much memory can be stored, but whether memory is truly used, understood, and shaped by real Agent work.
Going forward, we will continue refining memory structure, retrieval methods, and system boundaries based on real Agent scenarios.
Our goal is to make long-term memory a reliable foundation that every Agent can depend on.
If you are struggling with memory selection, organization, or evolution while building Agents, feel free to reach out.
We would love to hear about real memory challenges from real use cases.
You can find more about MemU on:
GitHub (⭐️ Star us): https://github.com/NevaMind-AI/memU
Official website: https://memu.pro
Discord: https://discord.gg/memu
X: https://x.com/memU_ai
Medium: https://medium.com/@memU_ai
YouTube: https://www.youtube.com/channel/UCv4ivxu9RImsTBkIwnE59uw
✉️Email: contact@nevamind.ai
Top comments (1)
Liked the idea of multi layered retrieval approach and the idea of evolution...The concept mimics how human memory works.. Suppose we wanted to find something, if we can't recollect, we go deep. Suppose we found the thing after deep search, next time retrieval is easy since the deep search retrieval became another print in memory. The approach implemented is very similar. I liked it.