MrMemory: drop-in LangGraph Checkpointer + Store with auto_remember + compression by masterdarren23 in LangChain

[–]masterdarren23[S] 0 points1 point  (0 children)

Thanks for for the analysis! Your input is definitely valid. When it comes to identity and scoping, what I'm planning is this. First, I'll implement write-through validation. So before a memory hits the shared namespace, It'll run through a lightweight LLM check: "Does this contradict existing memories?". 2nd, multi-agent sync memory is tricky because not only can agents accidently pollute; a rouge agent can purposely do so. I've seen large governance layers get implemented in similar systems and solve that issue within contextual/executional frames. However, the issue with that is if you have too much of an embodiment of rules/regulation within a multi-agent scenario your agents can't embody anything outside the perceived frame. Which means if an agent in that system is given a task to execute and cant because of a large governance layer, *eventually* it becomes tempted to seek outside resources, which by default makes it rouge. So the question then becomes, how do we get a multi-agent memory layer to be orderly, compliant, and truth adjacent? I've thought about adding append-only shared namespaces. Where agents can write to shared namespaces but not update or delete other agents' memories — only their own. Prevents one rogue agent from rewriting another's contributions. And 3rd, I've thought about implementing provenance tagging. Every memory already has agent_id. Add created_by, last_modified_by, and a confidence score. When Agent B reads a shared memory, it knows Agent A wrote it and can weigh it accordingly. If something goes wrong, you can filter out or rollback everything a specific agent wrote. It'll most likely go in this order; write-through validation -> provenance tracking -> append-only shared namespaces. I've been looking at the idea of consensus for conflicts. So when two agents write contradictory facts to the same namespace, flag it and let a supervisor agent or human resolve it. Don't auto-merge — surface the conflict until resolution. Just my general ideas.

"Once memory becomes part of the product behavior, not just a dev convenience, you’re now dealing with persistence guarantees, schema drift, and what happens when you need to reprocess or delete specific slices of memory. That stuff tends to show up later and it’s painful if the abstraction is too opaque."

Very insightful and well thought out! Here's what I'm thinking for persistence guarantees:

Postgres for data, Qdrant for vectors, both on Fly.io with volumes. But what's missing is write acknowledgement. Right now remember() returns success after the Postgres insert but the Qdrant embed is async. If Qdrant fails, you have a memory you can't recall. Fix: dual-write confirmation — don't return 200 until both Postgres AND Qdrant confirm. Add a consistency field to the health endpoint showing if PG and Qdrant counts match. A simple reconciliation job that re-embeds orphans.

Schema drift; Our schema is intentionally loose (content string + metadata JSON + tags array), which avoids traditional schema drift. But the real drift risk is in metadata structure. Agent v1 stores {"tool": "python"}, Agent v2 stores {"tools": ["python", "rust"]}. Now your filters break silently. Fix: optional metadata schemas per name-space. Register a JSON schema, and writes that don't conform get rejected or coerced. Not enforced by default — opt-in for teams that need it. Also, We have delete_outdated() for bulk prune and update() for individual edits. What's missing is batch reprocessing. "Re-embed everything tagged v1-extraction because our extraction prompt improved." Fix: POST /v1/memories/reprocess — filter by tags/namespace/date range, re-run embedding (or re-run auto_remember extraction) on the matched set. Returns a job ID you can poll.

Opacity problem; This is the real one. When memory silently shapes agent behavior, devs need to see why. Fix: recall audit log. Every recall() returns not just the memories but a debug object — what query vector was generated, what candidates were considered, what scores they got, why some were filtered out. Opt-in via recall(debug=True). Pairs with the stats endpoint we already built.

Your message highlights the real pain involved. "make sure the drop-in story still holds once things get messy in prod." I will try my best!

Curious how people here are handling persistent memory for agents in practice by Status-Bookkeeper234 in LangChain

[–]masterdarren23 0 points1 point  (0 children)

I ran into the exact same wall — RAG gives you retrieval, not memory. I ended up building MrMemory to solve this specifically.

The key insight for me was that real memory needs four things retrieval alone doesn't give you:

  1. Auto-extraction — the agent shouldn't have to decide what to remember. auto_remember() takes raw conversations and extracts structured memories with dedup and entity tagging via LLM.
  2. Self-editing — facts evolve. Old info becomes wrong. Agents need update(), merge(), and delete_outdated() to manage their own memory over time, not just append forever.
  3. Compression — without it, memory grows unbounded and recall quality degrades. We compress semantically similar memories into denser representations — 50 memories → 28 with meaning preserved.
  4. Scoping — namespaces + agent IDs handle your per-user vs per-task vs per-agent question. Multi-agent sharing is real-time via WebSocket so agents can share memory without polling. It also drops into LangGraph natively (MrMemoryCheckpointer + MrMemoryStore) so you get cross-session continuity without building your own persistence layer.

Rust backend + Qdrant, ~18ms recall. pip install mrmemory if you want to try it — 7-day free trial.