Key points
agentmemory is a memory engine + MCP server that gives AI coding assistants persistent, searchable long-term memory. It runs locally (default 127.0.0.1:3111), auto-captures agent behavior via hooks, and injects relevant context at the start of each new session.
The problem: session-level amnesia
Current assistants (Claude Code, Cursor, Copilot CLI, Codex) lose all context when a session ends. Vendor stopgaps—Claude Code's MEMORY.md (200-line cap, manually maintained), Cursor's notepads, Cline's memory bank—share the same flaws:
- Capacity bottlenecks (a few thousand tokens at most)
- No search (everything loaded into context)
- Manual maintenance
- Per-agent isolation (no cross-tool sharing)
- No memory evolution (no forgetting or reinforcement)
- 16+ supported tools: Claude Code (native plugin + MCP + 12 hooks), Codex CLI, GitHub Copilot CLI, Cursor, Gemini CLI, OpenClaw, Hermes, OpenCode (22 hooks), Cline/Roo Code/Kilo Code, Windsurf, Goose, Aider (REST API), Claude Desktop, Warp, pi. One shared memory server means decisions made in Claude Code are visible to Cursor.
- 53 MCP tools: core tools (
memory_recall,memory_smart_search,memory_save,memory_sessions,memory_profile,memory_file_history) plus consolidation, team sharing (team_share,team_feed), multi-agent coordination (lease,signal_send,mesh_sync), workflows, audit, and health/diagnosis tools. Most competing memory MCPs offer only 5–10 tools. - Project: agentmemory (author: Rohit Gupta)
- GitHub: https://github.com/rohitg00/agentmemory
- Engine: https://iii.dev
- Deployment: self-hosted by default (127.0.0.1); supports Fly.io/Railway/Render/Coolify
- Benchmark: LongMemEval-S R@5=95.2%, R@10=98.6%, MRR=88.2%
As creator Rohit Gupta puts it: "You explain the same architecture every session. You re-discover the same bugs. You re-teach the same preferences."
Four-layer memory architecture (brain-inspired)
| Layer | Content | Brain analogy | Implementation | |---|---|---|---| | Working memory | Raw observations (tool call inputs/outputs) | Short-term memory | SQLite raw storage, 5-min dedup window | | Episodic memory | Session summaries | Event memory | LLM-compressed narratives | | Semantic memory | Extracted facts/patterns ("project uses jose, not jsonwebtoken") | Knowledge base | Structured facts + concept extraction | | Procedural memory | Workflows and decision habits | Skills/habits | Pattern detection + workflow records |
Memory lifecycle: PostToolUse hook → SHA-256 dedup → privacy filtering (API keys/secrets stripped) → raw storage → LLM compression → vector embedding (6 providers + local) → BM25 + vector indexing. Stop/SessionEnd hooks generate session summaries and knowledge-graph extractions; SessionStart hooks load project profiles and run hybrid retrieval with a token budget (default 2000 tokens). Memories follow an Ebbinghaus-style decay: frequent access reinforces weight, stale memories expire via TTL/importance eviction, and contradictions are detected and resolved.
Three-stream hybrid retrieval
| Stream | Strength | Weakness | |---|---|---| | BM25 (stemming + synonyms) | Exact matching, fast | No semantic understanding | | Vector (dense embeddings) | Semantic/conceptual search | May miss specific terms | | Graph (entity matching + BFS) | Relational reasoning | High build cost |
Fusion uses Reciprocal Rank Fusion (RRF, k=60) plus session diversification (max 3 results per session).
LongMemEval-S benchmark: R@5 95.2%, R@10 98.6%, MRR 88.2% (independently measured), vs. BM25-only fallback 86.2% / 94.6% / 71.5%. Other systems (mem0 at 68.5%, Letta/MemGPT at 83.2% on LoCoMo) come from their own papers and are not direct comparisons.
Token efficiency: ~170K tokens/year (~$10; $0 with local embeddings) vs. ~650K with LLM summaries (~$500) or 19.5M+ for full context—roughly 92% savings from precise retrieval.
Zero-friction capture via 12 hooks
SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PostToolUseFailure, PreCompact, SubagentStart/Stop, Stop, and SessionEnd hooks capture everything automatically—no manual add() calls required (unlike mem0).
Tech stack: iii engine
agentmemory avoids Postgres/Redis/Express/pm2 in favor of the iii engine (https://iii.dev): SQLite + iii-state KV replaces Postgres, iii-stream WebSocket replaces Redis, iii function routing replaces Express, iii-observability OTEL replaces Prometheus. The built-in viewer (port 3113) exposes OTEL traces, editable KV entries, and replayable triggers.
Integration and tooling
Competitive comparison
vs. mem0 (manual add(), vector+graph, external Qdrant/pgvector), Letta/MemGPT (full agent runtime, framework lock-in, Postgres required), and built-in MEMORY.md (static, no search): agentmemory's edge is zero manual capture + three-stream retrieval + cross-agent sharing + self-hosting + full memory lifecycle management (~1,900 tokens/session vs. 22K+ for MEMORY.md at 240 observations).
Privacy and security
Local-first (127.0.0.1 by default), automatic secret stripping and <private> tag filtering, SHA-256 dedup, optional HMAC authentication for remote deployment, and full audit trails.
Limitations and risks
1. Requires the iii-engine binary (v0.11.2); weak Windows support 2. Some hooks are Claude Code-specific; other agents capture less detail 3. Inaccurate retrieval can inject stale context and cause hallucination 4. Memory database may grow large on long-running projects 5. Team sharing (namespaced + private memories) needs careful permission configuration
Verdict
agentmemory upgrades AI coding assistant memory from "static sticky notes" to a "dynamic database"—auto-captured, intelligently compressed, precisely retrieved, naturally forgotten. Its value lies not in any single technique (BM25, vector search, and knowledge graphs are all mature) but in combining them into a zero-friction, self-hosted, cross-agent memory system. When code-generation capabilities converge across frontier models, context management across sessions may be the decisive differentiator for AI coding tools.
---
References