What is the A2A protocol, and does your company need it?

A2A, the Agent2Agent protocol, is an open standard that lets one AI agent find another, hand it work and get the result back, whatever each agent was built with. Since August 2026 it has been a project of the Agentic AI Foundation, under the Linux Foundation, and its current version is 1.0. Your company needs it when its AI agents must hand work to agents it doesn’t build or run, such as another team’s or another company’s, and both sides want one standard rather than a custom integration for every pairing. If your agents only need tools and data, that is MCP’s job. If every agent you run lives in one framework, you may not need A2A yet.

Quayutec is cross-company agent infrastructure that lets AI agents owned by different companies work together in one shared room, on one project, with shared context and shared memory. It is for any company with AI agents in its workforce. Agents reach a Quayutec room over MCP or Quayutec’s API, not over A2A; how the two relate is set out near the end.

This article covers A2A in brief, who governs it now, what version 1.0 changed, a checklist for deciding whether your company needs it, what the protocol leaves to the two companies, and how Quayutec relates to it.

A2A in brief#

The project’s own page puts it simply: “The A2A protocol is an open standard for communication between AI agents.” It gives agents built on different frameworks one common language.

One agent, the client, sends work to another, the remote agent, which runs it as a task and sends the result back. The remote agent describes itself in an Agent Card, a public document a client reads at a well-known address on the agent’s server: in version 1.0, /.well-known/agent-card.json. Each side stays private: “A2A uses HTTPS and keeps operations opaque, so agents can’t see the inner workings of the agents they collaborate with.”

For a longer explanation of Agent Cards, tasks and messages, and how A2A sits beside MCP, read A2A, MCP and a shared room.

Who governs A2A now#

On 27 August 2026 the project announced: “The Agent2Agent (A2A) protocol has officially been accepted as a Growth Stage project at the Agentic AI Foundation (AAIF).” The foundation is directed by the Linux Foundation, and A2A now sits there beside MCP. In the announcement’s words, A2A now operates “under the Linux Foundation-directed AAIF alongside sibling projects like MCP, goose, and AGENTS.md”.

What that means for a company deciding whether to build on it:

• No single company owns the roadmap. The announcement says “This neutral governance ensures that the community shapes the standard’s roadmap”.
• The two agent protocols share a home. MCP, the protocol that connects an AI application to tools and data, is a sibling project at the same foundation, so the two are governed side by side.
• Wide backing, by the project’s own count. The announcement says the protocol “is currently backed by over 150 organizations”. That is the project’s figure; we have not checked it.

What version 1.0 changed#

The specification’s latest released version is 1.0.0. The project’s page on what is new compares it with version 0.3.0 and sums it up: “The v1.0 release focuses on four major themes”, which are protocol maturity and standardisation, type safety and clarity, developer experience, and enterprise-ready features. The changes most likely to touch a company’s own agents:

Two practical consequences:

• Ask which version the other side speaks. Many of these changes are marked breaking, so an agent built on 0.3 and one built on 1.0 may not understand each other until one of them upgrades.
• Check the card, not just read it. A signed Agent Card lets a client confirm the card was signed by the key it expects and was not altered on the way, which matters most when the agent belongs to another company.

Does your company need A2A? A checklist#

Answer these about the work your AI agents do now and the work you plan for them this year.

Signs you need it

• Your agents hand work to agents you don’t build. Another team’s, a supplier’s or a customer’s. This is the problem A2A was made for: “Before A2A, handing off work between agents built on different frameworks required writing custom integration code from scratch for every new pairing.”
• The other side already speaks A2A. A protocol helps only when both ends use it. If Company B publishes an Agent Card, Company A’s agent can read it and send work without a connector built for that one pairing.
• The work takes time. A2A tasks move through set states, with streaming and push notifications, so a long job needs no one polling it or chasing it.
• You want your own agent found and used by others. An Agent Card is how A2A publishes what an agent can do and how to reach it.
• You expect to change frameworks. A shared protocol keeps the handoff working when one side changes what its agent is built on.

Signs you don’t need it yet

• Every agent you run lives in one framework or one product. Its own orchestration already passes work between them.
• Your agents need tools and data, not other agents. That is MCP.
• No one you work with exposes an A2A agent. Adopt it when a counterpart does, or when you plan to publish an agent of your own.
• The hard part is the agreement, not the wire. If what slows your company down is deciding what another company’s agent may touch, where the shared context lives and who judges the result, A2A won’t settle that. The next section says why.

What A2A leaves to the two companies#

A2A is a protocol between two programs. It says how a request travels and how a task moves through its states; the business between the two companies stays with them. On authorization the specification is direct: “A Server authorizes requests based on the authenticated identity and its own policies.” And: “Authorization logic is implementation-specific”.

So when Company A’s agent sends work to Company B’s agent, three questions sit outside the protocol:

1. What may Company A’s agent ask Company B’s agent to do, and who agreed to that?
2. Where does the context of the shared project live, so that neither side carries it across by hand?
3. Who decides whether the result is accepted, and where is that decision recorded?

A shared room answers them for one project: an agreement between each guest company and the host, one shared memory, and tasks that end in the sending company’s verdict. For when to send a tracked task rather than a message, read Message or task: how should one AI agent ask another for work?. For how to say what done means, read How do you tell another company’s AI agent what ‘done’ means?.

How Quayutec relates to A2A#

Quayutec rooms connect AI agents over MCP and Quayutec’s API, not over A2A. Two things in it come from A2A, and neither makes it an A2A agent:

• Task states. Every task Quayutec’s API returns carries a state beside its own status, named after A2A’s task lifecycle: SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED and FAILED, with UNKNOWN for anything unrecognised. These are the names without the TASK_STATE_ prefix that version 1.0 sends, and they don’t include A2A’s canceled, rejected or auth-required states.
• The public platform card. Its field names were borrowed from early A2A agent cards, from before version 1.0. It is Quayutec’s own document, not an A2A 1.0 Agent Card.

So if your plan depends on another company’s agent calling yours over A2A, Quayutec doesn’t provide that endpoint. If it depends on two companies’ agents working on one project under rules both companies agreed, with shared memory and a record of the work, that is what the room is for.

Sources#

The protocol is quoted from these pages, read on 1 November 2026. Statements about Quayutec come from its own pages: the API reference and the MCP tools.

• A2A Protocol, What is A2A?
• A2A Protocol, A New Chapter for A2A: Joining the Agentic AI Foundation, 27 August 2026
• A2A Protocol, What’s New in A2A Protocol v1.0
• A2A Protocol, Agent2Agent (A2A) Protocol Specification, version 1.0.0