Shared AI Memory for Multi-Agent Coordination
Abstract
When multiple autonomous agents must collaborate on a shared task, the fundamental coordination challenge is not computation but communication: how do independently operating agents share state, synchronize actions, enforce turn-based protocols, and resolve conflicts in concurrent updates? Membase 2.0 addresses this challenge by transforming the memory layer from a passive storage backend into an active coordination substrate. This article details the technical mechanisms that enable multi-agent collaboration — including scoped shared memory, content-addressed pointers with Lamport clock versioning, the Session Orchestration Engine, and inbox-based asynchronous notifications.
1. Introduction
1.1 The Coordination Problem
Articles 1 and 2 in this series addressed the memory needs of individual agents — persistence and intelligent recovery. But modern AI applications increasingly require multiple agents to work together. A research workflow might involve one agent gathering data, another performing analysis, and a third synthesizing results. A negotiation might require two agents to exchange proposals in structured rounds.
These collaborative scenarios introduce coordination requirements that single-agent memory cannot address: shared state, concurrency control, protocol enforcement, and asynchronous communication.
1.2 Memory as Coordination
The fundamental insight driving Membase 2.0's approach to multi-agent coordination is that memory operations are coordination operations. When two agents write to the same key, they are implicitly negotiating. When an agent reads a value written by another, it is synchronizing. When a group of agents follows a structured protocol for updating shared memory, they are executing a workflow.
2. Scoped Shared Memory
2.1 From Private to Shared Scopes
Article 1 introduced the Membase scope model with five scope types. For single-agent operation, the USER scope provides private, persistent memory. For multi-agent collaboration, the TASK and TEAM scopes provide the shared memory spaces that enable coordination.
A TASK scope is a named shared workspace associated with a specific collaboration. When an agent creates a task scope, it specifies the initial member set. All members receive READ and WRITE permissions by default. A TEAM scope provides the same shared access semantics but is intended for persistent groups rather than specific collaborations.
2.2 Scope Lifecycle for Collaboration
The lifecycle of a collaborative scope follows a structured pattern:
Creation. An agent creates a TASK or TEAM scope by specifying the scope type, a unique identifier, and the initial member list.
Invitation. The system generates inbox notification messages addressed to each specified member. Members must accept invitations before they can access scope data.
Active Collaboration. All participants can read and write to keys within the scope's namespace.
Membership Management. The scope owner can add or remove members, modify per-user permissions, and transfer ownership.
Completion. The scope can be archived or deleted when the collaboration concludes.
3. Conflict-Free Distributed State
3.1 The Concurrent Write Problem
When multiple agents share a memory scope, concurrent writes become inevitable. Agent A and Agent B may both update the project status key at approximately the same time, each unaware of the other's write. Without a deterministic conflict resolution mechanism, different observers may see different final values.
3.2 Lamport Clock Versioning
Membase 2.0 resolves concurrent writes through Lamport clock versioning — a distributed logical timestamp that establishes causal ordering without requiring global time synchronization.
When an agent writes to a key for the first time, the version is set to 1.
When an agent updates an existing key, it reads the current version (v) and writes with version v+1.
When two concurrent writes have the same version, the write with the higher wall-clock timestamp wins.
This Last-Write-Wins (LWW) strategy with Lamport clock ordering provides a critical guarantee: all observers converge to the same final state, regardless of the order in which they receive the writes. This property — known as strong eventual consistency — means that Membase's shared memory is a Conflict-free Replicated Data Type (CRDT).
4. Session Orchestration Engine
4.1 Session Model
A Session is a stateful, multi-phase workflow that governs the interaction between two or more agents. Sessions progress through a linear sequence of Phases. At any point, the session is positioned at a single phase, and all agent interactions are governed by that phase's configuration.
4.2 Auto-Advance Conditions
Auto-advance conditions determine when a phase automatically transitions to the next. Membase 2.0 supports four condition types:
- all_submitted: Advances when every enrolled agent has submitted data.
- min_agents(n): Advances when at least n agents have submitted.
- data_match(field, value): Advances when any submission contains a matching field.
- timeout: Advances automatically after a configured duration.
4.3 Built-In Evaluators
Evaluators process agent submissions at phase completion and produce structured results. Membase 2.0 ships with several built-in evaluators:
| Evaluator | Description | Use Case |
|---|---|---|
| highest_score | Selects submission with highest value | Auctions, ranked selection |
| majority_vote | Counts votes, selects majority | Governance, consensus |
| comparison | Evaluates pairs against game rules | Competitive games (RPS, chess) |
5. Asynchronous Coordination via Inbox
Agents in a distributed system operate on different schedules. Membase 2.0 provides an inbox mechanism for asynchronous agent notifications. Events such as scope invitations, session phase transitions, and evaluation results generate inbox messages addressed to specific agents.
Agents poll their inbox through the inbox() API, receiving a chronologically ordered list of pending notifications. The inbox mechanism decouples event production from consumption, enabling agents to process coordination events at their own pace without requiring persistent network connections.
6. Conclusion
Membase 2.0 transforms the memory layer into a coordination substrate by combining scoped shared memory, conflict-free distributed state through Lamport clock versioning, session-driven workflow orchestration, and inbox-based asynchronous notifications. These primitives compose to support a wide range of multi-agent collaboration patterns — from distributed research workflows and iterative negotiations to voting protocols and governance mechanisms.
Next in the series: Trustless Settlement: Paying for Membase with Smart Contracts