Memory for AI agents is a growing space. Here's how memnos fits in — and what makes it different for developers and engineering teams. The short version: memnos is self-hosted, MCP-native, and ships as a single Docker container with no external database or API key required.
✓ = supported ✗ = not supported ~ = partial or limited support
| Capability |
memnos
|
mem0 | Zep | Graphiti | Letta / MemGPT | LangMem | Obsidian+Claude | ChatGPT Memory |
|---|---|---|---|---|---|---|---|---|
| Memory Layer | ||||||||
| Multi-agent shared memory | ✓ | ✗ | ~ | ~ | ~ | ~ | ✗ | ✗ |
| Temporal memory (as_of queries) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Knowledge graph (not just vector) | ✓ | ✗ | ✗ | ✓ | ~ | ✗ | ✗ | ✗ |
| 7 typed memory kinds | ✓ | ~ | ~ | ✗ | ~ | ~ | ✗ | ✗ |
| Constraint auto-injection on search | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Governance & Security | ||||||||
| Complete audit trail with provenance | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Namespace-based ACLs | ✓ | ✗ | ~ | ✗ | ✗ | ~ | ✗ | ✗ |
| Encrypted secret vault | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Architecture enforcement (corpus CI) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Infrastructure & Integration | ||||||||
| Single container, zero external DB | ✓ | ~ | ~ | ~ | ~ | ✗ | ✓ | ✗ |
| MCP-native (works with any MCP client) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Real-time pub/sub (SSE / webhook) | ✓ | ✗ | ~ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Multi-model / multi-LLM support | ✓ | ✓ | ✓ | ~ | ✓ | ✓ | ~ | ✗ |
| Python SDK for agent frameworks | ✓ | ✓ | ✓ | ~ | ✓ | ✓ | ✗ | ✗ |
| Open source / MIT license | ✓ | ✓ | ~ | ✓ | ✓ | ✓ | ✗ | ✗ |
~ indicates partial or limited support. Information based on public documentation and known capabilities as of 2026.
mem0 is a per-user memory layer for individual AI assistants. memnos is organizational memory for multi-agent engineering teams. These are different products solving different problems.
Per-user memory for individual AI assistants
Organizational memory for AI engineering teams
The fundamental difference: mem0 remembers what you told it. memnos stores what your team built, decided, and learned — shared across every agent, governed, audited, and enforced. Different scope entirely.
Zep focuses on long-term memory for individual AI assistants, primarily through conversation history summarization. memnos stores typed organizational knowledge with governance.
Conversation memory
Zep stores and summarizes chat history efficiently. For a single AI assistant that needs to remember previous conversations, Zep works well.
Long-term user preferences
Zep extracts entities and facts from conversations and persists them across sessions for a single user's AI assistant.
Typed knowledge, not summaries
memnos stores typed memories — decisions, constraints, incidents, ADRs. Not chat history summaries. The distinction matters for architecture governance and incident intelligence.
No temporal memory in Zep
memnos's as_of temporal queries have no equivalent in Zep. "What did we know about the auth service on March 15th" is a uniquely memnos capability.
Multi-agent coordination
Zep has no real-time multi-agent coordination mechanism. There's no pub/sub, no cross-agent event stream, no way for one agent's discovery to reach another agent in real time.
Architecture enforcement
Zep has no concept of typed constraint nodes, corpus ingestion, or CI pipeline enforcement. It cannot check a PR diff against your architecture documentation.
LangMem is LangChain's long-term memory toolkit for LangGraph agents. memnos is a standalone MCP-native memory server. They solve overlapping problems with different trade-offs.
Long-term memory for LangGraph agents
MCP-native memory for any LLM client
memnos-sdk[langchain]When to pick LangMem: you are already on LangGraph, your stack is Python, and you are comfortable managing a Postgres (or similar) database. LangMem integrates tightly with LangGraph's execution model.
When to pick memnos: you use Claude Code, Cursor, or any MCP client. You want memory to work across frameworks — LangChain, LlamaIndex, or direct API — without managing a separate database. One container, no database, no extra API key.
This is the most common current approach for teams using Claude Code. Markdown notes in Obsidian, CLAUDE.md files in repos. It works — for a while. Here's where it breaks down at scale.
| Dimension | Obsidian + CLAUDE.md | memnos |
|---|---|---|
| Who writes the memory | You, the human — manually | AI agents write as they work, automatically |
| Stays current | Decays — requires manual upkeep; outdated in weeks | Self-updating — agents write every session |
| Multi-agent shared | No — each agent reads its own CLAUDE.md snapshot | Yes — all agents read the same live graph |
| Temporal queries | No — there is no "as of March 15th" for markdown files | Yes — every node carries valid_from / valid_until |
| Architecture enforcement | No — CLAUDE.md can suggest; it cannot block a PR | Yes — corpus.check_all() enforces in CI |
| Audit trail | Git blame on the markdown file — no agent attribution | Every write: agent_id, tool, git_commit, ticket, timestamp |
| Access control | File system permissions — no granular ACLs | Namespace ACLs per API key — surgical control |
| Real-time coordination | No — files are read at session start, static thereafter | SSE / webhook push — agents know in milliseconds |
The fundamental difference
"Obsidian is a notebook you manage. You are the librarian. memnos is a living knowledge graph the team builds together — where AI is also a contributor. The former scales with your discipline. The latter scales with your team's activity."
For a solo developer or a very small team that is disciplined about maintaining markdown notes, Obsidian + CLAUDE.md is a reasonable starting point. It has zero infrastructure overhead and works well for a single user's Claude Code context.
Team > 3 people
Notes diverge. CLAUDE.md files proliferate. No one knows which version is canonical. Agents get contradictory instructions from different files.
Multiple AI agents
Agent A's CLAUDE.md is different from Agent B's. They make inconsistent decisions because they read different context snapshots.
Any compliance requirement
There is no audit trail, no governance, and no way to prove which AI agent made which decision. Compliance requires more than git blame on a markdown file.
These aren't features — they're capabilities that exist nowhere else in the AI memory tooling ecosystem.
Query the knowledge graph as of any past date. Know what your team knew on March 15th. Track how understanding evolved. Watch when a decision was superseded and by what.
# What did we know about auth on March 15?
results = await client.search(
"authentication strategy",
as_of="2026-03-15",
namespace="org:acme:engineering",
)Only memnos supports this.
Ingest your docs as constraints. Every agent's code is automatically checked against your architecture at search time and in CI. This is governance, not just memory — rules that enforce themselves.
# Enforce in CI — no manual review
result = await client.corpus.check_all(
code=pr_diff,
context="auth service",
)
if result[0].shall_violations:
sys.exit(1)Only memnos supports this.
Every memory write carries agent_id, tool, git_commit, and ticket. In an AI-assisted world, know exactly which agent made which decision and why. Forever queryable. Compliance-grade provenance.
# Query by agent — who made this?
decisions = await client.query(
memory_type="decision",
provenance__agent_id="arch-agent-01",
provenance__ticket="ARCH-42",
)Only memnos supports this at team scale.
Self-host with Docker in 90 seconds. MIT licensed. No lock-in. If you're running AI-assisted engineering at any scale, your team needs a memory layer built for teams — not individuals.