Shared Memory in Multi-Agent Systems

Why Agents Need Shared State

Without shared state, each agent operates in complete isolation, unaware of what other agents have done, are doing, or plan to do. This isolation forces the orchestrator to explicitly pass all relevant context to every agent through its prompt, which is both token-expensive and error-prone. If the orchestrator forgets to include a piece of information that Agent A produced and Agent C needs, Agent C either fails or produces output based on incomplete information.

Shared state solves this problem by providing a common data store that all agents can access. When Agent A completes its work, it writes its results to the shared state. When Agent C begins its work, it reads the shared state to find Agent A's results along with any other relevant information. The orchestrator does not need to know which specific pieces of state each agent needs because each agent can query the shared state for the information it requires.

Shared state also enables agents to communicate indirectly, coordinating their behavior without direct message passing. An agent can check the shared state to see whether another agent has already completed a specific subtask, avoiding redundant work. It can read quality scores from a review agent to decide whether its own output needs revision. It can check resource consumption metrics to adjust its own behavior (such as switching to a cheaper model) when the overall task is approaching its budget limit.

Blackboard Architecture

The blackboard architecture is one of the oldest shared memory patterns in AI systems, dating back to speech recognition research in the 1970s. In this pattern, a central data structure (the blackboard) is visible to all agents. Agents read the blackboard to understand the current state of the problem, contribute their own findings by writing to the blackboard, and trigger other agents when relevant information becomes available.

The blackboard pattern works well for problems where the solution emerges incrementally from contributions by multiple specialists. A medical diagnosis system might have a symptom analysis agent, a lab result interpretation agent, a medication interaction agent, and a differential diagnosis agent, all reading and writing to a shared patient blackboard. Each agent adds its analysis, and the collective information on the blackboard eventually provides enough evidence for a definitive diagnosis.

The main advantage of the blackboard pattern is its flexibility: agents can contribute information in any order, and new agent types can be added without modifying existing agents. The main disadvantage is that the blackboard can become large and unstructured over time, making it difficult for agents to find the specific information they need among all the accumulated data. Structuring the blackboard into named sections or typed fields mitigates this problem by providing organization that agents can navigate efficiently.

State Graph Pattern

The state graph pattern, used by frameworks like LangGraph, represents shared state as a typed object that flows through the execution graph. Each node in the graph receives the current state, performs its work, and returns state updates. The framework merges these updates into the state object before passing it to the next node. This approach provides strong typing and schema validation, ensuring that agents cannot corrupt the state with invalid data.

State graphs offer several advantages over unstructured blackboards. The type system catches errors at definition time rather than at runtime. The graph structure makes the flow of state between agents explicit and predictable. Built-in persistence enables checkpointing, recovery from failures, and time-travel debugging where developers can inspect the state at any point in the execution history.

The state graph pattern enforces a specific execution model: state flows forward through the graph, and each node's updates are merged into the accumulated state. This is well-suited for pipeline-style workflows where information flows in one direction. For workflows that require agents to iteratively refine shared state through multiple rounds, the graph must include explicit cycles (loops) that route execution back to earlier nodes, which adds complexity to the graph definition.

Message Passing

Message passing is an alternative to shared memory where agents communicate by sending messages to each other rather than reading and writing a common data store. Each agent has an inbox, and other agents send messages to it when they have information to share or work to delegate. The agent processes messages from its inbox and sends responses or follow-up messages to other agents.

Message passing provides stronger isolation between agents because no shared mutable state exists. Each agent maintains its own internal state, and the only way information moves between agents is through explicit messages. This isolation makes the system easier to reason about because you can understand each agent's behavior by examining the messages it receives and sends, without worrying about hidden state changes from other agents.

The tradeoff is verbosity: information that would be implicitly available through shared state must be explicitly included in messages. If Agent C needs information from both Agent A and Agent B, both Agent A and Agent B must send messages to Agent C (or the orchestrator must compile the information into a single message). This explicit communication is more work to set up but produces more predictable behavior because there are no implicit dependencies on shared state.

AutoGen exemplifies the message passing approach, modeling multi-agent collaboration as conversations where agents exchange messages. The conversation history serves as the communication channel, and each agent sees the messages from other participants when it is its turn to respond. This conversational model is intuitive for tasks that naturally involve discussion and deliberation but can be less efficient for tasks that require structured data transfer between agents.

Vector Store as Shared Memory

Vector databases provide a specialized form of shared memory that is particularly useful for knowledge-intensive multi-agent workflows. Agents can write information to the vector store as embedded documents, and other agents can retrieve relevant information through semantic similarity search. This is more flexible than structured state because agents can store and retrieve information by meaning rather than by key.

A research pipeline might use a vector store as shared memory: research agents write their findings as embedded documents, and a synthesis agent retrieves the most relevant findings for each section of the final report through similarity search. This approach scales well to large amounts of information because the vector search naturally surfaces the most relevant content without requiring the synthesis agent to read everything.

The limitation of vector stores as shared memory is latency. Writing to and querying a vector store is slower than reading from an in-memory state object. For workflows where agents need to coordinate in real time, such as iterative refinement loops, the latency of vector store operations can create bottlenecks. Vector stores are best used as supplementary shared memory for knowledge retrieval alongside a faster primary state mechanism for real-time coordination data.

Consistency Management

When multiple agents write to shared state concurrently, consistency problems can arise. Two parallel agents might read the same state, make conflicting decisions based on it, and write back conflicting updates. Without consistency management, the final state depends on which agent's write arrives last, potentially discarding important work from the other agent.

Append-only state updates are the simplest consistency mechanism. Instead of overwriting state fields, agents append their contributions to lists. The synthesis step at the next barrier combines all contributions, resolving any conflicts through explicit logic. This approach works well for parallel workflows where agents produce independent results that need to be merged.

For workflows requiring strong consistency where agents must see each other's updates before proceeding, implement a turn-based protocol where only one agent can write to the shared state at a time. This serialization eliminates concurrent write conflicts at the cost of preventing parallel state updates. The right consistency model depends on whether your workflow prioritizes throughput (append-only with eventual merge) or correctness (serialized access with strong consistency).