The Other Reason Multi-Agent Systems Get Stuck: Poorly Shared State
When multiple AI agents work together, communication protocols govern how messages travel and who goes first. Yet even with a correct protocol, the system can still fail—because each agent holds incomplete or even contradictory context. Agent A updates a customer record while B keeps working from the old version; the conclusions a research agent found never reach the writing agent. This is not just bad luck for individual teams: the MAST study from UC Berkeley (Cemri et al., NeurIPS 2025) analyzed 1,642 execution traces across 7 popular multi-agent frameworks and identified 14 failure modes, with nearly 40% falling under "inter-agent misalignment"—context not carried over, conflicting assumptions, earlier decisions forgotten by later agents. The Cognition team behind Devin put it even more bluntly in their 2025 engineering notes: most multi-agent failures boil down to missing context somewhere in the system. This article does not cover message-passing rules or collaboration topologies. It focuses on where context, memory, and task state should live between agents, how they should be transferred, and how to keep them consistent—the true information backbone of a multi-agent system.
First, Distinguish the Three Layers of Shared State
Unpack the word "state" and you can see which mechanism fits each layer. A multi-agent system has at least three:
- Working context (short-term): the live context of the current task—the user's original request, current progress, the previous step's output. Short-lived; disposable once the task ends.
- Task state (mid-term): the progress board for the whole task—which subtasks are done, where things are stuck, what each produced. Every agent relies on it to know where the overall effort stands.
- Long-term memory (cross-task): knowledge that accumulates across tasks—customer preferences, past decisions, business rules. It lets the next task avoid starting from zero.
Mainstream frameworks confirm this layering in their designs. LangGraph provides two parallel persistence mechanisms: the checkpointer handles short-term state within a single thread (conversation continuity, resumable runs), while the Store handles cross-thread long-term memory (user preferences, accumulated knowledge)—and the official docs explicitly recommend using both rather than conflating them. CrewAI splits memory into four functional types—short-term, long-term, entity memory, and a contextual memory layer that assembles them; earlier versions stored these separately in ChromaDB and SQLite, while the current version consolidates them into a single, unified Memory API. The theoretical root of this layering traces back to Berkeley's 2023 MemGPT paper (Packer et al., arXiv 2310.08560): borrowing the memory-hierarchy concept from operating systems, it treats the limited context window as "main memory," moves what does not fit to external storage, and lets the LLM call functions to page data between tiers. This "virtual context management" later evolved into the Letta framework, now a key reference for agent memory architecture. Mixing the layers is a common mistake: stuffing short-term context into long-term memory fills the knowledge base with noise, while cramming long-term knowledge into every conversation blows up the context window.
Two Sharing Mechanisms: Shared Store and Handoff Payload
In practice, passing state between agents combines two patterns.
Shared store (blackboard pattern): all agents read and write one central state; any update is visible to everyone. It suits information that needs global synchronization, such as task state. The upside is a single source of truth; the cost is handling concurrent writes and access control.
Handoff payload (context handoff): when an agent finishes a stretch of work, it distills the result into a structured artifact—summary, key fields, conclusions—and passes it to the next agent, instead of dumping its entire reasoning trace. Anthropic's 2025 engineering write-up on its multi-agent research system is a working example of both mechanisms combined: the lead agent saves its research plan to external Memory first (because a context window beyond 200K tokens gets truncated, the plan only survives if it lives outside the window), while subagents act as "intelligent filters," running large volumes of searches themselves and returning only condensed findings for the lead agent to synthesize. The cost is concrete too: such multi-agent systems consume about 15 times the tokens of a plain chat. In exchange, a system with Claude Opus 4 as the lead and Sonnet 4 subagents outperformed a single Opus 4 agent by 90.2% on Anthropic's internal research eval.
How Much Sharing Is Enough? A Tension Between Two Schools of Practice
On how much to share, the industry offers two seemingly opposite answers. Cognition's principle is "share as much context as possible": pass not only conclusions but full action traces, because any omitted detail can change how downstream agents interpret the task—which is also why they argue you should stick with a single agent running end-to-end before rushing into multi-agent designs. Anthropic's practice is "condense before handing off": subagents return only distilled findings so the lead agent is not drowned in raw material. The two are not actually contradictory—the difference is the direction of information flow. When delegating downstream, err on the side of more context (task goals, boundaries, known assumptions) so downstream agents do not start from wrong premises. When reporting upstream, condense first and hand over only conclusions and key evidence. A workable dividing line:
| Information type | Recommended scope | Rationale |
|---|
| Task goals and progress | Globally shared | All agents must align on the same goal |
| Each agent's final output | Shared (after distillation) | Downstream needs conclusions, not the process |
| Intermediate reasoning, drafts | Private | Noise; sharing only distracts others |
| Long-term knowledge, business rules | Shared read-only | A common baseline no single agent should freely alter |
When read-only is not nuanced enough for long-term knowledge, go one step further: read-only for everyone, writable only by a designated memory-manager agent responsible for consolidation and updates—balancing consistency with maintainability.
Consistency: Never Let Any Agent Work From Stale Context
The most dangerous failure of shared state is the stale read—A has updated, B keeps working from the old version, and their conclusions diverge from that point on. Within MAST's "inter-agent misalignment" category, one failure mode is precisely "forgetting information provided by other agents." Several practical countermeasures:
- Single source of truth: one authoritative copy per piece of state, with every agent pointing to it instead of caching drifting local copies. LangGraph's approach is to have the framework persist shared state centrally rather than scattering it across each agent's conversation.
- Versions or timestamps: tag every update with a version so downstream agents can tell whether their copy is current, and re-read when it is not.
- Distill before sharing: summarize and prune before writing into shared state rather than dumping raw long-form text—Anthropic's 15x token figure is a reminder that unrestrained sharing shows up directly in cost.
The goal of shared state is not "record everything, transmit everything," but ensuring every agent gets exactly the correct, current slice of context when it needs it.
Nerdtechnic: Getting Your Agents' Information Backbone Right
Gartner projects that by 2028, 33% of enterprise software will include agentic AI (up from under 1% in 2024), while also warning that over 40% of agentic AI projects will be canceled by the end of 2027—the difference often comes down to whether the foundational engineering was done right. A stable multi-agent system needs more than correct communication protocols; it needs a well-designed information backbone—where state lives, how memory is layered, how context is distilled and handed off, and how consistency is maintained. Nerdtechnic's AI systems consulting service helps enterprises inventory the shared and private state each agent needs, and design layered memory architectures and handoff mechanisms, so multiple AI agents genuinely collaborate on the same up-to-date facts instead of clinging to their own versions and drifting further apart.
References
- Cemri et al., "Why Do Multi-Agent LLM Systems Fail?" (MAST), NeurIPS 2025. arxiv.org/abs/2503.13657
- Cognition, "Don't Build Multi-Agents," 2025. cognition.com/blog/dont-build-multi-agents
- LangChain, "Persistence" (LangGraph documentation). docs.langchain.com/oss/python/langgraph/persistence
- CrewAI, "Memory" documentation. docs.crewai.com/en/concepts/memory
- Packer et al., "MemGPT: Towards LLMs as Operating Systems," arXiv:2310.08560, 2023. arxiv.org/abs/2310.08560
- Letta, "MemGPT Is Now Part of Letta." letta.com/blog/memgpt-and-letta
- Anthropic, "How we built our multi-agent research system," 2025. anthropic.com/engineering/multi-agent-research-system
- Gartner forecast (cited via secondary source): by 2028, 33% of enterprise software applications will feature agentic AI, up from under 1% in 2024. orbilontech.com/ai-agents-enterprise-applications-implementation-2028
- Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 2025-06-25. martech.org (quoting the original Gartner forecast)
Technical Sharing
