Shared Memory vs. Message Passing in Multi-Agent Systems

Shared memory and message passing are the two fundamental paradigms used to coordinate multiple AI agents. With shared memory (in its classic variant, the blackboard pattern), all agents read from and write to a common state. With message passing, each agent is encapsulated and communicates exclusively via messages, with no shared state. The decision between the two determines four properties of a multi-agent system: consistency, coupling, scaling and debuggability. This article compares the paradigms along these axes and shows when each one fits.

• Shared memory / blackboard: a common state (scratchpad, vector store, state object) that all agents read from and write to. Tightly coupled, simple context exchange, but tricky with parallel writes.
• Message passing: isolated agents, exchange only via messages. Decoupled, scales across process and vendor boundaries, is the standard behind A2A, the OpenAI Agents SDK and the Anthropic Claude Agent SDK.
• The decisive rule: reads may run in parallel fan-out, writes should remain single-threaded, regardless of the chosen paradigm.

Shared Memory and the Blackboard Pattern

In the shared-memory approach, all agents share a central store. The classic blackboard pattern originates in AI research: a shared "blackboard" holds the current state of a task, specialized agents observe it, read the parts relevant to them, enter their partial results and react to changes that other agents have caused. There is no fixed execution plan; the order emerges from which agent is currently able to contribute something useful.

In modern multi-agent systems, shared memory appears in several forms. Four external storage layers are common:

• Vector stores (pgvector, Pinecone, Weaviate, Qdrant) for retrieval-augmented context.
• Structured databases (Postgres, BigQuery, SAP HANA, Snowflake) for facts.
• Scratchpads as ephemeral shared notepads that agents read from and write to, usually with append-only or compare-and-swap semantics.
• Persistent agent memory (Letta/MemGPT style, LangGraph's cross-thread store, Anthropic's memory tool).

The peer-to-peer or swarm pattern also partly falls under this: peer agents on a shared message bus and/or shared store with no fixed orchestrator. OpenAI Swarm is the reference here: an experimental framework released in October 2024 and succeeded by the production-ready OpenAI Agents SDK in March 2025. For DACH enterprise contexts, however, this free-form model is rarely suitable, because debuggability and accountability suffer as a result.

The weak point is consistency. As soon as two agents read the same store and at least one writes, a clear strategy is needed. Three options are common: (a) optimistic concurrency, (b) a single writer with multiple readers, or (c) explicit lock semantics. Most production systems choose (b), which corresponds to the Cognition rule "writes stay single-threaded".

Message Passing and Agent Communication via Messages

With message passing, each agent holds its own state and its own context window. Information flows only via explicit messages, never via direct access to another's state. This decouples the agents: an agent does not need to know anything about another's internal workings, model or memory; it only needs to know the message format.

This is precisely the design idea behind the Agent-to-Agent protocol (A2A), which was released by Google at Cloud Next in April 2025 and handed over to the Linux Foundation on June 23, 2025. A2A defines how agents talk, not how they think: each agent publishes an AgentCard (a JSON document with endpoint, capabilities, skills, modalities and auth schemes). A collaboration runs via a task lifecycle:

submitted -> working -> input-required -> completed | failed | canceled

The internal workings of the remote agent remain opaque throughout. This is exactly what allows a Salesforce agent to call an SAP agent without either one exposing prompts, memory or model to the other. While A2A covers the agent-to-agent level, the Model Context Protocol (MCP) governs the agent-to-tool level. The rule of thumb common across the industry (as of 2026): MCP for capabilities (agent to tool), A2A for collaboration (agent to agent).

Other stacks implement message passing with their own semantics:

LangGraph is an interesting borderline case here: the typed state object is effectively a shared state, but it is passed in a controlled manner from node to node and checkpointed, so it is not written freely. This is the hybrid form common in practice.

The Trade-offs in Direct Comparison

Two failure modes deserve particular attention. First, context fragmentation: sub-agents make incompatible implicit decisions. Cognition states this as a principle: "Actions carry implicit decisions, and conflicting decisions carry bad results." The remedies are sharing full traces under high coupling, single-threaded writes and explicit decision contracts. Second, debuggability collapse: with message passing there is no single trace covering the entire run, but rather N sub-agent trajectories plus synthesis. The remedy is end-to-end distributed tracing with correlation IDs propagated across every A2A task and every MCP call.

A Concrete Example: Read Fan-out with a Single Writer

The Anthropic Research Agent (June 2025) is the reference for the correct split. A lead agent (Claude Opus 4) decomposes the request and spawns N parallel sub-agents (Claude Sonnet 4). Each sub-agent has its own context window of around 200k tokens, researches independently and returns a compressed summary (not the full transcript) to the lead, which synthesizes. This is pure message passing with isolated contexts. The result, according to Anthropic's internal research eval: the multi-agent system performed 90.2% better than a single agent running Claude Opus 4. The price is around 15x the token consumption of a normal chat interaction; a single agent uses about 4x. These economics only pay off for high-value, parallelizable tasks.

A counterpart from insurance practice is Allianz Project Nemo: seven specialized agents (planner, cyber, coverage, weather, fraud, payout, audit) for food-spoilage claims after natural disasters. In Allianz's worked example, less than five minutes pass between filing the claim and the final review. That review stays with a human: a caseworker reads the audit summary and makes the final payout decision (human-in-the-loop as an explicit requirement). Allianz built the system in under 100 days and launched it in Australia in July 2025. Documented result: 80% less processing and settlement time for valid claims under AUD 500.

As pseudocode, the read fan-out topology with a single writer looks like this:

1. fragments = parallel_map(sub_agent.research, subtasks): reads run in parallel as a fan-out with isolated contexts.
2. result = lead.synthesize(fragments): exactly one writer merges the fragments.
3. commit(result): the write stays single-threaded.

Concurrent writes by several agents to the same state, by contrast, should be avoided, because agents writing in parallel make implicit decisions that contradict each other.

When to Use Which Paradigm

• Choose message passing when agents collaborate across process, team or vendor boundaries, when internals are to remain encapsulated and when auditing per message is required. This is the default for cross-system workflows (Agentforce to Joule to Copilot via A2A) and for read-mostly fan-out (research, retrieval, classification, review).
• Choose shared memory when tightly coupled subtasks run within a single process, the shared state is small and the write frequency is low, and a single writer can be established. The blackboard suits tasks without a fixed execution plan.
• Combine both, which is the production reality: an internal LangGraph flow with a durable state object and checkpointing, exposed to the outside as an A2A endpoint with an AgentCard. Controlled shared state internally, clean message passing externally.

For Agencies and B2B Decision-Makers

The choice of paradigm is a question of operational risk. Anyone setting up multi-agent workflows in the DACH region should default to message passing via the convergent standard combination of MCP plus A2A and deliberately confine shared memory to tightly coupled internal subtasks with a single writer. For marketing agencies this means, in concrete terms: content, research and review pipelines benefit from parallel read fan-out, while the final write step (publication, CRM entry) remains single-threaded. Anyone planning a production-ready, auditable agent architecture for their clients or their own organization should fix the coupling profile, the consistency strategy and the tracing infrastructure early, before the first line of orchestration is written. This is exactly where Blck Alpaca's consulting comes in.