Shared Memory and Context Propagation

Why context breaks down between agents

Here's the thing, when you split a workflow across multiple agents, each one typically gets its own isolated execution context. Agent 1 processes a customer inquiry, Agent 2 verifies the account, Agent 3 drafts a response, and somewhere between steps 2 and 3, critical context evaporates. The customer's original timezone preference? Gone. The severity flag from the first triage? Lost.

From what I've seen in production systems, coordination without shared state is just expensive context-passing (as Mikiko Bazeley from MongoDB puts it). You end up re-prompting each agent with increasingly bloated context windows, or worse, agents start hallucinating missing details to fill the gaps. By step 5 of a 12-step chain, you're operating on fictional premises.

The solution isn't just better prompting. You need architectural mechanisms for shared memory and context propagation, governed storage that maintains consistent state across agent boundaries, prevents context drift, and catches bad data before it cascades downstream.

Check your understanding

Your 5-agent customer support workflow is producing inconsistent responses. Agent 1 correctly classifies a ticket as 'urgent billing issue,' but by the time Agent 4 drafts the response, it's treating it as a routine inquiry. What's the most likely architectural cause?

Governed shared memory architectures

A production-grade shared memory system isn't just a key-value store everyone can read and write. It's governed storage with four critical dimensions: scope (who may read this data), time (is this version still current), provenance (how was this derived), and propagation (does this cross agent boundaries).

Think of it like this. Agent 1 writes a customer verification result to shared memory. Agent 3 (the payment processor) needs to read it, but Agent 5 (the marketing recommendations agent) shouldn't have access to PII. The memory layer enforces read/write permissions at the agent level, not through prompt engineering or trust.

The best implementations I've seen use a REST API layer that agents call explicitly. Each memory entry carries timestamps for staleness checks, lineage metadata showing which agent wrote it, and visibility flags that prevent sensitive context from leaking across security boundaries. This catches the failure mode where Agent 1 hallucinates an API response format and poisons the entire downstream chain.

Key ideas: governed storage with four critical dimensions. The memory layer enforces read/write permissions at the agent level. timestamps for staleness checks, lineage metadata showing which agent wrote it — Key ideas from this lesson, grouped for review.

Most frameworks don't handle this for you

LangGraph, CrewAI, and AG2 provide state primitives, typed channels, conversation history, workflow context, but they leave the shared memory architecture to you. The #1 cause of production multi-agent failures is assuming the framework handles context consistency automatically. It doesn't.

Check your understanding

Context propagation patterns in practice

Let's get concrete. In a sequential pattern, Agent A completes its work and writes artifacts (extracted entities, validation flags, intermediate outputs) to shared memory. Agent B reads that entire accumulated context, appends its own results, and passes the enriched state forward. This works beautifully for fixed transformation pipelines, KYC verification → transaction processing → notification dispatch.

In a concurrent pattern, multiple agents execute in parallel against the same input context. An e-commerce order triggers inventory check and fraud detection simultaneously. Both agents read the initial order payload from shared memory, but they write to separate namespaces (inventory.status, fraud.score). The orchestrator waits for both writes, then aggregates results before routing to the payment agent.

The trickiest is the handoff pattern used in AG2's GroupChat. Agents participate in a shared conversation where context flows through message history. A selector LLM decides who speaks next based on accumulated dialogue. Context propagates conversationally, not through structured memory writes, which is elegant but makes it harder to enforce governance or validate intermediate state.

Key ideas: sequential pattern. concurrent pattern. handoff pattern — Key ideas from this lesson, grouped for review.

Monotonic context accumulation

The ClimateAgent research workflow uses a simple but powerful rule: each agent appends artifacts to shared context, never overwrites. Planning agent writes decomposition, Data agent adds retrieved datasets, Coding agent adds scripts, Visualization agent adds charts. By the end, you have a complete audit trail of what each specialist contributed, and no agent can accidentally delete another's work.

Check your understanding

Match each context propagation pattern to the workflow scenario where it fits best.

Checkpointing and validation gates

Don't worry if this feels abstract, the practical lever is validation checkpoints at every handoff. Before Agent B reads from shared memory, run a lightweight validation: Is the schema what we expect? Are required fields populated? Does the timestamp indicate fresh data?

Harrison Chase's LangGraph makes this explicit with typed state channels and checkpointing. You define a state schema (a TypedDict or Pydantic model), and the framework enforces it at every node transition. If Agent 2 tries to write a malformed object, the workflow crashes immediately rather than propagating bad data through six more steps.

For me, this was one of those 'huh' moments. I'd been treating memory as a free-for-all scratchpad. Adding validation gates, even simple JSON schema checks, caught hallucinated API responses, missing customer IDs, and stale cache hits before they poisoned downstream agents. The workflow became 3× more reliable without touching a single prompt.

Start with read-only memory for most agents

A production pattern I've seen work well: only the orchestrator and a few trusted agents get write access to shared memory. Worker agents operate in read-only mode, returning outputs to the orchestrator, which validates and writes. This prevents agents from clobbering each other's state and makes debugging far simpler.

Key takeaways

Coordination without shared state is just expensive context-passing, agents lose critical metadata across handoffs, leading to context drift and hallucination propagation.
Governed shared memory enforces scope (who reads), time (staleness), provenance (lineage), and propagation (cross-boundary visibility), it's not just a key-value store.
Most frameworks (LangGraph, CrewAI, AG2) provide memory primitives but leave the architecture to you; context consistency is the developer's responsibility.
Validation checkpoints at every handoff catch malformed data, stale context, and hallucinated outputs before they poison downstream agents.
Sequential patterns accumulate context step-by-step; concurrent patterns aggregate parallel results; handoff patterns propagate context conversationally through shared dialogue.

Your product check-in

Apply “Shared Memory and Context Propagation” to a product or workflow you know. What would you try, what could go wrong, and what evidence would help you decide?