A2A Protocol: Wiring Opaque Agents Together with JSON-RPC and Agent Cards

What A2A Solves That a Shared Framework Does Not

The README frames the problem as agents built on diverse frameworks by different companies, running on separate servers, that need to communicate as agents rather than as tools. That distinction matters. A tool call assumes the caller knows the interface and owns the orchestration loop. A2A assumes the remote side is opaque: it has its own memory, its own tools, its own logic, and it will not expose any of that. What crosses the wire is a task and its results.

The intended audience is therefore teams that already have agents and now need them to cooperate across an organizational or framework boundary. If you have a LangGraph agent and a colleague has one built on Google ADK, A2A is the layer that lets them negotiate instead of one being rewritten. The README lists what an agent can do under the protocol: discover other agents' capabilities, negotiate interaction modalities across text, forms and media, collaborate on long-running tasks, and do all of it without exposing internal state, memory or tools.

Where it is the wrong tool is equally clear from that framing. Two agents in the same process do not need an agent card, a JSON-RPC envelope, or a task lifecycle. They need a function call. A2A adds a network boundary, a discovery step and a serialization format, and you pay for all three in latency and debugging effort.

JSON-RPC 2.0, Agent Cards, and the Three Interaction Modes

The key features section is compact and worth reading literally. Standardized communication is JSON-RPC 2.0 over HTTP(S). Discovery happens through Agent Cards that detail capabilities and connection info. Interaction is flexible: synchronous request/response, streaming over SSE, and asynchronous push notifications. Payloads handle text, files and structured JSON.

So the data flow has two phases. First a client fetches an Agent Card, which is the machine-readable description of what the remote agent offers and how to reach it. Then the client sends JSON-RPC requests against that endpoint. The three modes are not interchangeable decorations: synchronous fits short exchanges, SSE fits a task whose output arrives incrementally, and push notifications fit a task that outlives the connection. Choosing the wrong one for your workload is a design error you will notice in production.

The repository layout backs this up. The spec lives in specification/, the prose documentation in docs/, and architectural decisions in adrs/. There is a mkdocs.yml and a requirements-docs.txt, which means the published documentation site is built from this repository rather than maintained elsewhere. The README points to the specification at a2a-protocol.org/latest/specification/ as the authoritative text.

Installing an A2A SDK and Sending a First Request

A2A is a protocol first, so there is no single binary to install. The README directs you to the documentation site at a2a-protocol.org for the full specification, tutorials and guides, and to the samples repository to see it in action. What you install is an SDK for your language. The README gives the exact install line for each.

For Python, the package is published on PyPI as a2a-sdk:

pip install a2a-sdk

For Go, the module path is used directly:

go get github.com/a2aproject/a2a-go

For JavaScript and TypeScript, the scoped package is @a2a-js/sdk:

npm install @a2a-js/sdk

For .NET, the package is A2A on NuGet:

dotnet add package A2A

For Rust, the crate is a2a-lf:

cargo add a2a-lf

The Java SDK is referenced in the README as using Maven, with no install line given. After installing, the first real use is to point a client at an Agent Card and issue a request. The README does not include a worked request example in the text available here, so the concrete call shape belongs to the specification and the samples repository rather than to this page. Start with a sample that matches your framework, since the README names Google ADK, LangGraph and BeeAI as frameworks whose agents can be exposed as A2A servers.

The DeepLearning.AI Course Is the Practical On-Ramp

The README devotes a section to a short course on A2A built in partnership with Google Cloud and IBM Research and taught by Holt Skinner, Ivan Nardini and Sandi Besen. The stated learning outcomes are specific enough to be useful as a checklist: make agents A2A-compliant by exposing agents built with Google ADK, LangGraph or BeeAI as A2A servers; connect agents by writing A2A clients from scratch or using integrations; orchestrate sequential and hierarchical workflows of A2A-compliant agents; build a healthcare multi-agent system across different frameworks; and understand how A2A complements MCP.

That last item is the one most readers get wrong. MCP and A2A are frequently confused because both are about connecting AI systems. The distinction the README draws is that A2A complements MCP by enabling agents to collaborate with each other, rather than by exposing tools to a single agent. If your problem is one model needing access to a database or a filesystem, that is a tooling problem. If your problem is two autonomous systems needing to hand work back and forth, that is the A2A case.

The course is a reasonable first stop because the README does not attempt to teach the request lifecycle inline. It teaches the concepts and defers the wire format to the specification.

Opacity Is the Design Goal, and It Is Also the Cost

Preserving opacity is listed as a first-class aim: agents collaborate without sharing internal memory, proprietary logic or tool implementations. That protects intellectual property and keeps security boundaries intact. It also means you cannot debug a remote agent by reading its state. When a task fails, you see the task failure, not the reasoning that produced it.

A second limitation follows from the transport. JSON-RPC 2.0 over HTTP(S) is a request-oriented protocol, and the three interaction modes exist precisely because not every task fits a single round trip. Long-running work needs either SSE held open or a push notification channel the client can receive on. Both add operational surface: an open connection to keep alive, or an inbound endpoint the client must expose and secure. The README's enterprise-ready line mentions security, authentication and observability as design considerations, but the text available here does not document a rollback procedure, a version negotiation mechanism, or a migration path between protocol versions. Those are questions to take to the specification before you depend on them.

There is also a boundary problem the protocol cannot solve for you. If two agents disagree about what a task result means, A2A will deliver the payload faithfully and the disagreement will survive intact. Standardized transport is not standardized semantics.

How A2A Differs from MCP and from Framework-Level Orchestration

The README names MCP directly as the complement, and the difference is architectural rather than cosmetic. MCP exposes tools to an agent: the agent is the caller, the tool is the callee, and the tool does not have goals. A2A connects agents: both sides can hold state, pursue a task, and push back. A tool cannot decline a request because it disagrees with the plan. An A2A peer can.

The other alternative is framework-level orchestration, where you pick one framework and build every agent inside it. That gives you tighter coupling, shared types, and no network hop. It also means every participant must be rewritten or wrapped to join. A2A trades that coupling for a JSON-RPC boundary and a discovery step. The trade is worth it exactly when the agents are already separate and will stay separate.

The README also points to a samples repository for seeing A2A in action, and to a DeepLearning.AI course for guided practice, which is a fuller on-ramp than most protocol repositories offer.

Maintenance, Licence and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-04. The most recent release is v1.0.1 from 2026-05-28, following v1.0.0 on 2026-03-12 and v0.3.0 on 2025-07-30. The jump from 0.3.0 to 1.0.0 landed within roughly eight months, which tells you the protocol was still settling its surface through mid-2025. A 1.x line suggests the authors intend compatibility within the major version, but the README does not state a deprecation policy or a support window, so treat that as an assumption to verify rather than a guarantee.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you preserve notices and state significant changes. That is a permissive arrangement, but it is not legal advice, and if you plan to redistribute a modified server or embed the SDK in a product, have counsel read the LICENSE file rather than this paragraph.

Upgrade cost depends on how tightly you bind to an SDK. The protocol is defined in specification/, and the SDKs are separate repositories per language, so a protocol revision may not land in every SDK at the same moment. Pinning your SDK version and tracking the specification's changelog is the cheaper habit than upgrading both at once.

Editorial conclusion

Adopt A2A if you already run agents on separate stacks and need them to discover each other and cooperate without sharing internal memory or tool implementations; the specification repository and the six SDKs are the entry points, and the last push was on 2026-09-04. Do not adopt it if your agents live in one process and one framework, because a direct function call is cheaper than an HTTP round trip with a card handshake. Before committing, verify three things: that your framework of choice has a sample under a2aproject/a2a-samples, that your transport can carry the streaming or push-notification mode you need, and that the Apache-2.0 terms fit how you intend to redistribute your server. The specification is the contract, not the SDK, so pin the version you build against.

Frequently asked questions

Official sources

1. a2aproject/A2A on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases