Design Patterns for Agentic AI: Multi-Agent Shared State Management
How agents share and protect what they know || Edition 25
This post is part 7 of the Agentic AI Series — a multi-part exploration of how autonomous systems are reshaping enterprise architecture, governance, and security.
The Short Version
State is what agents share. Context lives in one agent's window; state persists outside it. When Agent A discovers something Agent B needs, that finding flows through state.
Isolation is foundational. Agent isolation protects working memory. Tenant isolation enforces organizational boundaries. Implement these boundaries first; coordination patterns depend on them.
State coordination is hard. Multiple agents reading and writing shared state create synchronization challenges—conflicts, stale reads, race conditions. Explicit coordination patterns manage this complexity.
Shared State patterns enable coordination. Blackboard for flexible collaboration, event logs for auditability, structured state for typed handoffs. Each trades flexibility for predictability.
Shared state governance determines system trust. Which agents can write, which can read, how conflicts resolve, and whether coordination flows are auditable—these decisions determine whether your multi-agent system can be trusted in production.
If you’ve read the base architecture post, you already have the foundations. This post extends the Orchestration layer to multi-agent systems—where the challenge shifts from managing one agent’s context to coordinating state across many agents while keeping their boundaries intact.
When AI Acts: The Architecture Behind Agentic AI
The architecture post establishes the foundational layers of an agentic AI system: how context is assembled, how plans are formed, how actions are orchestrated, and how outcomes flow back into the system.
Terminology: Context vs. Memory vs. State
Context is what one agent sees during inference. Memory is what one agent stores and retrieves for its own use. State is what multiple agents share for coordination.
The previous post discussed context management for single-agent systems. This post covers state: what architectural decisions do you face when multiple agents need to share information while protecting their boundaries?
Shared State patterns enable coordination. Memory Isolation patterns enforce boundaries.
The Multi-Agent Context Problem
When multiple agents operate together, context management becomes state coordination. The challenges shift from “what fits in the window” to “what should be shared” and “what must be protected between agents.”
The “Insider Threat”: A multi-agent system handles legal research and document drafting. One agent analyzes confidential acquisition documents. Another drafts an unrelated client memo—but without agent isolation, it sees the first agent’s findings and references them. Sensitive information leaks across agent boundaries. (Agent Isolation)
The “Noisy Neighbor”: An enterprise platform runs agent workflows for multiple clients. Client A’s agent accidentally writes to a shared state location, corrupting Client B’s workflow. Without tenant boundaries, one customer’s bug becomes everyone’s outage. (Tenant Isolation)
The “Left Hand vs. Right Hand”: A multi-agent supply chain system coordinates Inventory and Finance agents. The Inventory Agent places an emergency order while the Finance Agent cancels all pending shipments to cut costs. Without shared state, their locally sound decisions paralyze the company. (Shared State)
These are multi-agent state failures. Without the right architecture, agents leak information across boundaries (no agent isolation), contaminate other tenants (no tenant isolation), or work at cross-purposes (no shared state).
Foundational: Isolation Requirements
Agent Isolation
Protecting agents from each other
Agent isolation ensures each agent's working memory remains private. Without it, a compromised agent can read other agents' secrets, and sensitive information leaks across boundaries that should stay separate.
With isolation in place, each agent operates within its own working memory and information can only be shared through explicit shared state mechanisms. This limits blast radius—if one agent is compromised, the attacker gains access to that agent's memory rather than propagating across the entire system.
Isolation Levels
Agent-Scoped Isolation: Each agent maintains its own working memory. Information moves between agents only through explicit shared state, limiting blast radius if one agent is compromised. This improves containment but increases coordination overhead and complicates cross-agent debugging.
Workflow-Scoped Isolation: Agents within one workflow can share state, but different workflow runs are isolated from each other. This supports parallel execution of similar workflows, though long-running workflows can accumulate state over time.
Sensitivity Classification
In multi-agent systems, sensitivity classification determines what can flow between agents. Public findings flow freely. Workflow-internal state stays within one run. Confidential data requires explicit grants. Credentials, PII, and security tokens never cross agent boundaries—even within the same workflow.
Tenant Isolation
Enforcing organizational boundaries
Tenant isolation enforces a hard organizational boundary. State is never shared across tenants, even when workflows run on shared infrastructure. This boundary is required for multi-tenant deployments such as enterprise SaaS platforms and shared agentic systems.
Tenant isolation operates at the infrastructure level rather than the application layer. Four requirements make it effective:
Tenant tagging: Every state object—agent memory, shared state, logs, and artifacts—is tagged with a tenant identifier.
Storage isolation: Separate partitions or tenant-specific encryption keep data isolated at rest.
Access enforcement: Cross-tenant access is blocked at the storage layer, not just the application layer.
Audit logging: Logs are scoped by tenant, preventing cross-tenant visibility during debugging or compliance reviews.
Why Infrastructure-Level Enforcement
Application-level checks are fragile. Bugs, misconfigurations, or compromised agents can bypass them. Infrastructure-level enforcement—through separate databases, storage partitions, or cryptographic isolation—ensures that cross-tenant access remains impossible even when the application layer fails.
State Coordination Patterns
Pattern 1: Blackboard
The flexible collaboration pattern
A Blackboard is a shared workspace where agents post findings and read contributions from others. Agents contribute based on their expertise and the evolving state of the board. This pattern supports collaborative problem-solving where solutions emerge incrementally from multiple perspectives.
Variations
Pub/Sub (Publish-Subscribe): Agents publish to topics and subscribe only to what’s relevant. This reduces noise compared to a pure blackboard but requires deliberate topic design.
Observer Pattern: Agents register interest in specific state changes and are notified when those changes occur. Coordination is event-driven rather than based on polling shared state.
When to Use
Collaborative analysis where multiple perspectives improve the outcome
Research synthesis where findings build on each other
Creative tasks where rigid task decomposition would limit outcomes
Tradeoffs
Pattern 2: Event Log
The auditable coordination pattern
An Event Log is an append-only record of events and actions shared across agents. Agents subscribe to relevant event types and react as events arrive. The append-only structure enforces ordering, avoids update conflicts, and provides a built-in audit trail.
Variations
Message Queue: Events are consumed and acknowledged, ensuring each event is processed exactly once. This model works well for task distribution, though it offers less visibility for coordination.
Event Sourcing: System state is reconstructed by replaying events, preserving full history and enabling point-in-time recovery. This approach increases complexity but delivers maximum auditability.
When to Use
Workflow coordination where execution order matters
Audit-sensitive domains such as finance, healthcare, and legal
Debugging complex multi-agent interactions
Systems that require reconstruction of past decisions and actions
Tradeoffs
Pattern 3: Structured State
The predictable handoff pattern
Structured State uses a typed, schema-defined shared object (e.g., JSON document with defined fields). Each field has a clear owner: the agent responsible for writing to it. This model provides predictability and clarity, with the tradeoff that schemas must be designed upfront and changes require coordination.
Variations
Orchestrator State: A central coordinator maintains authoritative state. Agents report results and receive instructions from the orchestrator. Ownership is clear, though the orchestrator becomes a single point of failure.
Hierarchical State: State is nested across scopes—team, workflow, and global—to reflect organizational structure. This supports delegation but adds structural complexity.
When to Use
Well-defined pipelines with known stages
Typed handoffs between specialized agents
Production systems where predictability matters
Systems with clear ownership boundaries
Tradeoffs
At a Glance: Shared State Patterns
Cross-Cutting: Governance
State coordination patterns require governance decisions that apply across all patterns. Four questions shape how these systems behave in practice:
Who can write? Any agent that writes to shared state can influence every agent that reads from it. Define which agents can write to which state, what validation protects the write path, and how changes are recorded.
How are conflicts resolved? When multiple agents update related state, conflicts are inevitable. Decide upfront how they are handled: last-write-wins, merge logic, reject-and-retry, or central arbitration. Each choice trades simplicity, safety, and throughput differently.
How long does state persist? State that persists indefinitely becomes stale or unmanageable. Define retention windows, cleanup triggers, and what is archived versus deleted.
Can you reconstruct what happened? For debugging, compliance, and trust, you need to trace who wrote what, when, and under what conditions. Auditability must be designed in from the start.
Together, these decisions determine the security posture and operational trustworthiness of a multi-agent system.
In Closing
State coordination is a trust problem expressed through infrastructure. Every shared state channel carries an implicit contract: who is allowed to write, what other agents will treat as true, and what happens when that trust is violated. The patterns you choose encode assumptions about which agents can access which context—and under what conditions.
Multi-agent systems fail differently from single-agent systems. Single-agent failures tend to be local, contained to one user, one session, or one context. Multi-agent state failures propagate. A poisoned shared state influences every agent that reads it. A missing isolation boundary allows one agent’s context to bleed into another’s. The blast radius is architectural, not incidental.
The next part makes those assumptions explicit. Contracts and specifications define who can act, what counts as truth, and how the system enforces boundaries before failures have a chance to cascade.
