TechByteByByte

Shared State and Memory

What agents need to see in common versus what should stay private, real ownership architectures from named production systems, and four precisely defined failure modes — including a real, dated security incident.

#AI Agents#Multi-Agent Systems#Shared Memory#State Management

A team writing on one whiteboard can coordinate quickly, but one mistaken edit can confuse everyone. Shared state is powerful because all agents see it—and risky for exactly the same reason.

Agents → read shared state → propose updates → validate/version → save

What You Will Learn

  • What belongs in shared state versus private agent context.
  • How versioning, locks, ownership, and event logs prevent lost updates.
  • How shared memory can spread stale, private, or incorrect information.

Your previous course already gave you the foundational distinction — context, state, and memory, and how they differ for one agent. This module asks the question that only exists once there’s more than one: who owns this piece of information, and who else needs to see it?

Module 10 already covered what happens when two agents race to write the same resource. This module is about the architectural decision that determines whether that race happens at all — what gets shared, what stays private, and how that choice gets made deliberately rather than by accident.

The two shapes, side by side

Private-only

Agent A          Agent B          Agent C
  │                │                │
  ▼                ▼                ▼
Memory A        Memory B         Memory C
(isolated)      (isolated)       (isolated)
Shared-workspace

Agent A ──┐
          │
Agent B ──┼──►  Shared Memory Pool  ◄── all read/write
          │
Agent C ──┘

Neither shape is correct by default. The right one depends entirely on whether the requirement is isolation (privacy, consistency, role stability) or real-time mutual awareness — exactly the question the rest of this module answers with real, named systems on both sides, and exactly the same discipline this course has applied to every other architecture decision since Module 1: match the mechanism to the requirement, not to whichever option feels more sophisticated.

Three real architecture patterns

Production memory infrastructure converges on three named patterns, each with a different trade-off:

  • Centralized — one shared store every agent reads and writes. Simple, and it bottlenecks past a certain agent count — the same scaling ceiling Module 7 already gave you numbers for.
  • Distributed — private stores per agent, with selective synchronization between them. Scales well; consistency across those private stores is where the real difficulty lives.
  • Hybrid — what most production systems actually run. (Mem0, How to Design Multi-Agent Memory Systems for Production)

That last point is worth taking seriously: hybrid isn’t a compromise reached reluctantly — it’s the, dominant real-world choice, precisely because pure centralized and pure distributed each have a real failure mode the other one avoids.

Private-only memory: real systems, real trade-offs

In a private-only architecture, each agent’s memory is isolated — readable and writable only by that agent. This gives strong isolation and makes the system easier to reason about. The real cost: the same information often gets independently rediscovered and stored redundantly across multiple agents’ private spaces, wasting real resources. (Rethinking Memory Mechanisms of Foundation Agents, arXiv)

Three named, real systems illustrate why teams choose this trade-off deliberately:

  • RecAgent instantiates one agent per user, keeping memory private specifically to avoid mixing different users’ histories — a privacy requirement, not a performance choice.
  • TradingGPT gives each trading agent its own memory so it maintains a consistent risk preference and sector focus — collaboration happens through exchanging selected viewpoints, not sharing full memory, precisely because a shared memory pool would blur the distinct risk postures that make the system valuable in the first place.
  • MetaAgents isolates each role’s memory of its own past thoughts and decisions specifically to keep that role stable and consistent over time, writing new information back locally rather than into a shared pool.

Notice what these three systems have in common: private memory wasn’t the default they fell into — it was the deliberate answer to a requirement (privacy, consistency, role stability) that shared memory would have actively undermined.

Shared-workspace memory: the other real trade-off

A shared-workspace design gives agents a common pool they all read and write. Agents share intermediate results through this pool directly, which reduces the need for heavy peer-to-peer messaging — Module 3’s communication overhead, meaningfully lowered.

The real cost: the shared pool tends to get noisy quickly, requiring filtering mechanisms, and needs real coordination strategies to prevent conflicts when multiple agents update the same information. (Rethinking Memory Mechanisms of Foundation Agents, arXiv)

A real, concrete scoping model

It’s worth grounding “what should be shared versus private” in an actual, named production implementation rather than leaving it abstract. Mem0’s memory infrastructure scopes information along four dimensions simultaneously: user, session, agent, and application — so each agent sees only what it needs, not everything the broader system has ever stored. (Mem0)

The honest trade-off, stated directly by the same source: “scoping decisions are hard to change later, so get them right early.” This is worth taking as seriously as it’s stated — retrofitting scope boundaries onto a system that started with everything shared by default is harder than designing the boundaries deliberately from the start.

Four precisely named failure modes

This is worth knowing exactly, because “shared state can go wrong” is too vague to design against. Current research names four distinct failure modes for governed shared memory in multi-agent systems:

  • Unauthorized leakage — information reaching an agent (or, transitively, a user) that was never supposed to have access to it.
  • Stale propagation — outdated information continuing to circulate through the shared substrate after it should have been superseded, exactly Module 7’s “understanding drift” problem, now at the memory-architecture level rather than the reasoning level.
  • Contradiction persistence — conflicting versions of the same fact both remaining live in shared memory, with nothing resolving which one is authoritative.
  • Provenance collapse — losing track of where a piece of shared information actually originated, making it impossible to trace a wrong fact back to whichever agent introduced it.

(Governed Shared Memory for Multi-Agent LLM Systems, arXiv)

Each of these is a different problem requiring a different fix — unauthorized leakage needs access control; stale propagation needs expiration or versioning; contradiction persistence needs a reconciliation authority (Module 9’s reconciler-agent pattern, applied here); provenance collapse needs the audit trail Module 6 already told you observability infrastructure exists to provide.

It’s worth being explicit about why treating these as one undifferentiated “shared state can go wrong” risk is a real mistake, not just an imprecise way of talking about it. A team that builds strong access control — solving unauthorized leakage — has done nothing to prevent contradiction persistence, because access control governs who can write, not whether two legitimate writes conflict.

Similarly, a versioning system that expires stale entries cleanly does nothing to preserve provenance if it discards the record of who wrote the current, non-stale version in the process. Each of these four failure modes needs its own, specific mechanism, and a system that’s hardened against one can still be vulnerable to the other three.

A real, dated security incident

This isn’t hypothetical. The same research paper introducing those four failure modes reports its own real, measured findings against a production-style memory system, with dates attached: a freshly-provisioned tenant was measured on 2026-05-30, and one specific finding — improper scope isolation on a sub-tenant lookup path — was disclosed and remediated server-side on 2026-05-31. (Governed Shared Memory for Multi-Agent LLM Systems, arXiv)

This is worth knowing precisely because it demonstrates unauthorized leakage isn’t an abstract risk category — it’s a real, disclosed, dated vulnerability in real infrastructure, found and fixed within roughly 24 hours of measurement. The lesson: even a system deliberately designed with governance in mind can still ship a real scope-isolation gap, which is exactly why testing access boundaries directly — not just designing them — matters.

Shared memory can propagate more than facts

It’s worth knowing a more serious risk than a stale or contradictory fact. Current research found that jailbreak and poison content propagates across agent-society topologies, and shared-memory architectures propagate it more readily than independent-memory ones. Separately, evaluator bias stored in past trajectories propagates forward in time to future agents sharing that memory — with no safe contamination threshold, even when the system attempts to consolidate and clean the shared record. (Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents, arXiv)

Read that precisely: this isn’t saying shared memory occasionally passes along a bad fact. It’s saying a adversarial or biased entry, once written into shared memory, has no known safe threshold below which the system can trust it won’t influence future agents. This is directly why Module 11’s security discussion about untrusted content applies here with even more force — a compromised entry in shared memory isn’t read once by one agent, it’s available to every agent that reads from that pool, for as long as it remains there.

The honest anti-pattern worth naming directly

It’s worth closing the architecture discussion with a candid critique from a real, credible source, because it names a mistake this course has been circling since Module 1.

“The problem is what teams typically build after the split: multiple agents running the same base model, differentiated only by system prompts, coordinating through message queues or shared files. The architecture looks like a team but behaves like a slow, redundant, expensive single agent with extra coordination overhead.” — O’Reilly Radar, citing LangChain’s “Choosing the Right Multi-Agent Architecture,” January 2026

This is worth connecting directly to Module 2’s original argument: role specialization is only when scope, capability, and accountability are actually distinct. Agents that share the same model, the same shared file, and differ only in system prompt wording have none of those three things separated — they’re not really specialized, they’re the same undifferentiated capability paying multiple times over for the privilege of coordinating with itself.

Applying this to the recurring scenario

The legal-contract pipeline currently keeps Executor and Critic output in a structured, shared report — Module 6’s structured-aggregation choice. It’s worth running this module’s four failure modes against that design honestly.

Unauthorized leakage is low-risk here, since every agent in the pipeline is working the same contract with the same legitimate need to see it. Stale propagation becomes a real risk only if the same Executor result gets reused across a later, unrelated revision of the contract without being re-verified — worth an explicit expiration or re-check rule if contracts are ever revisited.

Contradiction persistence is exactly why the Critic role exists at all — it’s the reconciliation authority preventing two conflicting clause interpretations from both surviving into the final report. Provenance collapse would mean losing track of which specific Executor run produced a specific comparison — precisely why Module 6’s tracing discipline (capturing every tool call and its result) isn’t optional infrastructure, it’s what keeps this specific failure mode from ever becoming possible in the first place.

Running all four failure modes against this one pipeline honestly shows something worth generalizing: a system doesn’t need to guard against every failure mode with equal urgency. This pipeline’s risk concentrates almost entirely on contradiction persistence, precisely because its shared surface (the structured report) is narrow, single-purpose, and already has a designated reconciliation authority in the Critic role. A system with a broader shared memory pool — spanning multiple unrelated tasks, retained across sessions — would need to take unauthorized leakage and stale propagation just as seriously as this pipeline takes contradiction persistence.

Interview-relevant framing

Q: How would you decide what memory should be shared versus private in a new multi-agent system?

Ans: I’d start from requirements, not convenience — the way RecAgent, TradingGPT, and MetaAgents each chose private memory for a specific reason: user privacy, maintaining a consistent risk posture, or keeping a role stable over time. Shared memory earns its place specifically when agents need real-time awareness of each other’s progress and the coordination savings outweigh the noise and conflict-resolution cost.

I’d also treat scope decisions as expensive to change later, so I’d rather over-invest in getting the boundaries right upfront than retrofit access control onto a system that started with everything shared by default.

Q: **What’s the difference between a stale-propagation failure and a contradiction-persistence failure in shared memory? **

Ans: Stale propagation is old information that should have been superseded still circulating — the system hasn’t caught up to reality yet. Contradiction persistence is different: two conflicting versions of the same fact are both still live in the system simultaneously, and nothing has the authority to resolve which one is correct. The fix for the first is expiration or versioning. The fix for the second needs an actual reconciliation authority — a Critic or reconciler agent with real authority to resolve the conflict, not just detect that one exists.

A third question worth preparing for:

Q: Why is shared memory a different security concern than a single compromised message?

Ans: Because a single malicious message is read once, by whichever agent it’s addressed to. A compromised or poisoned entry written into shared memory is available to every agent that draws from that pool afterward, indefinitely — current research found no safe contamination threshold for this kind of propagation, even when the system attempts to clean or consolidate the shared record. That’s a different risk profile than Module 11’s untrusted-content problem, which is scoped to one request. This is scoped to the entire fleet’s future behavior.

Common Misconception

Incorrect idea: A shared memory gives every agent the same correct understanding.

Why it is incorrect: Shared data may be stale, incomplete, conflicting, or poisoned. Systems need ownership, versions, validation, and access control.

Key takeaways

  • Module 10 covered what happens when agents race to write shared state; this module covers the architectural decision that determines whether that race happens at all.
  • Three real architecture patterns dominate production systems: centralized (simple, bottlenecks past a certain scale), distributed (scalable, consistency is hard), and hybrid — the most common real-world choice, not a compromise.
  • Private memory is a deliberate choice for requirements — RecAgent for user privacy, TradingGPT for consistent risk posture, MetaAgents for role stability — not a default teams fall into.
  • Shared-workspace memory reduces communication overhead but requires filtering and conflict-resolution mechanisms as the pool grows noisy.
  • Mem0’s real production scoping model splits memory across four dimensions (user, session, agent, application) — and scoping decisions are hard to change later, worth getting right upfront.
  • Four precisely named failure modes exist: unauthorized leakage, stale propagation, contradiction persistence, and provenance collapse — each requiring a different fix, not one generic “access control” solution.
  • A real, dated 2026 security incident (disclosed May 30, remediated May 31) shows unauthorized leakage is a measurable risk even in systems explicitly designed with governance in mind.
  • Shared memory can propagate jailbreak content and evaluator bias with no known safe contamination threshold — a compromised entry isn’t read once, it’s available to every agent drawing from that pool indefinitely.
  • The honest anti-pattern to avoid: agents differentiated only by system prompt, sharing the same model and files, produce a system that looks like a team but behaves like one slow, expensive agent with added coordination overhead.

Module 13 covers what happens once shared state does produce a conflict despite careful design: conflict resolution — voting, arbitration, and supervisor intervention, and how a system decides which of several different agent outputs actually wins, when this module’s own four failure modes weren’t fully prevented upstream.

Author
TechByteByByte Editorial Team
Reviewed by
TechByteByByte Admin
Published
Last reviewed