Research Report 5.4: Shared Context & Memory

A single LLM agent managing its own context is hard enough. Now multiply the problem. Five agents working on the same project. Each one has its own context window. Each one makes decisions that affect the others. Agent A discovers that the API has a rate limit. Agent B is about to hit that rate limit. If they can't share what they know, Agent B will rediscover the same constraint through the same failure, wasting time and tokens on a problem that was already solved.

This is the shared context problem in multi-agent systems, and it's fundamentally a distributed systems challenge wearing an AI costume. The questions - how do you synchronize state, maintain consistency, manage conflicts, and scale coordination - are the same questions that distributed databases have been wrestling with for decades. The difference is that the "nodes" in this system are language models with attention mechanisms instead of servers with RAM.

The Core Challenge: Distributed Working Memory

Shared context in a multi-agent system functions as distributed working memory for the agent network. Each agent maintains its own working context (what it sends to the model on each call), but some of that context is relevant to other agents and needs to be accessible across the network.

The challenge breaks into three sub-problems:

What to share. Not everything an agent knows is relevant to other agents. The Planner's reasoning about task decomposition isn't useful to the Executor unless the Executor encounters a problem that requires replanning. Sharing everything creates noise. Sharing nothing creates amnesia. The system needs a relevance filter.

When to share. Real-time synchronization maximizes consistency but creates overhead. Every piece of shared state requires propagation, and every propagation costs time and tokens. Batch synchronization reduces overhead but creates windows where agents operate on stale information.

How to handle conflicts. Two agents might update the same piece of shared state simultaneously. Agent A marks a task as "in progress" while Agent B marks it as "blocked." Without conflict resolution, the shared state becomes inconsistent, and agents make decisions based on contradictory information.

Memory Architecture Models

Multi-agent memory systems follow three architectural patterns, each with distinct trade-offs:

Centralized Memory

All shared state lives in a single store. Agents read from and write to the central store. Consistency is guaranteed because there's only one copy of each piece of state.

Advantages: Simple consistency model. No synchronization needed. Easy to query the complete state.

Disadvantages: Single point of failure. Bottleneck under high concurrent access. Every agent must communicate with the central store for every shared operation.

In practice, centralized memory works well for small agent networks (2-5 agents) where the coordination overhead is manageable and the failure risk is acceptable. The GSD methodology used this pattern - the .planning/ directory was effectively centralized shared memory, and agents coordinated through files.

Distributed Memory

Each agent maintains its own copy of relevant shared state. Changes propagate between agents through synchronization protocols.

Advantages: No single point of failure. Agents can operate independently during network partitions. Better performance under concurrent load.

Disadvantages: Consistency is hard. Synchronization introduces latency. Conflict resolution is complex.

Distributed memory follows patterns from distributed database theory. Eventual consistency (all agents will eventually see all updates, but not necessarily immediately) is the practical choice for most multi-agent systems, because strong consistency (all agents always see the same state) requires coordination overhead that dominates the actual work.

Hybrid Memory

A combination where frequently accessed shared state is centralized for consistency, while less critical state is distributed for performance.

Advantages: Balances consistency guarantees with performance requirements. Critical state (task assignments, blocking issues) stays consistent. Non-critical state (agent reasoning traces, partial results) propagates asynchronously.

Disadvantages: Complexity of maintaining two systems. Must correctly classify which state is critical and which isn't.

Most production multi-agent systems converge on hybrid approaches. Frameworks like AutoGen and CrewAI implement variations of this pattern, with a central task manager for coordination state and agent-local memory for working context.

Memory Partitioning

Not all memory should be accessible to all agents. Memory partitioning creates zones with different access rules:

Private memory belongs to a single agent. Its internal reasoning, partial calculations, and working hypotheses. Other agents can't see private memory. This prevents premature conclusions from influencing other agents' work.

Shared memory is accessible to agents that need it. The project state, completed tasks, discovered constraints, and agreed-upon decisions. Access is controlled by role - the Verifier can read execution results, but the Planner's research notes might not be relevant to the Debugger.

Public memory is accessible to all agents and the human operator. The final artifacts, verified results, and project status. Public memory is the output layer - what the system produces as its deliverable.

The partitioning scheme mapped naturally to the GSD agent architecture: each agent had private context for its reasoning (not shared), shared context for project state (.planning/ files), and public context for verified deliverables (the actual code and documentation).

Attention and Relevance Filtering

The most important optimization in shared memory isn't storage - it's retrieval. When an agent needs to make a decision, it shouldn't receive everything in shared memory. It should receive only what's relevant to the current decision.

Semantic relevance filtering uses embeddings to match the agent's current task against shared memory entries. If the Executor is working on a database integration task, shared memories about API rate limits are relevant. Shared memories about UI component choices are not. Embedding similarity provides a rough relevance score.

Role-based filtering predefines which categories of shared memory are relevant to each agent type. Planners need requirements and constraints. Executors need plans and conventions. Verifiers need success criteria and implementation details. Role-based filtering is coarser than semantic filtering but faster and more predictable.

Temporal relevance weights recent entries higher than old ones. A constraint discovered five minutes ago is more likely to be relevant than one discovered five hours ago. But temporal relevance has exceptions - some early decisions remain relevant throughout the project. The system needs to distinguish between time-sensitive state and persistent decisions.

Importance scoring assigns priority to shared memory entries based on their impact. A blocking issue scores higher than a minor optimization suggestion. A critical constraint scores higher than a stylistic preference. Importance scoring ensures that when the token budget is tight, the most consequential information gets loaded first.

Forgetting Strategies

Shared memory that grows without bound eventually drowns the system in noise. Forgetting - deliberately removing or archiving information - is as important as remembering.

Least-recently-used eviction removes entries that haven't been accessed in a defined period. If no agent has retrieved a shared memory entry in 24 hours, it's likely no longer relevant to active work.

Importance-based archival moves low-importance entries to long-term storage that isn't included in active context but can be retrieved on demand. Decisions and constraints stay active. Intermediate reasoning and superseded information gets archived.

Progressive compression summarizes older entries rather than deleting them. A detailed discussion about a technology choice becomes a one-line record of the decision. The detail is lost, but the decision persists. This mirrors how human institutional memory works - organizations remember what was decided, not the full deliberation.

Failure Modes

Shared context systems fail in predictable ways:

State divergence happens when agents operate on different versions of shared state. Agent A thinks the task is complete. Agent B thinks it's still in progress. Both make decisions based on their version, producing contradictory outputs.

Context pollution occurs when irrelevant information from one agent leaks into another agent's context. The Debugger's error traces show up in the Planner's context, biasing the Planner toward cautious approaches for problems that have already been fixed.

Synchronization bottlenecks appear when too many agents try to update shared state simultaneously. In centralized architectures, this creates queuing delays. In distributed architectures, this creates conflict storms.

Memory overflow happens when shared memory exceeds the system's ability to filter effectively. With thousands of shared memory entries, even good relevance filtering retrieves too many results, and the agent's context window gets flooded.

The diagnosis for all of these is observability: the ability to see what each agent received in its context, what it wrote to shared memory, and where the state diverged from expectation. Without observability, shared memory failures manifest as mysterious quality degradation that's nearly impossible to debug.

Related

For how single-agent state management creates the foundation for shared memory, see Research Report 2.3: State Management Across Calls.

For the comprehensive memory architecture framework, see ACE Comprehensive Reference Specification.