Shared State and Context in Multi-Agent Systems

Multi-agent systems rarely fail because agents cannot produce text. They fail because the agents disagree about what is true, what has already happened, who owns the next step, or which result is authoritative.

That is a state and context architecture problem.

Reliable coordination does not mean copying the full conversation into every agent. It means separating durable workflow facts from temporary model input, defining which component may update each field, and giving every agent only the information required for its task.

TL;DR

• Context is the information available to a model for a particular inference; state is the structured condition of the running system.
• Memory stores information for later use; state records what is true about the current task or workflow.
• Shared state should have explicit schemas, ownership, update rules, versions, and checkpoints.
• Agents can coordinate through a central store, orchestrator-owned state, messages, or shared artifacts.
• “Share everything” creates oversized context, leakage, duplication, stale copies, and conflicting updates.

A shared-state architecture

A shared store is useful only when read scopes, write ownership, update rules, and durable checkpoints are explicit.

In a typical system, agents read selected fields from a shared store and publish structured updates or artifact references. An orchestrator reads the resulting workflow state to determine which tasks are runnable, blocked, failed, or complete.

The store is not automatically a model prompt. The application builds each agent’s [context](/glossary/context/) from a controlled subset of state, instructions, retrieved knowledge, and recent results.

This distinction keeps the system record separate from the transient view that one model sees.

Context vs state vs memory

These terms overlap in implementation, so definitions should follow function.

Context

Context is information made available for a particular model call. It can include the user request, instructions, selected history, tool descriptions, retrieved documents, task state, and previous results.

Context is a view. It is assembled for an agent at a moment in time and constrained by relevance, permissions, and the model’s context window.

State

[Agent state](/glossary/agent-state/) is the structured condition of the system or run. Examples include:

• task identifiers and owners;
• status such as pending, running, blocked, or complete;
• workflow position;
• input and output references;
• attempts and error records;
• approvals;
• budgets and deadlines;
• current plan version.

State answers “what is true now?” It should be inspectable without asking a model to reconstruct facts from prose.

Memory

[Agent memory](/glossary/agent-memory/) preserves information for future use. It may contain user preferences, learned facts, prior episodes, or reusable summaries. Memory answers “what should we retain and retrieve later?”

State and memory can use the same database, but their lifecycle differs. A run’s current_owner is state. A user’s preferred report format is memory. A completed incident summary may begin as run state and later be promoted into durable memory.

Shared state vs shared memory

Shared state coordinates active work. It should be current, authoritative, and tied to execution.

Shared memory makes retained information available across agents or future runs. It may be retrieved by relevance rather than read as a complete record.

A risk agent and market agent might share the same organization profile from memory. They also share current workflow state showing that the market report is complete and the risk review is blocked on a missing filing.

Treating all retained information as one undifferentiated “memory” makes update and retention policies difficult to enforce.

Local vs shared information

Agents need enough shared information to coordinate—not identical prompts or copies of the entire conversation.

Each agent can maintain local context and local working state:

• domain-specific instructions;
• scratch notes;
• temporary tool outputs;
• internal candidate plans;
• information irrelevant to other agents.

Shared information should normally include:

• the goal and normalized task brief;
• task assignments and status;
• dependencies;
• approved artifacts;
• result summaries and provenance;
• workflow-level budgets and deadlines;
• explicit completion or escalation state.

Local state reduces interference and information exposure. Shared state creates a common operational picture. The boundary should be deliberate.

Four common state architectures

1. Central shared state store

All agents read and write a shared schema through a controlled interface. The store may contain tasks, statuses, artifact references, and workflow fields.

This architecture supports a global view and makes tracing easier. It also creates contention and coupling. If every agent can overwrite every field, the “shared” store becomes a race.

Use per-field ownership, version checks, append-only results, or reducer functions. A worker might append its result under its own branch ID while only the aggregator can write final_synthesis.

2. Orchestrator-owned state

Workers receive bounded inputs and return structured results. Only the orchestrator updates authoritative workflow state.

This makes ownership clear and prevents concurrent writes. It works well for supervisor-worker and fan-out/fan-in designs.

The trade-off is centralization: all updates pass through one component, which can become a bottleneck. The orchestrator must also validate worker results instead of blindly committing them.

3. Message-based state exchange

Agents send events or messages such as taskaccepted, evidenceready, or review_failed. Each agent updates its local state from the events it consumes.

This can decouple components and support asynchronous work. It also introduces delivery and ordering concerns. Messages may be duplicated, delayed, or processed out of order.

Message handling should be idempotent, and events should include task IDs, versions, producers, timestamps, and correlation IDs. A message is evidence that something was reported, not necessarily proof that every consumer has updated its view.

4. Agent-local state plus shared artifacts

Agents keep most state locally and publish immutable artifacts to a common store. Coordination messages carry artifact references rather than full contents.

This works well for large outputs such as research packets, datasets, code patches, or reports. It reduces prompt duplication and preserves provenance.

The challenge is discoverability and lifecycle management. The system needs a catalog showing which artifact is current, what task produced it, which input version it used, and whether it passed validation.

Task state, workflow state, and conversation history

Task state describes one work unit: owner, input, status, attempts, output, and errors.

Workflow state describes the whole run: active tasks, dependency graph, budgets, approvals, aggregate status, and terminal outcome.

Conversation history records messages. It may help an agent understand the interaction, but it is not a reliable substitute for structured state. A long transcript does not guarantee that the current owner or approval status is obvious.

If a field controls execution, store it explicitly.

Tool results, intermediate outputs, and artifacts

A [tool result](/glossary/tool-result/) may be small enough to place directly in state, but large results should usually become artifacts.

Separate:

• raw tool output;
• normalized structured result;
• validation status;
• human-readable summary;
• durable artifact reference.

An agent should not overwrite the raw result with its interpretation. Preserving both lets reviewers trace claims back to evidence.

Intermediate outputs also need retention rules. Some are essential checkpoints; others are disposable scratch data. Keeping everything indefinitely increases storage, context, and privacy risk.

Ownership, synchronization, and conflicts

For every shared field, define:

• who may read it;
• who may write it;
• whether updates replace, append, or merge;
• what version was read;
• what happens on conflict;
• whether the change is durable;
• which event or trace records it.

Conflicts occur when two agents update the same logical value from different assumptions. A last-write-wins rule may silently discard useful work. Better strategies include:

• single-writer ownership;
• compare-and-swap version checks;
• append-only branch results;
• deterministic reducers;
• conflict queues for an aggregator or human;
• recomputation against the newest state.

The right choice depends on meaning. Counts may be added; lists may be appended and deduplicated; two incompatible approvals must not be averaged.

Persistence and checkpoints

Persistent state allows a workflow to survive process restarts, long tool waits, and human approvals. A checkpoint records enough state to resume from a defined boundary.

[Agent graphs and state machines](/agent-graphs-and-state-machines/) make those boundaries explicit. Good checkpoints occur after meaningful commits: task assignment, artifact validation, approval, or aggregation—not after every token.

Checkpoints also need retention and schema-version policies. Restoring old state into new code can be unsafe if fields or transition rules changed.

State transfer vs handoff

State transfer moves information. A [handoff](/glossary/agent-handoff/) transfers active ownership.

Agent A can send an artifact and status update to Agent B while still owning the task. Conversely, Agent A can hand off ownership with a minimal transfer packet. Do not infer ownership merely because data moved.

[Agent Handoffs, Delegation, and Sub-Agents](/agent-handoffs-delegation-sub-agents/) explains why the receiver should explicitly accept the task and why the previous owner must stop acting after transfer.

Shared context is not full-history copying

Copying an entire conversation into every agent appears simple, but creates several problems:

• irrelevant tokens crowd out task-specific information;
• private or restricted data reaches unnecessary agents;
• old decisions conflict with current state;
• duplicated tool results raise token cost;
• agents may anchor on discarded plans;
• no one can tell which facts are authoritative.

Build context from structured state and selected artifacts. Include summaries with provenance and version identifiers. If an agent needs more detail, let it retrieve the source artifact under permission controls.

Failure modes

Stale state

An agent acts on an old task version. Include versions in assignments and reject updates based on superseded inputs.

Missing updates

A worker completes but never publishes the result. Use explicit task lifecycle states, deadlines, and reconciliation.

Conflicting writes

Parallel workers overwrite the same field. Isolate branch outputs and merge them once.

Oversized context

The system injects the full store into every call. Create role-specific context views and budget them.

Information leakage

Shared state contains secrets or user data outside an agent’s scope. Apply field-level access controls and redact before context construction.

Unclear ownership

Multiple agents believe they own the task, or none does. Store one authoritative owner and record transfers.

These failures should be visible through [observability](/glossary/observability/): state versions, transitions, tool results, and artifact lineage should appear in the run trace.

When not to use shared mutable state

Do not introduce a broad shared store when agents only need to return independent immutable results to one coordinator. Passing structured outputs may be enough.

Avoid letting agents directly mutate business systems through “shared state” abstractions. Separate coordination state from external side effects, and guard external actions with permissions, idempotency, and approvals.

My take

The best shared-state design shares less.

Keep authoritative workflow facts small and structured. Keep large outputs as immutable artifacts. Keep agent-local reasoning local. Then construct context from the minimum current information each role needs.

That separation makes the multi-agent system cheaper, safer, and far easier to resume and debug.

Sources

• LangGraph persistence documentation distinguishes checkpoints for thread state from stores for durable cross-thread data and discusses shared state across graph boundaries.
• LangGraph Graph API documents state schemas and reducers that control how node updates replace or combine shared values.
• OpenAI Agents SDK handoffs documents handoff input filtering and the separation between model-generated handoff metadata and application context.

Continue learning

Use [Sequential vs Parallel Agent Execution](/sequential-vs-parallel-agent-execution/) to decide where concurrent updates can occur, then compare the control trade-offs in [Centralized vs Decentralized Multi-Agent Architectures](/centralized-vs-decentralized-multi-agent-architectures/).