MemOS 2.0 Stardust
Persistent, manageable memory for AI applications and agents.
Per-dimension scores and reasoning
Evidence shows: README suggests keeping API keys server-side, but no explicit least-privilege principle; install script directly executes curl | bash without user confirmation; data flow description incomplete, not explaining how data is collected, stored, and shared; sensitive data handling not detailed; dependencies have version ranges but no security audit; external effects (e.g., network requests) not explicitly stated; rollback mechanism not mentioned; publisher identity unverified, but code has clear authors and contact. Deductions: lack of explicit least-privilege, user confirmation, data flow transparency, sensitive data handling, dependency security audit, external effects description, rollback mechanism, and source attribution evidence.
Evidence shows: README and code descriptions are mostly consistent, but some inconsistencies (e.g., version number in pyproject.toml is 2.0.27, but README does not specify); dependencies have version ranges but availability not verified; error messages partially present in tests, but overall lack of detailed failure handling documentation. Deductions: minor inconsistency in self-consistency, dependency availability unverified, failure messages not comprehensive.
Evidence shows: README clearly defines target audience (AI assistants, customer support, personalized agents, etc.) and use cases; capability boundaries described in feature list but not explicitly limited; trigger conditions (e.g., auto-recall) present in tests but not detailed in docs; environment fit (e.g., Docker, local install) described. Deductions: capability boundaries and trigger precision not precise, environment fit not covering all platforms.
Evidence shows: README structure clear, with quick start, feature list, performance data; install notes detailed, including Docker and local; naming stable (e.g., MemOS, memos-local-plugin); examples and FAQ links present; known limitations not explicitly listed; license Apache-2.0; version number in pyproject.toml but no changelog; maintenance responsibility indicated via community links. Deductions: known limitations not explicit, versioning changelog missing.
Evidence shows: output usability demonstrated in examples, but actual output quality not evaluated; marginal value shown in performance data, but not compared with existing solutions; cost-benefit not analyzed in detail. Deductions: lack of in-depth evaluation of output quality, marginal value, and cost-benefit.
Evidence shows: performance data listed in README, but no raw data or reproduction method; cross-source corroboration insufficient, relying only on own docs; facts and inferences not clearly separated. Deductions: lack of traceable verification evidence, cross-source corroboration insufficient, facts and inferences mixed.
- Install script executes remote code directly, posing supply chain risk; review before running.
- API keys should be kept strictly confidential to avoid leakage.
- Performance data lacks reproduction method; treat with caution.
What does this agent do, and when should you use it?
MemOS is a memory operating system for LLMs and AI agents, exposing operations to store, retrieve, and manage long-term memory. It represents memory as an inspectable, editable graph and supports text, images, tool traces, and personas in one memory system. Its self-hosted REST service can run through Docker alongside Neo4j and Qdrant, or through uvicorn when those dependencies are already running. The repository also includes an OpenClaw cloud plugin and a local plugin for Hermes Agent and OpenClaw; the latter uses SQLite with FTS5 and vector retrieval. It fits teams that need durable user or task context across runs, provided they are comfortable either managing infrastructure or using a cloud API key.
In cloud mode, an application sends user_id, conversation_id, and messages to https://memos.memtensor.cn/api/openmem/v1/add/message, then queries /search/memory with query and user_id. In self-hosted mode, it creates a memory cube through /product/create_cube, writes messages through /product/add with writable_cube_ids and async_mode, and searches through /product/search with readable_cube_ids to scope access. MemScheduler can execute memory operations asynchronously, and the system describes natural-language feedback for correcting, supplementing, or replacing stored memories. The OpenClaw cloud plugin recalls cloud memories before each agent run and saves new messages afterward; the local plugin persists data in SQLite and performs hybrid FTS5-plus-vector retrieval on the device.
- A customer-support application team that needs to retain a user’s prior tickets and conversations under a user_id.
- A developer building a multi-agent workflow that needs separate or selectively shared memory cubes for users, projects, and agents.
- An engineering team that must operate the memory service on its own infrastructure with a REST API boundary.
- An OpenClaw user who wants cloud-backed memory injected before runs and saved after runs without operating the backend.
- A Hermes Agent or OpenClaw user who needs on-device persistence through the local SQLite-based plugin.
What are this agent's strengths and limitations?
- One API covers adding, retrieving, editing, and deleting memory, with an inspectable and editable graph representation.
- The self-hosted deployment boundary is explicit: Docker starts the MemOS API together with Neo4j and Qdrant.
- It offers four documented delivery paths: hosted cloud, self-hosted service, an OpenClaw cloud plugin, and a local SQLite-based plugin.
- The local plugin combines FTS5 keyword search with vector retrieval and documents multi-agent collaboration plus tiered skill evolution.
- Self-hosting depends on Neo4j and Qdrant; non-Docker deployment requires both services to be running already.
- Cloud adoption requires creating and protecting a MemOS API key, and cloud-mode data resides in MemOS Cloud.
- The local plugin is explicitly for an existing OpenClaw or Hermes installation and requires Node.js.
- The supplied material does not specify an MCP endpoint, MCP configuration flow, or a verified provider-adapter matrix.
How do you install or deploy this agent?
Self-host with Docker:
git clone https://github.com/MemTensor/MemOS.git
cd MemOS
cp docker/.env.example .env
cd docker
docker compose upFill in the required API keys in .env; the API is served at http://localhost:8000. Without Docker, start Neo4j and Qdrant first, then run:
cd MemOS/src
uvicorn memos.api.server_api:app --host 0.0.0.0 --port 8000 --workers 1For cloud use, create an mpg- prefixed API key in the MemOS dashboard and keep it server-side. Install the OpenClaw cloud plugin with:
openclaw plugins install @memtensor/memos-cloud-openclaw-plugin@latest
openclaw gateway restartThe local plugin requires Node.js and an existing OpenClaw or Hermes installation.
How do you use this agent?
After starting the self-hosted service, POST cube_name, owner_id, and cube_id to http://localhost:8000/product/create_cube. POST user_id, writable_cube_ids, messages, and async_mode to /product/add, then POST query, user_id, and readable_cube_ids to /product/search. For the hosted API, make the first write to /api/openmem/v1/add/message with Authorization: Token mpg-... and Content-Type: application/json, then call /api/openmem/v1/search/memory with query and user_id.