A2A: a JSON-RPC contract for agents that cannot see inside each other
Agent2Agent (A2A) is an open protocol enabling communication and interoperability between opaque agentic applications.
At a glance
- What is it?
- The Agent2Agent protocol defines how independently built agents discover one another and collaborate without sharing memory or tools. It is a specification plus a set of language SDKs, not a runtime, and that distinction decides whether you should adopt it.
- Who is it for?
- Adopt A2A if you need two agents owned by different teams, or running on different servers, to exchange tasks while keeping their internal state private. Do not adopt it if you are wiring a single agent to a set of tools: that is MCP's job, and the README treats the two as complementary rather than competing.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem A2A solves is opacity, not connectivity
Connecting two agents over HTTP is not hard. Connecting two agents that were built by different companies, on different frameworks, running on separate servers, and that must not expose their internal memory, proprietary logic or tool implementations, is the harder case. The README frames A2A around exactly that: enabling agents to communicate "as agents, not just as tools." The distinction matters. A tool call assumes the caller knows the callee's interface and can describe it in a schema. An agent-to-agent call assumes the caller knows only what the callee advertises as a capability. A2A's target user is therefore an organisation that already has agents in production and now needs them to hand work to agents it does not own or operate. If your agents all live in one process and share a Python object graph, the protocol adds a network hop and a serialisation format for no benefit.
Agent Cards, JSON-RPC 2.0, and three interaction modes
The mechanism the README describes has four parts. Communication is JSON-RPC 2.0 over HTTP(S), so the wire format is a request object with a method and params, not a bespoke RPC. Discovery happens through Agent Cards, which the README describes as detailing "capabilities and connection info," meaning a client fetches a card before it can address the agent at all. Interaction comes in three modes: synchronous request/response, streaming over Server-Sent Events, and asynchronous push notifications. Data exchange covers text, files and structured JSON. The opacity guarantee is a design constraint rather than a feature you enable: the protocol is built so that collaboration does not require sharing internal memory, proprietary logic or tool implementations. What the README does not give is the card's field-level schema or the concrete JSON-RPC method names. Those live in the specification at a2a-protocol.org, and anyone evaluating A2A for a real integration should read that page rather than the repository front page, because the front page is a summary.
Installing an SDK, and why the repository is mostly Shell
The A2A repository itself is a specification and documentation project, which is why the primary language shows as Shell. The runnable code lives in sibling repositories, one per language. The README gives these install commands: pip install a2a-sdk for Python, go get github.com/a2aproject/a2a-go for Go, npm install @a2a-js/sdk for JavaScript, dotnet add package A2A for .NET, and cargo add a2a-lf for Rust. Java is listed with a Maven dependency but no command string in the README. Note the naming inconsistency: the Rust crate is a2a-lf, not a2a-rs, even though the repository is a2a-rs. Working samples are kept separately in the a2aproject/a2a-samples repository, and the README points to a DeepLearning.AI course covering how to expose agents built with Google ADK, LangGraph or BeeAI as A2A servers. That course is the closest thing to an onboarding path the material offers; there is no quickstart command in the README itself.
Where the protocol stops and your code starts
A2A standardises the handshake, not the work. It tells you how a client finds a card, how a task is submitted, and how results come back. It does not tell you what a task means, how to decompose one, or what to do when a remote agent returns a partially completed result. Those are application concerns, and the README is silent on them. There is a second gap worth naming: the README calls the protocol "Enterprise-Ready" and says it is "designed with security, authentication, and observability in mind," but it does not state which authentication schemes are supported or how observability data is emitted. For a protocol whose selling point is cross-organisation collaboration, that is the part a reviewer most wants specified, and the front page does not answer it. Treat the specification as the source of truth and budget time for it.
MCP is the comparison the project itself draws
The README and the course outline both position A2A against MCP, and the relationship is stated plainly: A2A "complements MCP by enabling agents to collaborate with each other." The difference in approach is about who is on the other end. MCP connects an agent to tools and data sources, where the caller is expected to understand the callee's interface and invoke it directly. A2A connects an agent to another agent, where the caller deliberately does not see the internals and negotiates the interaction. The a2a-mcp topic on the repository suggests the two are used together rather than chosen between. If your integration is one agent calling a database or a search API, MCP is the shorter path and A2A adds an agent-shaped abstraction you do not need. A2A earns its place when the thing on the other side has its own reasoning loop and its own owner.
Version cadence and what upgrading costs
The release history shows v0.3.0 in July 2025, v1.0.0 in March 2026, and v1.0.1 in May 2026. The jump from 0.3 to 1.0 in roughly eight months, followed by a patch two months later, suggests the wire contract stabilised recently and that anyone who integrated against the 0.x line should expect to revisit their client code. The last push to the repository is dated 2026-09-04, so the project is active. Because the specification and the SDKs are separate repositories with their own release tags, a protocol version and an SDK version can drift; pinning the SDK and checking its release notes against the specification version you target is the practical mitigation. On licensing: the repository is Apache-2.0, which permits commercial use and modification with the usual notice and patent-grant terms. That licence covers this repository. The SDKs are separate projects, and their terms should be confirmed independently rather than assumed. None of this is legal advice; read the LICENSE file and the individual SDK licences before shipping.
Who should adopt A2A, and what to verify first
The fit is narrow and identifiable. You should look at A2A if you are building a system where at least two agents have different owners, or run on different servers, or are built on different frameworks such as Google ADK, LangGraph or BeeAI, and you need them to exchange tasks without exposing internal state. You should not adopt it if you are connecting one agent to a set of tools (use MCP), or if all your agents share a process and a memory space, or if you need the protocol to define task semantics for you, because it does not. Before writing integration code, verify three things against the specification rather than the README: the exact Agent Card schema, the JSON-RPC method names for task submission and streaming, and which authentication schemes your chosen SDK implements. The README's claim that A2A handles text, files and structured JSON is broad enough that the per-SDK support matrix is what will actually determine your effort.
Editorial conclusion
Adopt A2A if you need two agents owned by different teams, or running on different servers, to exchange tasks while keeping their internal state private. Do not adopt it if you are wiring a single agent to a set of tools: that is MCP's job, and the README treats the two as complementary rather than competing. Before committing, read the specification page at a2a-protocol.org/latest/specification and confirm which transport modes (synchronous, SSE streaming, push notifications) your target SDK version actually implements, because the protocol lists all three while individual SDKs may lag. The Apache-2.0 licence covers the specification repository and its code; it does not grant rights over the separate SDK repositories, which you should check individually.
Community notes