Shared Context in Multi-Agent AI: What to Build
Shared context in a multi-agent system means every agent working from the same governed record of facts, decisions and state, not just the same wire protocol. Interoperability standards like MCP and A2A move messages between agents reliably; they do not decide what gets remembered, who is allowed to see it, which version is current, or how a contradiction between two agents’ beliefs gets resolved. Architects have to build that layer themselves.
What Does “Shared Context” Actually Mean in a Multi-Agent System?
Shared context is not a bigger prompt window. It is a governed store that every agent in a system reads from and writes to, with rules about what gets promoted into it and who can see what.
Treat context sharing as a copy-paste problem and you get the failure mode every production multi-agent deployment eventually hits: Agent A learns a customer’s refund was denied, Agent B never sees that fact and approves a duplicate refund, and nobody can explain afterwards which agent knew what, when. The underlying issue is architectural, not a prompting bug. Multi-agent systems need a memory layer that answers not just “can the model retrieve this” but “should this specific agent see this specific version of it right now,” a distinction most teams don’t design for until they’ve already shipped an incident report (Zylos Research on multi-agent memory architectures).
Why Don’t MCP and A2A Already Solve This?
MCP and A2A standardise how agents move information, not what they’re allowed to remember, share or trust once it arrives.
Model Context Protocol gives an agent a uniform way to pull data and invoke tools from external sources, replacing bespoke integrations with a single client-server pattern. Agent2Agent gives two agents a shared vocabulary for discovering each other’s capabilities and tracking a task through its lifecycle. Both are genuinely useful, and both are silent on the harder question: once Agent A calls Agent B, what happens to the fact that got exchanged? Does it get written anywhere durable? Who else can read it? What happens when Agent C, three hops later, retrieves a version of that fact that’s since changed?
Surveys of the protocol landscape keep landing on the same gap: MCP and A2A are largely stateless communication standards, and neither tracks what an agent did, what data it touched, or how the result was used downstream once the call completes (survey of agent interoperability protocols, arXiv). That gap doesn’t close itself as more protocols get adopted. It gets wider, because more protocol adoption means more agents passing more context through a layer nobody built to hold it.
What Does an Architect Actually Have to Build?
Five things, none of which come from a protocol spec, and all of which have to exist before a second agent joins the system, not after.
- A context assembly service. A dedicated layer that retrieves, filters, ranks and formats context for each agent’s specific task, rather than every agent independently querying a shared database and interpreting the results differently.
- A promotion policy. Rules for which facts move from an agent’s private working memory into the shared store. Not everything an agent infers deserves to become institutional memory; promotion has to be a deliberate gate, not a default.
- Versioning and supersession. When a fact changes (the refund was actually approved on appeal), the old version doesn’t get silently overwritten. It gets superseded, with both versions traceable, so an agent that acted on stale information can be identified after the fact.
- Scoped access control. Per-agent, per-task visibility rules, so an agent handling a billing query doesn’t have standing access to HR context just because both live in the same shared store.
- Provenance and trace records. Which source, which policy version and which context snapshot shaped a given agent’s decision, captured at decision time, not reconstructed afterwards from logs that weren’t designed for it.
Recent architecture proposals for governed shared memory formalise roughly this same list: scoped visibility, policy enforcement, temporal correctness and synchronisation semantics as the non-negotiable requirements for production multi-agent memory, not optional hardening (Governed Shared Memory for Multi-Agent LLM Systems, arXiv). None of it is exotic engineering. It is exactly the kind of unglamorous data-architecture work that gets skipped when a team is excited about getting two agents to talk to each other at all.
Where Does the Protocol Layer End and the Architecture Layer Begin?
| What the protocol gives you | What the architect still has to build | |
|---|---|---|
| MCP | Uniform tool and data access for one agent | Which retrieved facts get retained, and for how long |
| A2A | Task discovery, lifecycle and transport auth between two agents | What happens to exchanged context after the task completes |
| Neither | Shared vocabulary for a single message | Cross-agent memory, versioning, and a source of truth for contested facts |
| Neither | Point-to-point security | Scoped visibility across an arbitrary number of agents and teams |
The pattern in every row is the same: protocols solve the transport problem well, and stop exactly where the persistence and governance problem starts. Treating protocol adoption as if it were the interoperability solution is a common early mistake, and it’s an expensive one to unwind once three or four agents are already writing to whatever ad hoc store got stood up first.
How Should Architects Decide What Gets Promoted to Shared Memory?
Promote a fact to shared context only when a second agent’s correctness depends on knowing it, not simply because an agent produced it.
Agent-local memory should stay private by default. It’s cheaper to store, cheaper to reason about, and it doesn’t force every other agent in the system to filter noise out of a shared store. Promotion becomes necessary only when a fact has genuine cross-agent relevance: a decision that changes what another agent should do next, a state change that another agent will otherwise duplicate, or an event that needs to be auditable regardless of which agent produced it. Layering memory this way, agent-local first and shared second, mirrors how well-run engineering teams already separate a service’s internal state from its published events; multi-agent systems just make the cost of skipping that separation visible faster, because the contradictions surface as agents acting on stale or private beliefs rather than as a slow data-quality drift nobody notices for months (mem0.ai on multi-agent memory design).
What Governance Has to Sit on Top of the Context Store?
Durable shared memory needs source tracking, expiry and a genuine hard-delete path, not just a growing log of everything agents have ever said to each other.
A shared context store that only ever appends will eventually contain contradictions nobody resolves, deprecated facts nobody expires, and personal data nobody can prove was deleted when asked. Each record needs a source (which agent, which upstream system), a lifecycle (active, superseded, expired), and a deletion path that actually removes data rather than soft-flagging it while it stays retrievable. This is governance work, and it’s exactly the kind of decision that has to be made by someone thinking about the business’s data obligations and audit requirements, not left to whichever team happens to stand up the first vector store. It’s also precisely the kind of question that gets missed when a business buys a multi-agent platform off the shelf and assumes the vendor’s defaults cover it: the platform can enforce whatever policy you configure, but it can’t tell you what that policy should be for your specific regulatory exposure and your specific data.
This is the diagnose-first argument in its clearest form. The technical question, “which memory framework do we adopt,” is downstream of a business question: which facts in this organisation are contested often enough, or sensitive enough, that a wrong shared version causes real damage. Architecture that starts from the framework and works backwards to the business almost always under-builds the governance layer, because frameworks ship with permissive defaults and businesses discover their actual risk tolerance only after something has already gone wrong.
FAQ
Does adopting MCP and A2A mean my agents already share context? No. Both standardise message transport and task discovery between agents; neither specifies what happens to exchanged information afterwards, so shared memory still has to be designed and built separately.
Is a shared vector database enough for multi-agent context? On its own, no. A vector store gives you retrieval, not scoped visibility, versioning, promotion rules or provenance, all of which are what actually prevent one agent acting on another agent’s stale or private belief.
Should every agent write to the same shared memory? No. Keep agent-local memory private by default and promote only facts that another agent’s correctness genuinely depends on; a store that accepts everything becomes noise every agent has to filter.
What’s the first thing to build if we’re adding a second agent to an existing single-agent system? A promotion policy and a provenance record, before the second agent goes live. Retrofitting who-knew-what-when after an incident is far more expensive than deciding it upfront.
Does the EU AI Act or similar regulation require this kind of context governance? Regulatory frameworks increasingly expect traceability of automated decisions, which in practice means provenance and audit records for shared agent context; treat this as a compliance requirement to scope early rather than a technical nicety to add later.
Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.