Memory Types · Multi-agent
Shared Memory in Multi-Agent Systems
Shared memory in multi-agent systems lets multiple AI agents read and write a common memory store — enabling coordination, shared context and collective learning, with consistency challenges to manage.
Shared store
Definition
What is shared (collective) agent memory?
A common store accessible by an agent pool — team knowledge, shared task state, customer records — vs per-agent private memory.
Collective memory enables agent teams to build on each other’s work: a research agent writes findings, a writing agent reads them, a reviewer agent adds corrections — all through one memory layer. Also called multi-agent memory store or team memory.
Disambiguation
OS “shared memory” vs agent shared memory
This page is about AI agents sharing a memory layer — not Python multiprocessing.shared_memory or Linux IPC shared memory.
Queries for “python shared memory” and “linux shared memory” refer to operating-system inter-process communication — a different topic entirely. Here we mean multiple LLM agents reading and writing a common semantic or graph memory store.
Patterns
Patterns for multi-agent shared memory
| Pattern | How it works | Pros / cons |
|---|---|---|
| Shared vector store + namespace | One collection; filter by agent_id | Simple; needs conflict handling |
| Shared graph + provenance | Edges tagged with writing agent | Audit trail; Zep/Graphiti fit |
| Blackboard architecture | Central board agents read/write | Classic MAS pattern; coordinator needed |
| Coordinator writes, workers read | Lead agent owns memory writes | Low conflict; bottleneck risk |
| Event bus + projection | Agents publish events; memory layer projects state | Scalable; eventual consistency |
Consistency
The consistency and conflict problem
When two agents write conflicting facts, you need resolution strategies.
- Last-write-wins — simplest; risky for high-stakes facts
- Versioning — keep history with version IDs
- Temporal KG — Zep Graphiti bi-temporal invalidation
- Locking — coordinator holds write lock per entity
- Confidence scores — higher-confidence agent wins
Frameworks
Implementation with memory frameworks
- Engram — scoped collections per team/project; multi-agent state templates (Weaviate GA roadmap, June 2026)
- Mem0 — namespace by org_id + user_id; multiple agents share org memory
- Zep — shared graph with agent provenance on edges
- Letta — shared archival memory across agent instances
- LangGraph — shared store with thread_id / namespace scoping
FAQ
Frequently asked questions
Why use shared memory for AI agents?
Agent teams need common context — research findings, task state, customer records — without re-deriving facts each turn. Shared memory enables coordination and collective learning.
Shared memory vs per-user memory?
Per-user memory scopes facts to one end user. Shared memory scopes to a team, project or agent pool. Production systems often use both layers.
Is Python shared memory the same as agent shared memory?
No — Python multiprocessing.shared_memory is OS IPC between processes. This page covers AI agents sharing a semantic/graph memory store.
What is the namespace pattern for multi-agent memory?
Single vector/graph store with metadata filters: org_id, team_id, agent_id. Each agent reads shared namespace, writes with provenance tags.
How does Zep handle multi-agent memory?
Shared temporal graph with agent provenance on edges. Bi-temporal invalidation resolves conflicts. LongMemEval +18.5% vs baseline (Rasmussen et al., 2025).
LangGraph shared memory store?
LangGraph supports shared stores with thread/namespace scoping. Pair with LangMem for durable cross-agent LTM.
How do you resolve multi-agent memory conflicts?
Last-write-wins, versioning, temporal KG invalidation (Zep), coordinator merge or confidence scores. See conflicting memories.
Shared memory for coding agent teams?
Blackboard or coordinator pattern: planner writes task state, coder reads constraints, reviewer writes feedback. See coding agents use case and multi-agent memory guide.