How we use Dakera for multi-agent memory in production

[ferhimedamine]

Hey 👋 — I'm the creator of Dakera, and wanted to share how we actually use it in production to give our AI agents persistent memory across sessions.

The problem

We run 9 autonomous AI agents (CEO, CTO, Core Engine, Platform, SDK, QA, etc.) that each need to:

• Remember decisions and context across sessions (sometimes days apart)
• Share knowledge with each other without direct coupling
• Have memory that naturally decays — old context fades unless reinforced
• Search memories by meaning, not just keywords (hybrid BM25 + vector)

The setup

Single docker-compose.local.yml → one Dakera server handling all 9 agents. Each agent has its own namespace, but they can read each other's memories for cross-team coordination.

git clone https://github.com/dakera-ai/dakera-deploy
cd dakera-deploy/docker
docker compose -f docker-compose.local.yml up -d

What makes it work

1. Decay-weighted importance — memories at importance 0.5 naturally fade over weeks, while 0.9+ memories persist. Agents don't accumulate noise.
2. Session grouping — each agent run opens a session. At recall time, session context helps the engine prioritize recent-session memories.
3. Hybrid search — BM25 handles exact matches (API names, error codes), HNSW handles semantic queries ("what did we decide about the auth flow?").
4. Knowledge graph — entity extraction builds connections between memories automatically. "PR #502" links to "CI failure" links to "OOM fix".

Results

88.2% on the LoCoMo benchmark (1,540 questions testing temporal reasoning, multi-hop retrieval, and event ordering). In practice, agents recall decisions from weeks ago and build on each other's work.

Happy to answer questions about the setup, configuration, or scaling. If you're building multi-agent systems and need persistent memory, I'd love to hear about your use case.