Shared Context vs Isolated Context in Multi-Agent Architectures

One of the most consequential architectural decisions in multi-agent system design is how context is distributed across agents. Should all agents have access to a shared global context that reflects the current state of the entire task? Or should each agent work in an isolated context containing only the information directly relevant to its assigned subtask? The answer affects correctness, security, performance, and debuggability in ways that are difficult to change after the system is built.

What Context Means in Multi-Agent Systems

Context in a multi-agent system is everything an agent can see when making a decision. It includes the original task description, any information gathered so far, the results of previous agents' work, metadata about the current state of the pipeline, and any constraints or preferences from the user or system. More context generally helps agents make better decisions, but context also carries risks: it can be polluted with incorrect information, it can contain sensitive data that should not be visible to all agents, and it consumes token budget.

The Shared Context Model

In a shared context model, all agents in a pipeline can read from and write to a common context store. When one agent discovers something relevant, it writes it to the shared context and all other agents can immediately see it. This model maximizes information availability and enables emergent coordination where agents naturally incorporate each other's discoveries without explicit handoffs.

The practical implementation is typically a key-value store (Redis works well) or a document store that all agents can access. Each agent reads the current state at the start of its work and writes its findings back on completion. Locks or optimistic concurrency control are needed if agents can write to the same keys concurrently.

# Shared context implementation with Redis
import redis.asyncio as aioredis
import json
from typing import Any

class SharedAgentContext:
    def __init__(self, task_id: str, redis_url: str):
        self.task_id = task_id
        self.redis = aioredis.from_url(redis_url)
        self.prefix = f"task:{task_id}:ctx"

    async def get(self, key: str, default: Any = None) -> Any:
        val = await self.redis.get(f"{self.prefix}:{key}")
        return json.loads(val) if val else default

    async def set(self, key: str, value: Any, ttl_seconds: int = 3600):
        await self.redis.set(
            f"{self.prefix}:{key}",
            json.dumps(value),
            ex=ttl_seconds,
        )

    async def atomic_update(self, key: str, update_fn) -> Any:
        """Safe concurrent update using optimistic locking."""
        async with self.redis.pipeline() as pipe:
            while True:
                try:
                    await pipe.watch(f"{self.prefix}:{key}")
                    current = await self.get(key)
                    new_value = update_fn(current)
                    pipe.multi()
                    await pipe.set(f"{self.prefix}:{key}", json.dumps(new_value))
                    await pipe.execute()
                    return new_value
                except aioredis.WatchError:
                    continue  # Retry on concurrent modification

# All agents use the same SharedAgentContext instance
ctx = SharedAgentContext(task_id="task-abc", redis_url="redis://localhost")
await ctx.set("research_complete", True)
await ctx.set("sources_found", ["url1", "url2"])

# Any agent can read what other agents have written
sources = await ctx.get("sources_found", default=[])

The Isolated Context Model

In an isolated context model, each agent receives a curated context package prepared specifically for its subtask. The orchestrator assembles this package from the broader task state, passing only the information that agent needs. Agents cannot read each other's context directly. Results flow back through the orchestrator, which decides what to propagate where.

The isolated model is more work for the orchestrator but produces a system with clear information flow. Every piece of context that an agent has access to arrived there deliberately, through an explicit decision by the orchestrator. This makes the system easier to audit and harder to corrupt through prompt injection.

# Isolated context, orchestrator curates what each agent sees
from dataclasses import dataclass
from typing import Any

@dataclass
class AgentContextPackage:
    task_id: str
    agent_id: str
    instruction: str
    context: dict[str, Any]  # only what this agent needs
    output_schema: dict       # what this agent should return

class IsolatingOrchestrator:
    def prepare_research_context(self, task: dict) -> AgentContextPackage:
        return AgentContextPackage(
            task_id=task["id"],
            agent_id="research-worker",
            instruction=f"Research the following topic: {task['topic']}",
            context={
                "topic": task["topic"],
                "max_sources": task.get("max_sources", 5),
                # NOT included: user preferences, billing info, other agents' progress
            },
            output_schema={"sources": "list[url]", "summary": "string"},
        )

    def prepare_writer_context(self, task: dict, research_result: dict) -> AgentContextPackage:
        return AgentContextPackage(
            task_id=task["id"],
            agent_id="writer-worker",
            instruction="Write a report based on the provided research",
            context={
                "research_summary": research_result["summary"],
                "sources": research_result["sources"],
                "tone": task.get("tone", "professional"),
                "target_length": task.get("word_count", 500),
                # NOT included: raw research data, user identity, system config
            },
            output_schema={"draft": "string", "word_count": "number"},
        )

    async def run(self, task: dict) -> dict:
        research_ctx = self.prepare_research_context(task)
        research = await self.call_agent(research_ctx)

        writer_ctx = self.prepare_writer_context(task, research)
        draft = await self.call_agent(writer_ctx)

        return draft

Security Implications of Each Approach

Context architecture has direct security implications. In a shared context model, a successful prompt injection against one agent can contaminate the shared context store. Other agents reading that contaminated context will then operate on injected data. The injection blast radius covers all agents with read access to the store.

In an isolated context model, a successful injection against one agent affects only that agent's context. Other agents receive curated context from the orchestrator, not from the compromised agent. The orchestrator serves as a trust boundary between agents, preventing horizontal propagation of injected content.

Context Synchronization Patterns

For systems that require a degree of context sharing but want to avoid the risks of fully open shared state, there are three synchronization patterns that offer different tradeoffs between coordination overhead and information freshness.

When to Use Each Model

Use shared context when your agents are tightly coupled around a continuously evolving task state, when agents genuinely benefit from seeing each other's real-time discoveries, and when all agents are within the same trust boundary. Collaborative research tasks, iterative refinement workflows, and tasks where the optimal next step depends on the cumulative state of all previous steps fit the shared model well.

Use isolated context when agents work on independent subtasks that don't need real-time awareness of other agents' progress, when agents span different trust levels or organizational boundaries, when security or privacy requires strict data separation between agents, or when you need a clear, auditable record of what information influenced each agent's decisions.

Hybrid Context Architecture

Most production systems end up with a hybrid: a shared read-only context for task-level metadata (task ID, user preferences, overall goal, timeline), combined with isolated write contexts for each agent's working state. Agents can read the shared task metadata freely but cannot write to it or to each other's working contexts. Only the orchestrator can promote information from an agent's working context into the shared context.

class HybridContextManager:
    def __init__(self, task_id: str, redis_url: str):
        self.task_id = task_id
        self.redis = aioredis.from_url(redis_url)

    # Shared read-only section (orchestrator writes, agents read)
    async def get_task_metadata(self) -> dict:
        key = f"task:{self.task_id}:meta"
        data = await self.redis.get(key)
        return json.loads(data) if data else {}

    async def set_task_metadata(self, data: dict):
        # Only the orchestrator should call this
        await self.redis.set(
            f"task:{self.task_id}:meta",
            json.dumps(data),
            ex=7200,
        )

    # Isolated write section (each agent has its own namespace)
    async def get_agent_state(self, agent_id: str) -> dict:
        key = f"task:{self.task_id}:agent:{agent_id}"
        data = await self.redis.get(key)
        return json.loads(data) if data else {}

    async def set_agent_state(self, agent_id: str, state: dict):
        await self.redis.set(
            f"task:{self.task_id}:agent:{agent_id}",
            json.dumps(state),
            ex=3600,
        )

    # Orchestrator promotes agent results to shared state
    async def promote_to_shared(self, agent_id: str, keys: list[str]):
        """
        Orchestrator explicitly moves specific results from agent state
        to shared state after reviewing them.
        """
        agent_state = await self.get_agent_state(agent_id)
        shared = await self.get_task_metadata()
        for key in keys:
            if key in agent_state:
                shared[f"{agent_id}_{key}"] = agent_state[key]
        await self.set_task_metadata(shared)

Conclusion

Context architecture is the fabric of multi-agent coordination. Shared context reduces coordination overhead but increases the blast radius of failures and injections. Isolated context increases safety and auditability but requires deliberate orchestration of information flow. The hybrid approach, shared read-only metadata with isolated write contexts, provides a practical middle ground that most production systems converge on.

Whatever model you choose, make the choice deliberately and document it. The context architecture of a multi-agent system is not visible in any single agent's code. It emerges from the interaction of all the agents, and it needs to be a first-class design decision, not something that happens by default.