The Missing Layer: No Protocol Says What Agents Know

TL;DR

• A2A (Agent2Agent) standardizes agent-to-agent work. MCP (Model Context Protocol) standardizes access to tools and external context. Neither defines persistent shared-memory semantics.
• Our decomposition identifies five requirements for agent memory interoperability: identity and addressing, schema, trust and provenance, consistency, and permissions.
• Teams often avoid protocol-level exchange by connecting every agent to one shared store. The store’s record format, access controls, and transaction model then become the implicit protocol.
• Early proposals address parts of the problem. But no ratified interoperability standard for agent memory exists as of July 2026.

Memory interoperability is the ability of agents and memory systems to identify, exchange, interpret, verify, synchronize, and control access to persistent knowledge across implementation boundaries.

The memory gap is the absence of standardized protocol-level semantics for persistent shared knowledge between agents. A2A vs MCP and A2A Protocol Explained established this gap.

That omission follows A2A’s stated design: agents collaborate “without needing access to each other’s internal state, memory, or tools” (A2A specification; A2A overview). That principle is fine for task handoffs. It becomes a wall when agents need to share what they learned after the task completes.

Five requirements for agent memory interoperability

The table below is our own decomposition, not an existing protocol taxonomy. It breaks the memory gap into five faces that a usable interoperability layer would need to specify.

Face	Required protocol semantics	What specifications provide today	What practitioners improvise
Identity and addressing	Namespaces, addresses, and discovery for an agent’s memory or a shared memory space	A2A identifies agents and endpoints, not their memory. MCP identifies servers and exposed features, not portable memory spaces (A2A; MCP).	A shared connection string for a central vector store, database, blackboard, or knowledge graph (reported patterns).
Schema on the wire	Fields, types, authorship, time, confidence, and provenance for a memory entry	A2A Parts and Artifacts carry task outputs. MCP Resources carry context. Neither types a persistent “memory” (A2A; MCP).	Framework-specific records and bespoke export or import formats.
Trust and provenance	Origin, integrity, tamper evidence, and rules for deciding whether to consume an entry	A2A transport authentication can identify an agent, and MCP authorization authenticates a client to a server. Neither establishes the trustworthiness of stored knowledge (A2A; MCP).	Nothing standard — entry-level verification is application-specific or absent.
Consistency	Ordering, conflict resolution, stale-read behavior, and guarantees for concurrent writes	A2A and MCP define no consistency model for persistent shared memory (A2A; MCP).	One central store whose transaction model becomes the de facto consistency model (reported patterns).
Permissions	Read and write scopes, isolation boundaries, grants, and revocation for memory spaces	A2A and MCP authorize interactions or API calls, not interoperable memory-space permissions (A2A; MCP).	Store-level ACLs, application checks, or shared access for every agent.

1. Identity and addressing

Agent B needs a stable way to name and reach agent A’s memory, or a shared memory space both agents use. That requires a namespace, an address scheme, and some form of discovery.

A2A’s Agent Card names an agent, not its memory. MCP addresses tools, not memory spaces (A2A specification; MCP specification). An Agent Card advertises an endpoint. MCP can expose a memory service as another server. But neither defines how to name memory spaces across systems.

Teams often collapse the problem into infrastructure setup. Each agent gets credentials and a connection string for the same vector store, blackboard, database, or knowledge graph (shared-memory patterns). The shared backend becomes the address.

Named memory domains — agent:researcher, project:acme, team:* — are one documented implementation of explicit addressing. See Shared Memory for Multi-Agent Systems. They are an implementation choice, not a cross-system standard.

2. Schema on the wire

Once an agent finds a memory space, it still needs to know what an entry means. A protocol must type the entry and define its metadata: author, creation context, confidence, and provenance.

A2A Parts and Artifacts carry task communication and output. MCP Resources expose context from a server. Neither specification defines a portable memory record with persistent-memory semantics (A2A specification; MCP specification).

Portable Agent Memory proposes a model written as M = (E, S, P, W, I): Episodic, Semantic, Procedural, Working, and Identity memory. This is one preprint and a proposal, not a standard.

Without a shared schema, frameworks define their own records. Moving memory between them becomes a bespoke JSON conversion, not protocol-level exchange. The review Externalization in LLM Agents documents the broader shift toward external memory infrastructure.

3. Trust and provenance

Authentication answers who sent an entry. Provenance and integrity answer where the entry came from, whether it changed, and whether another agent should use it.

A signed Agent Card can establish the card’s origin and integrity. It does not prove that an agent’s stored claims are trustworthy. A2A does not sign individual memory entries. The authentication mechanics belong to a separate trust problem. How Do Two AI Agents Trust Each Other? covers it.

The security impact is direct. OWASP’s Top 10 for Agentic Applications (2026) names ASI06, “Memory & Context Poisoning” (OWASP Agentic Security Initiative). When agent B ingests a poisoned entry from agent A, memory exchange becomes a cross-agent attack path. The named mitigations are gated writes, provenance tracking, memory segmentation, and treating stored memory as untrusted input. These are exactly the primitives a memory protocol would have to specify. Memory Poisoning covers the full persistence-to-secret-leak chain.

The same Portable Agent Memory preprint proposes Merkle-DAG provenance, including “content-addressable entries” that provide “tamper-evidence.” That is one proposed design for this face, not an adopted protocol.

4. Consistency

Shared memory creates distributed-state questions. A standard must say what happens when agents write concurrently, read stale data, or see updates in different orders.

A2A task context ends with the task interaction. MCP state belongs to a client-server tool relationship. Neither defines ordering or conflict semantics for persistent knowledge shared across agents (A2A specification; MCP specification).

Yu et al. state the issue directly in Multi-Agent Memory from a Computer Architecture Perspective: “We argue that the most pressing open challenge is multi-agent memory consistency.” The same paper describes context-I/O protocols such as MCP as necessary but not sufficient.

How unsettled is this, exactly?

Even the paper's own framing moved between revisions. Its March 9 v1 declared, in its consistency section, "The largest conceptual gap is consistency." — and the March 30 v2 removed that sentence, keeping the softer abstract claim quoted above. When the authors of the field's reference analysis are still revising how to name the gap three weeks after publishing, a ratified consistency standard is not around the corner. It is also a working lesson in citation hygiene: quote the version the server actually serves.

Under our decomposition, a memory standard would need to pin down three things. It must define a consistency model (eventual, causal, or linearizable). It must define conflict resolution (last-writer-wins, CRDTs, or custom merge rules). And it must set explicit staleness bounds. Centralized deployments hand all three choices to one database. Its transaction model becomes the de facto consistency model (reported patterns). That works only while every participant can use the same store and accept its transaction model. It defines nothing across organizational or vendor boundaries.

5. Permissions

A memory address cannot imply universal access. An interoperability layer needs rules for who may read or write each memory space. It also needs rules for how to scope grants and how to preserve isolation.

A2A and MCP can authorize calls. But that does not create a shared permissions model for memory spaces. MCP authorization remains a client-to-server concern (MCP authorization spec). Portable Agent Memory proposes capability-based access controls — again as part of a preprint, not a ratified standard.

In many deployed systems, teams attach ACLs to the common backend or let all participating agents read the same store. Tenant isolation and hierarchical read scopes are one documented implementation of the former. See Shared Memory for Multi-Agent Systems.

Early agent memory protocol proposals

The absence of a ratified standard does not mean the field is idle.

SAMEP proposes a persistent memory layer beside MCP and A2A. It is motivated by “ephemeral memory limitations, preventing effective collaboration and knowledge sharing across sessions and agent boundaries.”

Portable Agent Memory proposes memory types, cryptographically verifiable provenance, capability-based access controls, and transfer across heterogeneous agents. That covers parts of the schema, provenance, and permissions faces in one design.

Other unstandardized proposals include memorywire, UMP, and WAMP (memorywire preprint). Their spread strengthens the gap diagnosis. Projects keep defining competing pieces because no accepted interoperability layer supplies them.

Is there a standard for agent memory interoperability?

As of July 2026 there is no ratified interoperability standard for agent memory. Standardization is nascent and fragmented. A W3C Community Group, “AI Agent Memory Interoperability” (proposed 2026-05-18), is drafting — but W3C Community Groups are not standards-track. No IETF working group is chartered for memory exchange (CATALIST addresses agent communication and WIMSE workload identity/auth — both adjacent, neither memory; outside the IETF, Google’s AP2 covers agent payments). No Linux Foundation project is chartered for it either (the LF and its Agentic AI Foundation host MCP and A2A themselves).

So the open question is not whether agents need persistent memory. The concrete interoperability question is who will define the address, record, evidence, consistency, and permission semantics that let independent systems exchange it.

Common questions

Is there a standard for agent memory interoperability?

As of July 2026, there is no ratified interoperability standard for agent memory. A W3C Community Group is drafting in this area, but Community Groups are not standards-track, and no IETF working group or Linux Foundation project is chartered for memory exchange.

Do A2A or MCP define agent memory?

No. The A2A specification defines agent-to-agent tasks, messages, artifacts, and discovery, while MCP connects an LLM application to external data and tools. Neither defines persistent shared-memory semantics or a standard memory entry.

What would an agent memory protocol have to specify?

Our decomposition identifies five faces: identity and addressing, schema on the wire, trust and provenance, consistency, and permissions.

What is the biggest open problem in multi-agent memory?

The paper Multi-Agent Memory from a Computer Architecture Perspective argues that “the most pressing open challenge is multi-agent memory consistency.” A protocol must define ordering, conflict handling, and stale-read behavior across agents.

What early agent memory interoperability proposals exist?

SAMEP proposes a persistent memory layer beside MCP and A2A. Portable Agent Memory proposes a typed memory model, Merkle-DAG provenance, capability-based controls, and memory transfer across heterogeneous agents. Both are proposals, not ratified standards.

Related

• A2A vs MCP
• A2A Protocol Explained
• Shared Memory for Multi-Agent Systems
• How Do Two AI Agents Trust Each Other?
• Memory Poisoning: The Patient Path to Your API Keys

Published July 12, 2026. By Edward Izgorodin.