Hi Lounge, I'm Henry, maintainer of mcp-memory-service

I'm Henry, based in Switzerland. Day job is Senior Technical Consultant and Devops Engineer at DMI, mostly Azure, infrastructure migrations and the JiVS platform. Evenings and weekends go into mcp-memory-service, an open-source memory layer for AI agents.

The problem is simple to state. Every new Claude, Codex or LangGraph session starts with amnesia, and you end up pasting the same context into it for the hundredth time. mcp-memory-service gives agents a persistent memory they can write to and search: semantic search over local embeddings (ONNX, all-MiniLM-L6-v2), a knowledge graph of how memories relate, and a background consolidation job that decays, clusters and forgets, loosely modelled on how sleep works.

Where it stands today:

• Started December 2024, now at v12.3.1, Apache 2.0
• 2,040 stars, 361 forks, 100+ contributors on GitHub
• Speaks MCP for Claude Desktop and Claude Code, plus a REST API for agent frameworks
• Storage: SQLite-vec locally (around 5 ms reads), Cloudflare D1 and Vectorize, or a hybrid of both
• v12 added a sync hub, so several machines share one memory without a cloud in the middle

My bias is data sovereignty. Your agent's memory is a record of how you work and think, and it should live on hardware you control. Cloud sync is optional, not the default.

Honest part: storing memories was the easy bit. Retrieving the right one at the right moment and forgetting the noise is still where most of my time goes. We also learned the expensive way that a careless sync loop can read 19 million rows a day from D1.

What I'm looking for:

• People running agents in production who hit the memory wall: what you keep, what you throw away, and why
• Contributors, especially around retrieval quality and benchmarks (LoCoMo, LongMemEval)
• Swiss and D-A-CH builders to swap notes with over a coffee in or around Konstanz/Kreuzlingen

Repo: github.com/doobidoo/mcp-memory-service Site: mcpmemory.services