Shared-Context AI Agents: Patterns, Risks, and Setup

Shared-context AI agents are several agents working toward one team objective that read from and write to a common, governed context, meaning definitions, decisions, findings, and task history, instead of each agent starting from a blank prompt. Teams use them when the work is too broad for a single agent session and when the cost of every agent re-learning the same facts exceeds the cost of governing a shared store. An illustrative example: a lead agent splits a release-readiness check across three workers. One reviews the pull request, one checks the incident log, one drafts the changelog. Each worker writes its findings to a shared record that the other agents and the humans on the team can read, so the changelog writer sees the reviewer's risk notes without a separate handoff.

---

TL;DR:

• Shared-context AI agents coordinate through a common, governed store of definitions, decisions, and findings, not through bigger prompts or copied chat history.
• Shared context is one layer among five: it differs from private agent state, the session context window, long-term memory, and operational workflow state, and each layer fails differently.
• The patterns that work in practice are a shared workspace, scoped retrieval, lead-and-worker coordination, durable records, and human review.
• The real risks are context contamination, permission leakage, stale facts, conflicting writes, and prompt-injection propagation. Each has a concrete mitigation, and none of them disappear on their own.
• Agent Swarm implements shared context through two memory scopes, isolated worker containers with one shared volume, lead-and-worker delegation, encrypted secrets with egress injection, and human steering and approvals.

---

Table of Contents

• Shared context vs memory vs private state
• Patterns teams use
• Risks and how to contain them
• How Agent Swarm implements shared context
• Getting started
• Sources
• FAQ

Shared context vs memory vs private state

The phrase "shared context" gets used for at least five different things, and teams design badly when they collapse them. A context window is not memory, memory is not a shared workspace, and a task queue is not any of those. Before choosing tools, decide which layer each piece of information belongs to.

Layer	What it holds	Who can read it	How long it lives	Typical failure
Shared context	Team definitions, decisions, findings, task history	Every agent on the team, plus the humans	Across sessions, until curated	Contamination: one bad fact spreads to every agent
Private agent state	One agent's working notes, preferences, scratch state	Only that agent	Across that agent's sessions	Siloed knowledge nobody else can reuse
Session context (context window)	The tokens a model can attend to in one request	The model, for that request only	One session	Eviction: critical facts fall out of the window
Long-term memory	Curated, durable facts retrieved on demand	Whoever the memory scope allows	Months or indefinitely	Poisoning: a bad write is trusted as fact later
Operational workflow state	Queues, locks, run status, schedules	The orchestrator and its agents	Until the run completes	Lost runs and duplicate work after a restart

Two clarifications prevent most confusion. First, the context window is volatile working memory that resets every session, while long-term memory is a durable store that feeds relevant facts back into that window through retrieval. Our memory vs context window guide covers that distinction in depth, including why raw token capacity does not behave like memory. Second, "shared" is a property of the scope, not of the storage. Two agents can sit on the same database and still have fully private memories if the scope rules say so. When people say shared-context AI agents, they mean agents whose governance layer deliberately makes some context common and keeps the rest private.

The design question is never "should agents share context" but "which layer should hold this fact, and who is allowed to read it." Answer that per fact type and the architecture follows.

Patterns teams use

Five patterns show up in nearly every working multi-agent setup. Most teams combine several of them.

Shared workspace

Agents read and write common artifacts: a findings record, a draft document, a decision log. The workspace is the blackboard the team gathers around. When to use it: when a deliverable or an intermediate finding must be visible to several agents and to humans, and when "who saw what" needs to be obvious rather than reconstructed from logs.

Scoped retrieval

The team stores far more than any prompt can hold, and each agent retrieves a narrow, relevance-ranked slice instead of reading everything. Scopes decide what is even eligible for retrieval. When to use it: the moment accumulated memory outgrows what fits in a context window, which happens within weeks on any active team. Retrieval without scopes eventually leaks; scopes without retrieval eventually flood.

Lead-and-worker coordination

A lead agent breaks an objective into tasks, delegates them to workers, monitors progress, and gives feedback. Workers report results back to shared records instead of negotiating peer to peer. When to use it: whenever tasks have dependencies, quality gates, or different required expertise. Hub-and-spoke coordination keeps write conflicts low because the lead arbitrates, at the price of making the lead a component you have to monitor.

Durable records

Task history, decisions, and findings persist as append-only records that survive restarts and redeploys. When to use it: when you will later ask "why did we decide this," when new agents must onboard onto existing team knowledge, and when an audit trail matters. Microsoft's shared agent context writeup describes the same operational shape: agents investigate in real time, then persist findings where humans already work.

Human review

People steer running tasks and approve sensitive or irreversible actions before they execute. When to use it: for anything customer-facing, anything that spends money, and anything that cannot be undone. Asana's work on agents built for teams makes the broader point well: shared work needs transparency about what the agent did and why, or humans stop trusting the system and route around it.

Risks and how to contain them

Shared context multiplies both the value and the blast radius of what agents write. This section is the part most vendor pages skip, and it is the part that decides whether your setup survives contact with production.

Context contamination. One agent writes a wrong or outdated fact to shared context, and every other agent retrieves it later as trusted input. Because retrieval feels authoritative, the error compounds across sessions instead of staying local to one run. Mitigation: validate on write, keep the shared scope curated rather than a free-text dump, and expire unverified facts instead of letting them live forever.

Permission leakage. A single shared store flattens access: anything written to it becomes visible to every agent, including agents that have no business seeing it. The failure is quiet, because nothing errors. Mitigation: decide per fact type what is shared versus private, keep sensitive material out of the shared scope entirely, and never let credentials live in any context an agent can read.

Stale facts. A fact that was true when written gets retrieved months later as if it were current. Statuses, counts, and decisions age badly. Mitigation: timestamp everything, set time-to-live on categories that decay, and re-read the live state of ongoing work at the moment you act on it rather than trusting the stored version. The mechanics of how memory degrades, and how poisoning compounds across repeated writes, are covered in our memory poisoning and decay deep dive.

Conflicting writes. Two agents write different versions of the same fact, and the next reader gets whichever one retrieval happens to rank higher. There is no magic merge: unless the platform explicitly offers compare-and-set semantics, assume last-writer-wins and design around it. Mitigation: assign a single writer per record where you can, route contested facts through the lead for arbitration, and surface conflicts to a human instead of silently picking one. Our coordination anti-patterns deep dive walks through the failure shapes this produces.

Prompt-injection propagation. One agent reads hostile content from a web page, ticket, or message and writes a summary of it into shared context. A later agent retrieves that summary, and the embedded instruction fires in a new context with new permissions. Shared context turns a one-agent injection into a team-wide one. Mitigation: treat retrieved content as data, never as instructions, strip imperative phrasing on write where feasible, and require human approval before agents act on instructions that originate from retrieved content.

None of these risks is a reason to avoid shared context. They are the reason the word "governed" belongs in the definition.

How Agent Swarm implements shared context

Agent Swarm is an open-source operating system for multi-agent work, and its shared-context model maps directly onto the patterns above. This section sticks to documented behavior; for anything beyond it, the architecture overview and memory documentation are the source of truth.

Two memory scopes, deliberately simple. Every memory in Agent Swarm is either agent-scoped, private to the agent that owns it, or swarm-scoped, readable by all agents. One deliberate exception: the lead's memory searches span every agent's private scope, because the lead curates the shared layer and needs to see what workers accumulate to do it. The lead can push a learning into a worker's memory with inject-learning, which creates a swarm-scoped memory by default, so a lesson learned in one task becomes available to the whole team. Only the lead can delete swarm-scoped memories, and editing another agent's memory requires the lead, which keeps the shared layer curated instead of crowdsourced. Memory search respects scope at retrieval time, and the graph expansion that follows links between memories can never widen what a search is allowed to see.

Retrieval is automatic, and failures are remembered. Before each task starts, the runner searches for memories relevant to the task description and injects the top matches into the agent's context. Every completed or failed task output is indexed, and failed tasks carry notes about what went wrong, so the swarm avoids repeating the same mistake. This is the scoped-retrieval pattern running by default rather than as a plugin.

Isolated workers, one shared volume. Each worker runs in its own container with a private /workspace/personal directory. There is also a single /workspace/shared volume mounted into every agent. It is shared by design: there are no per-agent permissions on that volume, so treat it as a team blackboard and keep anything sensitive out of it. The lead-and-worker structure is hub-and-spoke: the lead breaks work down, delegates, monitors, and gives feedback, as described in the multi-agent orchestration guide.

Credentials stay out of agent context. Secrets in the config store are encrypted at rest with AES-256-GCM. API calls can go through registered connections, so credentials are injected at egress and never enter the agent's context at all. This is the containment for the permission-leakage risk above, and the credential plane deep dive explains the mechanics. The Security and Trust page and the integrations catalog cover the surrounding posture. One precision worth stating: role-based access control in Agent Swarm governs REST API calls made with user tokens; it does not gate agent-to-agent calls inside the swarm. Governance between agents comes from memory scopes and lead privileges, not from per-user ACLs on agents. Our AI access control guide goes deeper on that boundary.

Self-hosted by default. The SQLite database holding tasks, memory, and config lives on a volume you own, and workers call your chosen model provider with your keys. If you run the managed cloud instead and need specifics about data location or retention, ask through the contact on the Security page rather than relying on a blog post.

Humans stay in the loop. Task steering lets a person redirect a running task, and approval requests pause work until a human signs off, which is the containment for irreversible actions. The human-in-the-loop guide covers the pattern. You can see all of this operating in real sessions in the examples collection. For a deeper treatment of shared-state contracts, conflict handling, and persistence, the Spanish deep dive on shared agent state covers the conceptual layer in detail.

Getting started

You do not need the full architecture on day one. Four steps get a team to governed shared context without overbuilding.

1. Decide what is shared versus private before you write anything. List your fact types: team definitions, decisions, findings, credentials, personal working notes. Assign each a layer from the table above. Credentials get the shortest answer: never in any context, shared or private, that an agent can read.
2. Start with swarm-scoped memory for agreed definitions only. Seed the shared scope with the facts the whole team has already agreed on, and let everything else accumulate in private scopes until it earns promotion. A small, trusted shared scope beats a large, noisy one every time.
3. Keep credentials in registered connections. Store API keys in the encrypted config store and route external calls through connections so secrets are injected at egress. This removes the single most damaging leak path before it exists.
4. Add human approval on irreversible actions. Identify the actions you cannot undo, production deploys, customer messages, deletions, and gate them behind approval requests from the start. Retrofitting review after an incident costs far more than the friction it saves.

Sources

Two external pieces shaped the citation shape of this guide and are worth reading directly.

• AI agents built for teams: context, transparency, and accountability (Asana), on why shared agent work needs inspectable context and action-level accountability to earn team trust.
• Shared agent context: tackling partner agent collaboration (Microsoft), on the operational pattern of agents investigating in real time and persisting findings where humans already work.

FAQ

What are shared-context AI agents?

Shared-context AI agents are several agents working toward one team objective that read from and write to a common, governed context instead of each starting from a blank prompt. The shared context holds definitions, decisions, findings, and task history. Teams use them when work spans more than one agent session and re-learning the same facts per agent costs more than governing a shared store.

What is the difference between shared context and memory?

Long-term memory is a durable store of curated facts that gets retrieved into a model's context window on demand. Shared context is the subset of that stored context, plus shared artifacts and records, that is deliberately made visible to every agent on the team. Memory answers "what persists," while shared context answers "who is allowed to see it."

How do teams keep agents from seeing everything?

By scoping. Each piece of stored context carries a scope that decides which agents may retrieve it, and retrieval respects those scopes automatically. A private scope is readable only by the agent that owns it, with one exception: the lead's memory searches span every agent's private scope, because the lead curates the shared layer. So a private scope is working room, not a vault. Sensitive material belongs out of agent context entirely, and credentials should live in an encrypted store that injects them at egress rather than into anything an agent can read.

Can shared context be self-hosted?

Yes. Agent Swarm, for example, stores tasks, memory, and config in a SQLite database on a volume you own, and workers call your chosen model provider with your own keys. Self-hosting gives you direct control over where the shared context physically lives and who can reach the machine that holds it.

What happens when two agents write conflicting facts?

Unless the platform offers explicit compare-and-set semantics, assume last-writer-wins and design around it. Practical teams assign a single writer per record where possible, route contested facts through a lead agent for arbitration, and surface unresolved conflicts to a human reviewer instead of silently picking one version.

How do humans review what agents share?

Through steering and approval gates. Task steering lets a person redirect running work, and approval requests pause sensitive or irreversible actions until a human signs off. Durable task records and inspectable memory make the review possible, because a human can see what was written, by whom, and why.