Shared State and Distributed Memory

"I read the plan, I did my part, I wrote it back. By the time my pen touched the page, four colleagues had already rewritten the plan. Now we have five plans and one very confused team."

An Agent Stuck Waiting on a Lock

An agent that cannot remember is a calculator that happens to speak. Everything interesting an agent does (following a multi-step plan, recalling what a tool returned three turns ago, knowing a user's name) rests on memory. For a single agent the question is where that memory lives and how it is brought back into view at the moment of reasoning. For a team of agents a second question appears, the one this section is about: how do several agents hold a common picture of the world so that their actions add up to coordinated behavior instead of contradiction? The answer turns out to be the same shared-state machinery the rest of this book has been building, applied to the context that drives a language model.

We have met this shape before. The modern agent blackboard is the lineal descendant of the blackboard architecture introduced for distributed problem solving in Section 27.4: a shared workspace where independent knowledge sources post partial results and read each other's contributions. What is new is that the knowledge sources are now language-model agents, the postings are natural-language context, and the cost of getting consistency wrong is not a stale cache entry but an incoherent team that argues with itself.

1. The Four Kinds of Agent Memory Beginner

Before the multi-agent twist, fix the vocabulary for a single agent. Practitioners borrow the cognitive-science taxonomy, and it maps cleanly onto distinct storage mechanisms. Table 32.7.1 lists the four kinds, what each holds, and where it physically lives, because the storage location is what determines the distributed-systems problem each one raises.

Working memory is the context window, and it is the binding constraint on everything an agent does. It is finite: a model can attend to only so many tokens, and every token in view is paid for at every call. Long-term memory is the escape hatch. Anything that does not fit in the window lives in an external store and is pulled back in on demand by vector search, which is exactly the retrieval-augmented generation of Chapter 25 applied to an agent's own history rather than a document corpus. Episodic memory is the special case of long-term memory that stores past trajectories ("the last time I tried this tool it failed this way"); semantic memory stores durable facts ("the user's deployment region is eu-west"). The two differ in what they index and how they are written, but both are retrieved the same way: embed the current situation, search for the nearest stored items, and splice the top matches back into the finite window.

2. The Multi-Agent Twist: Memory Becomes Shared State Intermediate

Give one agent the four memories above and you have a capable assistant. Now put several agents on one task and ask them to coordinate. They need a common context: the planner's decomposition, the researcher's findings, the writer's draft, all visible to the team so each agent acts on the same picture. The standard way to provide it is a shared object that every agent reads and writes, called a scratchpad, a blackboard, or simply the shared message history. The instant that object exists, it is distributed shared state, and it inherits the three problems every distributed shared state has had since Section 2.5 made consistency precise.

The first problem is consistency. If two agents hold divergent copies of the shared context, they reason from different premises and their actions do not compose; the team behaves incoherently even though each agent is individually correct. This is the distributed-belief inconsistency of Section 27.8 reappearing at the implementation layer: divergent state is divergent belief. The second problem is contention. When several agents write the shared object concurrently, their updates race, and a naive read-modify-write loses writes (the lost-update anomaly we are about to reproduce). The third is staleness. An agent that read the blackboard a moment ago may act on a view that newer writes have already invalidated, the same bounded-staleness tension that parameter servers manage when workers pull slightly old parameters.

This is not an analogy that merely rhymes; it is the same pattern with the same fixes. The shared agent blackboard is the parameter-server-style shared-state pattern of Section 11.9, where many workers read and update one logically central store, transposed from gradient vectors to natural-language context. Keeping that store consistent costs synchronization, and synchronization costs time; the engineering question is how much consistency the team actually needs, the same question the consistency spectrum of Section 2.5 framed for storage systems.

3. An Inconsistency, and the Synchronization That Fixes It Intermediate

The cleanest way to see the shared-state problem is to build the smallest version of it. The code below implements a Blackboard, a shared key/value memory that a team of stub agents read and write. Each agent records its task completions by incrementing a shared counter. Done correctly, fifty agents recording twenty completions each must leave the counter at exactly one thousand; that is the coherent state the whole team should agree on. The unsynchronized path has each agent read the counter, do a little work, then write back the incremented value, the classic read-modify-write that loses updates the moment two agents interleave. The synchronized path wraps the same read-modify-write in a lock so it executes as one atomic critical section.

import threading
import time

class Blackboard:
    """A shared key/value memory several agents read and write."""
    def __init__(self):
        self._store = {}
        self._lock = threading.Lock()

    def read(self, key, default=None):
        return self._store.get(key, default)

    def write(self, key, value):
        time.sleep(0.001)            # work between an agent's read and its write
        self._store[key] = value

    def update_locked(self, key, fn, default=None):
        with self._lock:             # read-modify-write as ONE critical section
            cur = self._store.get(key, default)
            time.sleep(0.001)
            self._store[key] = fn(cur)

def run_team(blackboard, locked, n_agents=50, increments=20):
    blackboard.write("done", 0)
    def agent():
        for _ in range(increments):
            if locked:
                blackboard.update_locked("done", lambda c: c + 1, default=0)
            else:
                cur = blackboard.read("done", 0)   # stale read
                blackboard.write("done", cur + 1)  # lost update under contention
    threads = [threading.Thread(target=agent) for _ in range(n_agents)]
    for t in threads: t.start()
    for t in threads: t.join()
    return blackboard.read("done"), n_agents * increments

for locked in (False, True):
    seen, expected = run_team(Blackboard(), locked=locked)
    tag = "WITH a lock" if locked else "WITHOUT synchronization"
    print(f"{tag:<24} done={seen:<5} expected={expected}  lost={expected - seen}")

WITHOUT synchronization  done=24    expected=1000  lost=976
WITH a lock              done=1000  expected=1000  lost=0

The unsynchronized run is not merely a little off; it lost 976 of 1000 updates, because while one agent held a stale value and slept, dozens of others read the same stale value and clobbered each other's writes. Translate the counter back into agent terms: it stands for any shared fact the team accumulates (tasks claimed, sub-results posted, a running plan). Lose updates to it and agents proceed on a picture of the world that silently disagrees with reality and with each other, which is exactly the incoherent-team failure mode. The lock costs something real: agents now wait their turn, and under heavy contention that wait is the bottleneck. That cost is the synchronization tax, and the whole craft of shared agent memory is paying as little of it as coherence allows, by locking at the finest granularity, by sharding the blackboard so unrelated keys never contend, or by accepting bounded staleness where the task tolerates it.

4. Context Management: The Cost of Carrying the Shared Picture Intermediate

Consistency is one tax on shared memory; the size of the shared context is the other. Working memory is finite, so the running blackboard cannot simply grow without bound: at some point the accumulated message history no longer fits the window. The standard remedy is summarization, also called compaction, where older context is condensed into a shorter summary that preserves the load-bearing facts and discards the rest. A team might keep the last few turns verbatim and replace everything older with a running summary, trading fidelity for room.

The economics are sharper in the multi-agent case because of a multiplier. Suppose the shared context holds $T$ tokens and the team has $A$ agents, each of which must see that context to act. If every agent reads the full shared context on every one of its calls, and the team makes $C$ calls in total, the tokens paid for scale as

where $T_c$ is the context size at call $c$. The trap is that $T_c$ tends to grow over a session as the blackboard accumulates, and it is paid at every agent's every call. A shared context that grows linearly with the conversation, read by $A$ agents over a session, turns a single agent's linear token bill into a roughly $A$-times-larger one, and a long unmanaged history makes each $T_c$ larger still. This is why compaction and selective context (giving each agent only the slice of the blackboard it needs, not the whole board) are not optimizations to add later; they are what keep a multi-agent system affordable and fast, since latency tracks tokens too.

# LangGraph: shared state + a checkpointer give consistent, persisted memory
from langgraph.graph import StateGraph, MessagesState
from langgraph.checkpoint.memory import InMemorySaver

builder = StateGraph(MessagesState)          # MessagesState IS the shared blackboard
# ... add_node(planner), add_node(researcher), add_edge(...) ...
graph = builder.compile(checkpointer=InMemorySaver())  # persists + serializes state

# Letta: agents with self-managed long-term memory (pip install letta)
from letta_client import Letta
client = Letta(base_url="http://localhost:8283")
agent = client.agents.create(model="openai/gpt-4o-mini",
                             memory_blocks=[{"label": "shared", "value": "team scratchpad"}])

5. Why Memory Often Makes or Breaks the System Advanced

It is tempting to treat memory as plumbing and spend design effort on the agents' reasoning prompts. In practice the opposite allocation usually pays off, because the failure modes that sink multi-agent systems are overwhelmingly memory and state failures rather than reasoning failures. An agent that reasons perfectly over a stale or inconsistent context produces a confidently wrong action; a team whose shared state diverges produces members that work hard at cross purposes. The lost updates in Output 32.7.1 and the divergent reports in the practical example were not reasoning bugs, they were shared-state bugs, and no amount of prompt engineering fixes a lost write.

The three taxes compose into a single design tension. More agents and more shared context buy more capability, but they raise the consistency cost (more writers contending), the staleness risk (more readers acting on old views), and the token cost (more context read more times). A system that ignores any one of them degrades in a characteristic way: ignore consistency and the team is incoherent, ignore staleness and it is subtly out of date, ignore token cost and it is slow and expensive. Getting the shared memory right, choosing the consistency level, the locking granularity, and the compaction policy that the task actually needs, is therefore not a finishing touch on a multi-agent system; it is frequently the thing that determines whether the system works.

With the shared-memory substrate in place, the remaining question is operational: what engine actually hosts these agents, routes their messages, and runs the blackboard reliably across machines? That is the orchestration layer, and the next section turns to the distributed orchestration engines that provide it, in Section 32.8.