When several LLM agents cooperate, they need a way to share what they know. One family of designs threads information through messages passed from agent to agent. The other — the subject of this piece — puts a single shared memory in the middle: a common store that every agent can read from and write to. This is the classic blackboard pattern, and it changes the coordination problem from ‘who tells whom’ into ‘who reads and writes what, when.’ That reframing brings its own math and its own failure modes: staleness, write conflicts, and a context window that quietly fills up. We walk the architecture from first principles, count the token cost, and name the pitfalls that decide whether shared memory scales.
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.
The scratchpad and artifact pattern
A powerful special case of shared memory keeps large objects out of context and passes references instead. When an agent produces a big result — a full document, a dataset, a rendered file — it writes the object to a shared scratchpad or artifact store and puts only a small handle (an id, a path, a one-line summary) on the board.
Downstream agents see the handle, and only the agent that needs the bytes dereferences them. A summarizer writes artifact://draft_7 with a two-sentence abstract; the planner reasons over the abstract and never loads the 40-page draft; only the editor fetches the full object. It is the shared-memory version of passing a pointer rather than a copy — the most effective way to keep collaborative agents from drowning each other in tokens. The board stays a lightweight index of what exists and where; the heavy content lives beside it, retrieved on demand.
Practical implications for small models on CPU
Shared memory is doubly attractive when the agents are small models running on CPU, because the binding constraint there is context length, not cleverness. A small model with a modest window cannot hold a long collaborative history in prompt, so the retrieve-don’t-broadcast discipline is not an optimization — it is the difference between working and overflowing.
Two habits follow. Keep the working state on the board terse and structured (typed fields, short keys, IDs) so a weak model parses it reliably and few tokens are spent; and lean on the artifact pattern, letting a small model reason over one-line summaries and dereference a full object only when it must. Shared memory lets several cheap, context-limited models behave like one system with a large effective memory — provided each prompt stays small. The shared store grows; no individual window has to.
Common pitfalls
Three failure modes recur. The first is unbounded context growth: broadcasting the whole board every turn, and hitting the quadratic token wall until runs get slow, expensive, or truncated. The fix is retrieval and references, never a bigger prompt. The second is silent staleness: agents acting on state that changed mid-turn, with no version check to catch it. Stamp versions and read late.
The third is lost writes from naive last-writer-wins on a contended cell — work that vanishes because two agents overwrote each other; prefer append-only logs and per-agent namespaces so the contention never arises. Underlying all three is one mindset shift: a shared blackboard is a concurrent data store, and it deserves the same care — consistency choices, conflict policy, bounded reads — that any shared store in a distributed system demands.