The author reflects on challenges in multi-user agentic memory, emphasizing the need for architectural boundaries between private and shared memory sessions, and discusses building an open-source project to address this.
Our bachelor's thesis was on multi-user agentic memory, and I spent about a year working on it. Going in, I assumed the hard part was persistence: storage, recall, retrieval quality, deciding what should become memory, etc. I don't think that's the hard part anymore. AI memory has gotten remarkably good at persistence. The problem we kept running into was simpler: My agent remembers. My teammate's agent remembers. But they don't remember together. So we write a handoff document for assistants that already saw the work happen, paste context between sessions, or hold a meeting to explain what happened. To be clear, shared/team memory already exists. Good work is happening across both commercial and open-source projects. But most implementations I've found treat collaboration primarily as a shared memory/knowledge layer with access controls. What I haven't been able to find is a branchable multi-user session. Something like: shared session → private branch → independent agent work → selectively merge context back Alice could take context from the team's session into a private Claude Code session. Bob could independently branch into Codex. Neither needs access to the other's private work. Both can selectively contribute results, decisions, or context back to the shared session. Different humans. Different agents. Private branches. Shared continuity. Two things surprised me while working on this. Attribution gets weird quickly. Once multiple humans use different agents, "who contributed this?" and "which agent produced this?" become separate questions. Human identity, agent identity, session identity, and provenance need to survive independently. The private/shared boundary needs to be structural. I don't think "private" should mean "it's in the same memory store, but our retrieval query filters it out." One bad query or permission bug and private context becomes shared context. So I'm increasingly convinced that private and shared memory need an architectural boundary, with explicit contribution across it rather than implicit retrieval restrictions. Full disclosure: I'm now building our thesis work into an Apache-2.0 open-source project, so I obviously have a horse in this race. I'm not linking it here because I don't want this to be a disguised promo post. What I'm actually trying to falsify is the premise: Does something already implement this shared → private branch → selective merge model across multiple humans and different coding agents? And for people working on teams with Claude Code, Codex, Cursor, Copilot, etc.: What carries a decision from one person's agent session into another person's session today? A doc? Slack? Copy/paste? Shared memory? Some internal tooling? I'm particularly interested in setups that are already working well, because those are probably the best counterexamples to what I'm building.
Building multi-agent systems reveals that managing shared memory and context consistency is more challenging than orchestration. The author's experiment using Statewave treats memory as an evolving lifecycle rather than a retrieval problem.
A developer shares a prototype memory architecture for multi-agent systems with separate storage for episodic, semantic, and procedural memories and intent-based retrieval, seeking feedback on scalability and design choices.
A developer discusses alternatives to the agentmemory library for multi-agent memory systems in coding agents, comparing Mem0 and ByteRover, and asks for confirmations on Opencode and Pi.
The authors developed a collaborative multi-agent memory system with shared/private memory scopes, trust-aware retrieval, lineage tracking, and contradiction resolution, and submitted a paper to a conference.
This paper presents a systematic experimental study of agent memory systems from a data management perspective, decomposing memory into four core modules and evaluating 12 representative systems across 11 datasets, finding no single architecture dominates and highlighting cost-performance trade-offs.