5. Multi-Agent Shared Memory
5.1 MCP as Blackboard
Classical AI blackboard architecture applied to agent swarms. Multiple agents read and write a shared semantic store via MCP tool calls: each agent deposits observations, other agents query by semantic search or tag.
Tools implementing this pattern: shared-memory-mcp (evalops), Agent-MCP (rinadelph), agentmemory (port 3111 as shared server), Mem0 cloud (shared user_id).
Limitation: MCP was designed for user-to-agent context access, not agent-to-agent coordination. The A2A protocol (Section 5.5) exists precisely because MCP alone is insufficient for this use case. Using MCP as a coordination bus is a workaround.
5.2 Neo4j Agent Memory
Three-layer graph architecture with Python package:
| Layer | Content | Purpose |
|---|---|---|
| Short-term | Conversation session state, working memory | Active task context |
| Long-term | Extracted entities, relationships, facts | Persistent knowledge |
| Reasoning | Tool call traces, decision steps, why | Audit trail for handoffs |
The reasoning layer is the key differentiator. When agent team B takes over from agent team A, they can read exactly which tools were called, what was tried, and why decisions were made. Background entity extraction jobs continuously transform short-term into long-term. [Demo: youtube.com/watch?v=qMV64p-4Deo, UNVERIFIED]
Security note: the reasoning memory layer stores exactly what an attacker who breaches the memory server wants: the why behind every action. No tool documents encryption-at-rest for reasoning traces. See Section 7.4.
5.3 Leases and Signals (agentmemory)
Beyond shared storage, agentmemory implements coordination primitives:
- Leases: an agent can lock a memory region while working on it, preventing write conflicts with other agents on the same task.
- Signals: agents can notify each other of state changes asynchronously, effectively pub/sub on top of the memory server.
The architecture is a correct direction: distributed locks + pub/sub. Real concerns not yet documented: lease expiry policy when an agent crashes mid-lease, signal delivery guarantees (at-most-once vs. at-least-once), and behavior when agents run on different machines with clock skew. The primitives are sound; the implementation needs the same scrutiny a distributed-systems library would receive.
5.4 ICM Memoirs for Inter-Agent Graphs
In a local multi-agent setup where all sub-agents share the same host, ICM Memoirs create a persistent, typed relationship graph that survives session boundaries:
# Agent A writes during its session
icm memoir create -n "project-arch"
icm memoir add-concept -m "project-arch" -n "auth-service"
icm memoir link -m "project-arch" --from "auth-service" --to "api-gateway" -r depends-on
# Agent B reads in its session (same host, same ICM DB)
icm memoir export -m "project-arch" -f asciiThis works because ICM's SQLite database is shared across all 17 configured tools on the same machine. Cross-machine sharing requires copying the database file manually; there is no sync protocol.
5.5 A2A Protocol
Source: developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
Complement to MCP. MCP = user to agent (context access). A2A = agent to agent (collaboration). Agents request help, share findings, and coordinate via function calls. The handoff mechanism allows one agent to transfer control to another without user intervention.
Adoption accelerated across frameworks in 2025-2026. The relationship: MCP handles tool access to external systems; A2A handles agent-to-agent communication and task delegation. Memory sharing between agents should eventually be designed around A2A primitives rather than bolted on top of MCP.