A2A, MCP and a shared room: what each one does

What the A2A and MCP protocols each do for AI agents, and what a shared room adds when the agents belong to different companies: agreements, memory and approval.

By Bhawesh Tibrewal · · 8 min read

Copy this page as Markdown

On this page

Three names keep coming up when people plan how AI agents should work together: the Agent2Agent protocol (A2A), the Model Context Protocol (MCP), and the idea of a shared room. They are often mentioned in one breath, as if they were three answers to the same question. They are not. Each one answers a different question, and a working setup can use all three at once.

This article is for the people who connect AI agents to things: what each protocol is, in the words of the people who maintain it, how the two fit together, and what a shared room adds when the AI agents on either side belong to different companies.

The short answer#

MCPA2AA shared room
ConnectsAn AI application to tools and dataOne AI agent to another AI agentAI agents and people from several companies, on one project
The question it answersHow does my agent use this tool or read this data?How does my agent hand work to another agent and get the result back?What may each company’s agents touch, where does the shared context live, and who says yes before something can’t be undone?
What it isAn open protocolAn open protocolA place where the work happens, with rules each company agreed to

The rest of this article explains each row.

What MCP is#

The Model Context Protocol’s own documentation puts it in one line: “MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.” Anthropic introduced it on 25 November 2024 as “a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments.” On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, and said the project’s governance model would remain unchanged.

How it works, in the terms the protocol uses:

  • Host, client, server. The host is the AI application, such as an AI assistant or a code editor. It holds one MCP client for each MCP server it connects to. An MCP server is a program that provides context: it can run on the same machine, or remotely over the web.
  • What a server offers. Three kinds of thing: tools, “executable functions that AI applications can invoke to perform actions”; resources, “data sources that provide contextual information to AI applications”; and prompts, “reusable templates that help structure interactions with language models.”
  • How messages travel. The messages are JSON-RPC 2.0. A local server talks over standard input and output; a remote one over Streamable HTTP, which works with ordinary web authentication.

What MCP leaves to the application is just as useful to know. The architecture overview says that “MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context.” The specification asks hosts to obtain “explicit user consent before invoking any tool”, and adds that “MCP itself cannot enforce these security principles at the protocol level.” Consent, in other words, is built by whoever builds the application.

What A2A is#

The A2A project describes itself as “an open standard for communication between AI agents.” Google introduced it on 9 April 2025, describing it as an open protocol that “complements Anthropic’s Model Context Protocol (MCP)”. On 23 June 2025 the Linux Foundation announced the Agent2Agent project; A2A’s own site says it “was originally developed by Google and donated to the Linux Foundation.”

How it works, in the terms the specification uses (version 1.0.0 at the time of writing):

  • A client agent and a remote agent. One agent asks; the other does the work.
  • An Agent Card. “A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.” A client finds it at a well-known address on the remote agent’s server and reads from it how to authenticate.
  • Tasks. A task is “the fundamental unit of work managed by A2A”. It moves through set states, including working, completed and failed, and two in which the remote agent waits on the client: one when it needs more input, one when it needs authentication.
  • Messages, parts and artifacts. The two agents exchange messages made of parts (text, files or structured data), and the work comes back as artifacts.
  • Transports. JSON-RPC 2.0, gRPC, or plain HTTP and JSON, with streaming over server-sent events and push notifications to a webhook for long-running work.

One design choice matters for anyone connecting agents from two organisations. A2A calls it opaque execution: “Agents collaborate without exposing their internal logic, memory, or proprietary tools.” The remote agent stays a black box: in the protocol’s words, “Interactions rely on declared capabilities and shared context.”

How MCP and A2A fit together#

The A2A project’s own comparison is the clearest one: “MCP is for agent-to-tool communication” and A2A “is for agent-to-agent communication.” Its page on the two protocols puts it as a direction:

MCP is vertical. It deepens a single agent. … A2A is horizontal. It connects agents across that boundary. The other agent may belong to another team, another department, or a partner organization.

The same page lists what A2A is not, and the first line of that list is short: “Not a replacement for MCP.” An agent can use MCP to reach its own tools and A2A to ask another agent for help, in the same piece of work.

What a shared room adds when the agents belong to different companies#

Both protocols describe a conversation between two parties: an application and a server, or a client agent and a remote agent. When the other party belongs to another company, three questions come up that sit outside either protocol, because they are about the two companies rather than the two programs:

  1. What may the other company’s AI agents touch, and who decided that?
  2. Where does the shared context of the project live, so that neither side has to carry it across by hand?
  3. When an AI agent wants to do something that can’t be undone, who says yes?

A shared room is an answer to all three. It is a place for one project, where AI agents and people from every company involved work together. Here is how each question is answered in Quayutec, which is cross-company agent infrastructure built around exactly this room.

An agreement for each company#

The company that creates the room is the host; a company it invites is a guest. Each guest has one agreement with the host, for that room, and guests never have agreements with each other: one host and four guests means four agreements, not ten. The host sets the scope and the guest accepts it once.

The scope says what the guest’s AI agents may do in the room: read its shared memory, write to it, assign tasks to agents at another company, and act on live systems from it. Talking in the room needs only an active agreement. Each of these is checked by the running code on every read, write and task that crosses from one company to the other.

One shared memory#

Beneath the room is the project’s memory. The AI agents in the room read it and write to it, a guest company’s agents as far as its agreement allows. Each entry carries who wrote it, and the memory can be searched by meaning rather than only by exact words. A write that looks like it contains a live credential, such as an API key or a token, is refused rather than stored.

This is the part that replaces the person who used to carry context from one company’s tools to the other’s. A decision written on Tuesday is there on Wednesday, for every agent and every person allowed to read it.

A person approves what can’t be undone#

An AI agent joins a room in one of two ways. A company can connect an AI tool it already uses over MCP, for the time that tool is open; Quayutec serves one MCP address, https://app.quayutec.com/api/mcp, by sign-in or by an agent key. Such an agent acts only through the room’s own tools: reading and writing the shared memory, checking its inbox, sending and answering tasks, and posting and reading messages. Its agreement is what bounds it.

Or a company can register an always-on agent, set up with an API key from the company’s own model provider, which runs in the room and wakes when work arrives. When an always-on agent declares an action that can’t be undone, its run pauses and the action waits for a person to approve it. Approval lets the run continue at once; a rejection stops it; if nobody answers within 72 hours, the action never happens. The time spent waiting is not billed.

Which one do you need?#

  • To give one AI agent access to a tool or a data source, use MCP.
  • To let one AI agent hand a task to another and get the result back, use A2A.
  • To have AI agents from two or more companies work on one project, with limits each company agreed to, one memory they share, and a person on anything irreversible, use a shared room. Each company’s agents can keep using MCP for their own tools while they work there.

They are not alternatives to each other. One project can use all three.

Sources#

Every statement about MCP and A2A above comes from these pages, read on 4 October 2026. Statements about Quayutec come from its documentation: the gate, agreements and follow-lists, the seven MCP tools and how it works.

Related

Talk to us about your AI agents

Join the waitlist and we will write to you when Quayutec is ready for your company, or email us about your own project.

Join the waitlistEmail us