Two ways to share: a store versus a channel
Every multi-agent system has to move information between agents, and there are two structural answers. In message passing, agent A hands a payload directly to agent B; the information lives in transit and in each agent’s private context. In shared memory, agent A writes to a common store and agent B reads from it later; the information lives in one place that outlives any single exchange.
The trade is the one distributed systems have argued about for decades. A channel keeps agents loosely coupled but fragments knowledge — no one holds the whole picture. A shared store gives every agent a single source of truth and decouples who produces from who consumes, but it introduces the classic hazards of shared state: two writers can clash, and a reader can see something out of date. This article stays on the shared-memory side; the coupling and topology questions of message passing are a separate story.
The blackboard architecture
The canonical shared-memory design is the blackboard, an idea that predates LLMs by decades (it grew out of 1970s speech-understanding systems). The metaphor is a group of specialists around a physical blackboard. No one hands notes to anyone; instead each specialist watches the board, and when the current state matches something they can contribute, they step up and add their piece. The solution emerges on the board incrementally.
Mapped onto agents, the blackboard is a structured store of the evolving solution — facts, partial results, sub-goals, intermediate artifacts. Agents are triggered by the state they observe rather than by a direct call: a researcher writes findings, a critic notices them and drafts a critique. Control is data-directed — what each agent does next is a function of what is on the board, not of a fixed script or a message addressed to it.
Read/write semantics and the consistency model
Once memory is shared, you must decide what a read is allowed to return. The strongest guarantee, linearizability, says every read reflects all writes that completed before it — the store behaves as if there is one global order and everyone sees it. It is the easiest model to reason about and the most expensive to provide.
Most agent systems relax this. Under eventual consistency, a write becomes visible eventually, and in the gap different agents may observe different states. For a loosely coupled research swarm that is often fine; for a plan two agents update in lockstep it is not, because they can diverge. The practical rule mirrors databases: pick the weakest consistency model that still keeps the agents correct, because every step up the strength ladder costs latency and throughput.
Staleness: reading the past
Staleness is the concrete failure that weak consistency invites. An agent reads the blackboard, spends thirty seconds thinking, and acts — but in those seconds another agent rewrote the very entry it based its decision on. The acting agent is now operating on the past. In a single program this is a race condition; among agents it looks like one agent ‘ignoring’ work that has already changed underneath it.
Two mitigations help. First, versioning: stamp every entry with a version or timestamp, and let an agent re-check it before committing a decision (optimistic concurrency — read version v, write only if the entry is still at v). Second, freshness discipline: read the state you depend on as late as possible, right before you act, rather than at the top of a long reasoning turn. Staleness is never eliminated in a distributed store; it is bounded and made detectable.
Write conflicts and how to resolve them
When two agents write the same location, someone must decide what it ends up holding. The bluntest policy is last-writer-wins: the most recent write overwrites and the earlier one is silently lost. It is simple and often wrong, because the lost write may have been the important one.
Better options structure the store so conflicts are rare or resolvable. Append-only logs sidestep overwrites entirely — agents add entries rather than mutate them, and readers fold the log into a view. Partitioning gives each agent its own region of the namespace (agent_a/notes, agent_b/notes) so writers never collide. Optimistic concurrency lets writes proceed but rejects any that raced, forcing the loser to re-read and retry. For most append-heavy agent workloads, a log plus namespacing removes the problem before it starts.
Memory as shared context: the token-budget tax
There is a subtlety unique to LLM agents: shared memory is not free-floating data, it is context that must be paid for in tokens. If the blackboard is injected into every agent’s prompt, the shared store competes directly with the model’s finite context window, and its cost is paid on every turn.
The growth is the danger. Suppose each agent turn appends about 500 tokens of notes to the shared board, and the whole board is prepended to every agent’s next prompt. After k turns the shared context is roughly 500 × k tokens, and the total tokens processed across the run grows like Σ_k 500k ≈ 250 · k^2 — quadratic in the number of turns. Twenty turns is 10k tokens of board and ~100k of cumulative reading; a hundred turns is 50k and ~2.5M. Shared memory broadcast in full does not scale linearly with the conversation — it scales like its square.
Retrieval over shared memory, not broadcast
The quadratic tax is why mature systems stop reading the whole board and start retrieving from it. Instead of prepending all of shared memory, an agent issues a query — by key, by recency, or by semantic similarity against a vector index — and pulls only the handful of entries relevant to its current step.
This converts the per-turn context cost from ‘size of all shared memory’ to ‘size of the top-m results,’ a constant the operator controls. A researcher asks the board for the three most relevant prior findings; a writer asks for the current outline and the latest critique; neither drags along the full history. The store can grow without bound while each prompt stays bounded. It is the shift that separates a chat log from a knowledge base: shared memory becomes something you search, not something you recite — which is what keeps a long multi-agent run inside its token budget.