Feature: Cross-agent shared memory namespaces with conflict resolution

[cdzzy]

Problem

In multi-agent systems, multiple agents often need to share knowledge (e.g., a research agent and a writer agent both need access to the same context). Currently there's no standard pattern for shared vs. private memory in agent frameworks.

Proposed Solution: Memory Namespaces

// Private namespace (default) -- only this agent reads/writes
const privateMemory = new Engram({ agentId: "research-agent", namespace: "private" })

// Shared namespace -- all agents in the same session can read
const sharedMemory = new Engram({ agentId: "research-agent", namespace: "shared:session-001" })

// Team namespace -- agents with the same team ID share memories
const teamMemory = new Engram({ agentId: "research-agent", namespace: "team:writing-crew" })

Conflict Resolution Strategy

const memory = new Engram({
  namespace: "shared:session-001",
  conflictPolicy: "last-writer-wins",  // or "merge", "version", "ask-llm"
  onConflict: async (existing, incoming) => {
    // Custom merge logic
    return await mergeLLM(existing.content, incoming.content)
  }
})

Use Cases

• Multi-agent pipelines: researcher passes findings to writer via shared memory
• Parallel agents: coordinate without redundant work
• Persistent sessions: multiple chat sessions sharing user preference profiles

Prior Art

Redis namespaces, PostgreSQL row-level locking, CRDTs for distributed state.

[m13v]

the namespace approach makes sense but the conflict resolution is where things get tricky in practice. we built a shared knowledge layer for multiple agents and the "last-writer-wins" policy sounds clean until two agents write contradictory observations about the same entity 30 seconds apart. what actually worked for us was versioning everything and letting a retrieval layer handle conflicts at read time - rank results by recency, confidence score, and source agent. that way you never lose data from merges gone wrong. the "ask-llm" conflict strategy is interesting but be careful with latency there, we tried something similar and the LLM calls for merge resolution added 500ms+ per write which killed throughput when agents were writing frequently. for the team namespace use case, a simpler approach might be append-only with semantic dedup at query time. each agent writes freely, and when you recall, you cluster similar memories and return the most recent from each cluster.

[m13v]

we open-sourced our embeddings and retrieval ranking layer that handles this kind of multi-source memory dedup: https://github.com/m13v/ai-browser-profile/blob/main/ai_browser_profile/embeddings.py - the scoring approach there evolved from dealing with exactly these namespace collision problems across multiple data sources.

[kinthaiofficial]

Clean API design. The namespace pattern with configurable conflict policies is exactly right. We run shared memory namespaces at KinthAI across 221 agents and have production experience with each conflict policy:

Conflict policy comparison from production:

Policy	Good for	Failure mode
last-writer-wins	Append-only data (events, logs)	Silently drops correct older data
merge	Compatible updates (additive lists)	Produces incoherent merged text
version	Audit trails	Unbounded growth, retrieval confusion
ask-llm	Nuanced conflicts	Expensive, non-deterministic, can hallucinate a 'merge'

Our recommendation: don't pick one globally — pick per memory type:

• Facts (entity attributes): version + expiry. Old versions decay via importance × 0.95^days
• Events (things that happened): append-only, no conflicts possible
• Preferences (user/agent settings): last-writer-wins with source priority (human > agent)
• Decisions (agreed plans): version with explicit supersede marker

The shared session namespace (shared:session-001) has a lifecycle problem:

What happens when the session ends? Shared memories don't just disappear — some should be promoted to persistent team memory, others should be discarded. We add an on_session_end hook that runs importance scoring on all shared memories and promotes the top N% to the team namespace.

For parallel agents preventing redundant work:

The shared namespace needs a lightweight locking mechanism. When Agent A starts researching topic X, it writes a claim:topic-X entry to shared memory. Agent B checks for claims before starting its own research. Simple but prevents 90% of duplicate work.

Architecture: OpenClaw Multi-Tenancy: Why VM-per-User Doesn't Scale