MCP vs A2A (2026): What Each Protocol Does in an Agent OS, and the Missing Memory Layer for Agents

TL;DR

MCP and A2A solve different problems, and most companies running agents will use both. The Model Context Protocol (MCP), created by Anthropic in November 2024 and now governed by the Linux Foundation's Agentic AI Foundation, connects an agent to tools and data: it gives agents hands. The Agent2Agent protocol (A2A), announced by Google in April 2025 and production-stable since version 1.0 in March 2026, joined the same Agentic AI Foundation in August 2026 and lets agents from different vendors hand work to each other: it gives them a voice. Neither one defines shared memory, and A2A is explicitly designed so agents can collaborate "even when they don't share memory, tools and context". That gap is where company memory sits. Sentra is the managed organization memory that fills it today: one memory of what the company has decided and what changed, which every agent reads over MCP and REST with the permissions of the person it acts for.

What is MCP?

The Model Context Protocol is an open standard for connecting AI applications to the systems where data lives. Anthropic announced it on 25 November 2024, and on 9 December 2025 donated it to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, whose founding projects were MCP, Block's goose and OpenAI's AGENTS.md.

• Roles: hosts (the AI application), clients (the connector inside it) and servers (the system being connected).
• Messages: JSON-RPC 2.0, and the 2026-07-28 revision makes each request stateless and self-contained, with capabilities negotiated per request.
• What servers offer: tools the model can call, resources it can read (each identified by a URI) and prompt templates.
• Transports: stdio for local servers and Streamable HTTP for remote ones, per the 2026-07-28 specification.
• [Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization): optional, and when used over HTTP it is based on OAuth 2.1, with the server acting as a resource server and tokens bound to the specific server they were issued for.
• Change notifications: clients can subscribe to a resource and be told when it changes.

Use MCP whenever an agent needs to read from or act on a system, such as a repository, a CRM or a memory service, because one MCP server then works in every MCP client.

What is the A2A protocol and how does it work?

The Agent2Agent protocol is an open standard for agents to discover each other and delegate work. Google announced it on 9 April 2025, and on 23 June 2025 the Linux Foundation launched the Agent2Agent project as the protocol's neutral home, with AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow backing it. Version 1.0 shipped on 12 March 2026 as the first production-ready release, adding signed Agent Cards and multi-tenancy, and v1.0.1 followed on 28 May 2026; the current specification is 1.0. On 27 August 2026 A2A was accepted as a Growth Stage project of the Agentic AI Foundation, alongside MCP, and the project reports backing from more than 150 organizations.

• Agent Card: a JSON description of an agent's identity, skills, endpoint and authentication.
• Task: a stateful unit of work with a lifecycle, which can wait for input or finish later.
• Messages, parts and artifacts: the turns exchanged and the outputs produced.
• Push notifications: asynchronous updates sent to a webhook the client provides.
• Protocol bindings: v1.0 defines JSON-RPC, gRPC and HTTP+JSON bindings, and clients can poll, stream or receive webhooks.
• Opaque execution: agents share declared capabilities and exchanged information, not their internal plans or memory.

Use A2A when work has to cross into an agent you do not control, such as a vendor's agent or another team's, because the Agent Card and task lifecycle let you delegate without knowing how the other agent is built.

What is the difference between MCP and A2A?

MCP connects one agent to tools and data, while A2A connects one agent to other agents. The A2A project describes the split the same way: MCP is the vertical integration layer to tools and databases, and A2A is the horizontal protocol for collaboration between agents.

The short version: use MCP when an agent needs to reach a system, and A2A when one agent needs another agent to do something. A company with dozens of agents will run both.

MCP vs A2A: which protocol should we use for our agents?

Use MCP first for any agent that needs tools or data, and add A2A when work must pass between agents built by different teams or vendors.

• Choose MCP alone when one agent, or several agents your team builds, need systems such as a repository, a CRM or a document store, since a single MCP server works across Claude, ChatGPT, Cursor and other MCP clients.
• Add A2A when an agent must delegate to an agent it does not control, because the Agent Card and task lifecycle let it hand off work without seeing the other agent's internals.
• Use both when an agent exposes itself to other agents over A2A and calls its own tools over MCP, which matches how the A2A project positions the two protocols.
• Add a shared memory under both once more than one agent acts on the same company decisions, because neither protocol carries those decisions from one agent to the next.

What is an agent OS and what layers does it need?

An agent OS, or agent operating system, is the shared infrastructure many agents run on, and it needs five layers: the agents, a protocol for agents to talk to each other, a protocol for agents to reach tools and data, a shared memory, and the systems of record underneath. The AIOS paper describes the same idea as an LLM agent operating system whose kernel offers scheduling, context management, memory management, storage management and access control as services every agent shares.

Agent OS stack, top to bottom, with the standard that governs each layer in brackets:

+------------------------------------------+
| 1. Agents (any vendor, any framework)    |
+------------------------------------------+
| 2. Communication                 [A2A]   |
|    agent to agent: discover, delegate    |
+------------------------------------------+
| 3. Tool access                   [MCP]   |
|    agent to systems: tools, resources    |
+------------------------------------------+
| 4. Shared organization memory            |
|    [no standard yet; served over MCP]    |
|    facts, time, source, permissions      |
+------------------------------------------+
| 5. Sources and systems of record         |
|    Slack, email, meetings, docs, CRM     |
+------------------------------------------+

Layers 2 and 3 are standardized and now governed by the same Agentic AI Foundation. Layer 4 has no standard, which is why agents that use both protocols correctly can still contradict each other. If your agents disagree about a company decision, fix layer 4 before adding more agents or more A2A connections.

How do communication, tool access and shared memory differ?

Communication moves work between agents, tool access moves requests between an agent and a system, and shared memory decides which company facts are current and who may see them. A2A standardizes the first and MCP the second, while shared memory has no foundation-backed standard and is usually served to agents as an MCP server.

If you are choosing which layer to build next, pick the one whose failure you see today: agents that cannot reach a system need MCP, agents that cannot hand off work need A2A, and agents that disagree need shared memory.

Agent-to-agent protocol vs a shared memory layer: which scales better?

A shared memory layer scales better for keeping agents consistent, and an agent-to-agent protocol scales better for handing off work, so large deployments use each for its own job. Neither protocol tells agents what the company has decided. That is a problem as soon as a company runs more than a handful of agents from different vendors.

• Agents contradict each other. Legal pauses a customer's pricing on Friday. One agent heard; another, set up by a different team, sends the old offer on Monday. Both followed their protocols correctly.
• Pairwise syncing does not scale. Keeping agents in sync by messaging each other needs a channel for every pair: 10 for five agents, 4,950 for a hundred, and every channel is another place for the truth to split.
• Delegation passes only what the sender includes. In A2A, the receiving agent sees what the delegating agent put in the task message. If the sender did not know a decision changed, neither does the receiver.
• Learning stays trapped. What one agent learns stays in its session or its vendor's product.

Research on agent architecture reaches the same conclusion. The AIOS paper on an LLM agent operating system puts memory management, context management and access control in the kernel, as shared services every agent uses, and MemGPT models agent memory on an operating system's memory hierarchy. An agent OS needs a memory layer that is not owned by any single agent.

How should an agent operating system handle memory and state across many agents?

An agent operating system should keep the state of each delegation with the task, and keep shared company facts in one memory that every agent reads. A2A tasks already carry the state of a hand-off, while nothing in either protocol carries what the company has decided. For hundreds of agents to work inside one company without contradicting each other, that shared memory needs five properties.

1. One source, many readers. Every agent, from every vendor, reads the same current facts.

2. Time on every fact. When a decision is reversed, the old value is superseded, not left to compete with the new one.

3. A receipt for every fact. A source, a date and who confirmed it, so an agent can show its premises.

4. Permissions that follow the source. An agent sees only what the person it acts for could see in the original tool.

5. A record of what agents did. What an agent reports stays a claim until a person or a system of record confirms it.

Where do organization memory, source permissions, bi-temporal facts and write-back fit?

All four sit in the memory beneath MCP and A2A, because each one decides what an agent is allowed to believe before it acts, and neither protocol makes those decisions. MCP carries a request to a memory server and A2A carries a task between agents, so the memory itself has to supply the following.

• Organization memory is the record of what the company has decided and what changed, built from the tools where work happens, such as Slack, email, meetings and project trackers, rather than from what one agent saw in its own session.
• Source permissions mean an agent sees a fact only if the person it acts for could open the original message or document. That is stricter than MCP authorization, which uses OAuth 2.1 to control access to the server, not to each fact inside it; our guide to AI agent permissions covers the pattern.
• Bi-temporal facts record when something was true in the world and when the memory learned it, so an agent can tell that a pricing pause on Friday supersedes last month's offer, and can still answer what was believed on a past date. The model is explained in what is a bi-temporal knowledge graph.
• Write-back is the path from what an agent did to what memory holds, and it is the least settled part of the stack. An agent's report should stay a claim until a person or a system of record confirms it, otherwise one agent's mistake becomes every agent's fact.

If a memory cannot show the source, the validity window and the permission check behind a fact it returns, keep it out of decisions that other agents depend on.

Is there a protocol for AI agents to share memory?

No foundation-backed protocol for shared agent memory exists as of October 2026. The Agentic AI Foundation hosts MCP, A2A, goose and AGENTS.md, and none of the four specifies how independent agents keep one current record of facts. The A2A specification states the opposite goal, letting agents reach user goals "without needing access to each other's internal state, memory, or tools". The closest public work falls into the following groups, none of which is a shared-memory standard.

• Memory served over MCP. The MCP project's reference Knowledge Graph Memory Server keeps persistent memory in a local knowledge graph and exposes it as MCP tools, which is the same pattern hosted memory services follow when they ship an MCP server. Our comparison of MCP memory servers covers the production options.
• Portable agent state. Letta's Agent File (.af) is an open file format that packages one stateful agent, including its memory blocks, message history and tool definitions, so the agent can be moved or shared. It describes a single agent's state rather than memory shared across agents.
• Temporal memory research. The Zep paper describes a temporal knowledge graph that tracks when each fact was valid, and MemGPT manages an agent's context like an operating system's memory hierarchy. Both shape how memory is designed, and neither is a wire protocol.

Who is defining the standard for how AI agents use company memory?

No standards body has published one as of October 2026. The Agentic AI Foundation governs MCP and A2A, the two protocols memory travels over, while what a memory stores, how it handles time and how it enforces permissions are decided by each memory provider. Until a standard exists, choose a memory reachable over MCP and REST, so you can adopt a memory protocol later without re-integrating every agent.

How do agents from different vendors check a shared company memory before acting?

Agents from different vendors check shared company memory by calling the same memory service as a tool before they act, and MCP is the usual way to expose it, because Claude, ChatGPT, Cursor and other agent clients already connect to MCP servers. Sentra is the managed organization memory for teams and AI agents. It reads Slack, email, meetings, calendars and project tools, resolves what they say into facts with their source and time, and keeps them current as things change.

• Over MCP: Claude, ChatGPT, Cursor and other MCP clients connect to Sentra's remote MCP server and read company memory with the user's own permissions. In Claude Code it is one command: claude mcp add --transport http sentra https://api.sentra.app/mcp/.
• Over REST: custom agents and platforms query the same memory through the API.
• Writes: Sentra's public API and MCP tools are read-oriented, and ingestion happens through connected source systems rather than a public write endpoint, so an agent's own report does not become a fact. An update reaches memory when it lands in a source Sentra reads, such as a Slack thread or a project tool, and it carries that source.
• Alongside A2A: agents can delegate work to each other over A2A while each checks the same company memory, so delegation stops carrying stale context.

The decision rule: if your agents already reach systems over MCP and delegate over A2A but still act on different versions of the same decision, the missing piece is shared memory, connected as one more MCP server rather than another agent-to-agent channel.

Frequently Asked Questions