Protocol explainer
What is the A2A protocol? Agent2Agent explained
A plain explanation of the Agent2Agent protocol from its own site, with its objects, security model, limits and relation to MCP, checked on 2026-10-07.
The Agent2Agent (A2A) protocol is an open standard for communication between independent AI agents, including agents built by different vendors on different frameworks. Google originally developed it and donated it to the Linux Foundation, and on 27 August 2026 it was accepted into the Agentic AI Foundation. It sits beside MCP: MCP connects an agent to its tools, and A2A connects agents to each other. Swfte does not claim A2A support, and this page says why.
Last verified 2026-10-07. Sources are listed at the end of the page.
What is the A2A protocol?
The specification describes A2A as an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems. Its goals are that agents can discover each other's capabilities, negotiate how they exchange content, manage collaborative tasks and share information without exposing their internal state, memory or tools.
The project says A2A was originally developed by Google and donated to the Linux Foundation. A Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow maintains it. The project's own announcement, dated 27 August 2026, says A2A was accepted as a Growth Stage project at the Agentic AI Foundation, which also hosts MCP. The licence is Apache 2.0.
The specification page shows 1.0.0 as the latest released version, with 0.3.0, 0.2.6 and 0.1.0 listed as previous versions. The text of the page that this review read shows no release date for 1.0.0, so this page does not state one. Version 1.0 made breaking changes against earlier versions.
What are the core objects in A2A?
| Object | What the specification says |
|---|---|
| Agent Card | A JSON metadata document published by an A2A server. It describes the agent's identity, capabilities, skills, service endpoint and authentication requirements. The specification gives /.well-known/agent-card.json as the well-known location. |
| Task | The fundamental unit of work, with a unique ID and a defined lifecycle. Completed, failed, canceled and rejected are terminal states. |
| Message | One communication turn between a client and a remote agent. It has a role of user or agent and contains one or more parts. |
| Part | The smallest unit of content in a message or an artifact: text, a file reference or structured data. |
| Artifact | An output of a task, such as a document, an image or structured data, made of parts. |
| Context | An optional identifier that groups related tasks and messages. |
| Streaming and push notifications | Real-time incremental task updates, and server-initiated HTTP POST requests to a webhook the client provides, for long-running or disconnected cases. |
| Extension | A way for agents to offer functionality beyond the core specification. |
The core operations are sending a message (with or without streaming), getting, listing, cancelling and subscribing to tasks, managing push notification settings, and fetching an authenticated extended Agent Card.
How do transports and security work in A2A?
| Topic | What the specification says |
|---|---|
| Protocol bindings | Three: JSON-RPC 2.0, gRPC and HTTP+JSON or REST. The operations are the same across them. |
| Discovery | An agent publishes its Agent Card at a well-known address. A client can fetch a fuller extended card after it authenticates. |
| Transport security | Production deployments must use encrypted communication: HTTPS for HTTP-based bindings and TLS for gRPC. The specification recommends modern TLS configurations. |
| Authentication | Agents declare their security schemes in the Agent Card. The specification lists API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS. |
| Authorisation | Servers must check authorisation on every operation and limit results to what the caller may see. The authorisation model is defined by each agent and is not prescribed by the protocol. |
| Push notifications | Agents should validate webhook URLs to prevent server-side request forgery. Clients must validate that a notification is authentic. |
How does A2A relate to MCP?
The A2A project has a page on this. It says "A2A connects the agents to each other; MCP connects each agent to its own tools." Its guidance is to use both together: A2A for collaboration between agents, and MCP for tool integration inside each agent. Appendix B of the specification says the same: an A2A server agent may itself use MCP to reach the tools and data it needs to finish a task.
The A2A home page lists what A2A is not. It is not an agent development kit such as LangGraph or CrewAI. It is not a protocol for an agent's own sub-agents or tool calls. It is not a replacement for MCP. And it is not an interactive messaging app. For the tool side, see What is MCP.
When do you need A2A?
| Situation | Do you need A2A? | Why |
|---|---|---|
| Agents from different vendors must hand work to each other | Likely | A shared task and message model avoids a custom integration for each pair of agents. |
| Agents from different teams use different frameworks | Possibly | A2A is the communication layer between agents built with any framework. A shared internal convention may be enough for two teams. |
| All your agents run in one framework | Probably not | The project says A2A does not specify how an agent talks to its own sub-agents. Use the framework's own primitives. |
| One agent needs tools or data | No, use MCP | The project positions MCP for agent-to-tool connections. |
| A single agent that answers users and does not delegate | No | There is no second agent to talk to. |
What are the honest limits of A2A?
- It defines how agents talk, not whether they should. Each agent defines its own authorisation model, so you still decide which agent may ask which agent for what.
- The remote agent is opaque by design. You exchange messages, tasks and artifacts, not its internals, so you cannot see how it reached a result unless it tells you.
- Versions matter. Version 1.0 made breaking changes, such as removing the kind discriminator on parts and events, so check which version a counterpart implements.
- Push notifications open a webhook, and the specification itself warns about server-side request forgery on those URLs.
- This page gives no adoption numbers. The sources read for it do not state a figure that could be verified, so none is quoted.
Where Swfte fits, and when you do not need it
Swfte does not claim A2A support. A search of the Swfte repositories on 2026-10-07 found an earlier in-house agent-to-agent interface in the agents service, named A2A in its code. Its method names and Agent Card location differ from specification 1.0.0, it does not implement task streaming, and we found no test of it against the specification. We do not describe it as A2A support.
A governed approach to cross-agent calls needs three things. Identity: each agent is a non-human identity with its own credentials. Policy: a rule for which agent may ask which agent for what, with a human approval step for risky actions. Audit: a record of every delegated task and who or what approved it. Swfte's pages describe these as designed for, and the agent-to-agent calls in the OWASP LLM top 10 page are meant to pass through the same identity and policy layer as tool calls. See AI agent governance.
You do not need Swfte to use A2A. The A2A project publishes the specification and SDKs, and any compatible agents can talk to each other without a platform in between. If you adopt it, put your own policy and logging layer in front of the endpoints.
Sources and last verified
Every dated or technical fact on this page was read from the pages below on 2026-10-07. Anything that could not be confirmed is left out or marked as not verified.
- A2A specification. Version 1.0.0, core objects, operations, bindings, security considerations and Appendix B on MCP.
- A2A Protocol home. What A2A is not, governance and licence statements.
- A2A and MCP. The project's own comparison with MCP.
- A2A joins the Agentic AI Foundation. Acceptance as a Growth Stage project, dated 27 August 2026.
- a2aproject/A2A (README). Linux Foundation project, contributed by Google, Apache 2.0 licence.
Frequently asked questions
What does A2A stand for?
A2A stands for Agent2Agent. It is an open protocol for communication and interoperability between independent AI agent systems. Agents publish an Agent Card that describes what they can do, and other agents send them messages and tasks over JSON-RPC, gRPC or HTTP and REST, without needing to see each other's internal state.
Who created and governs A2A?
Google originally developed A2A and donated it to the Linux Foundation. A Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow maintains it. The project announced on 27 August 2026 that A2A was accepted as a Growth Stage project at the Agentic AI Foundation.
What is an Agent Card?
An Agent Card is a JSON document that an A2A server publishes to describe itself. It states the agent's identity, capabilities, skills, service endpoint and the authentication it requires. The specification gives a well-known address for it, and an authenticated client can fetch a fuller extended card that may include more detail.
How is A2A different from MCP?
MCP connects an agent to its tools and data, and A2A connects agents to each other. The A2A project puts it this way: A2A connects the agents to each other, and MCP connects each agent to its own tools. The two are meant to be used together, and A2A does not replace MCP.
Is A2A secure?
It gives you the pieces but not the policy. The specification requires encrypted transport in production, lets agents declare schemes such as OAuth 2.0 and mutual TLS, and requires authorisation checks on every operation. It leaves the authorisation model to each agent, so you decide who may ask what, and you should log it.
Does Swfte support A2A?
Swfte does not claim A2A support. An earlier in-house agent-to-agent interface exists in the agents service, but its method names and card location differ from specification 1.0.0 and we found no test of it against the specification. Swfte describes identity, policy and audit for cross-agent calls as designed for, not as a shipped A2A feature.