A2A Protocol: How AI Agents Talk to Each Other

A2A — Agent2Agent — is an open protocol for one AI agent to find another, ask it to do something, and get a result back, even when the two were built by different vendors on different frameworks. Google introduced it in April 2025 and handed the specification and SDKs to the Linux Foundation two months later. Version 1.0 is the current stable release.

The three things worth knowing before you read further:

• An Agent Card is the whole discovery mechanism. A JSON document at a known URL that says what an agent can do and how to reach it.
• A2A is not MCP. MCP connects an agent to tools and data. A2A connects an agent to another agent. They're complementary, and most real systems use both.
• You probably don't need it yet. A2A solves cross-organization, cross-vendor agent delegation. If your agents all live in one codebase, a function call is faster and simpler.

The reason it matters anyway is that the interop question arrives whether you plan for it or not — the moment two vendors you already pay for both ship agents.

The Problem A2A Solves

An agent that can call tools is well covered. MCP standardized that in 2024 and it's now broadly adopted. What was missing is the layer above: agent A needs work done that agent B is better at, and agent B is behind someone else's API, running someone else's model, holding data agent A will never see.

You could solve this with a REST integration per pair. That's the state most teams are in, and it scales the way point-to-point integrations always scale — badly, at N².

A2A's bet is that agents should be able to advertise capability in a machine-readable way and be invoked without a custom integration. Same bet HTTP made about documents.

Critically, A2A treats the remote agent as opaque. You don't get its prompts, its memory, or its model. You get a capability description and a task interface. That opacity is the feature: it's what makes cross-company delegation possible without exposing internals.

The Agent Card

Everything starts here. An Agent Card is a JSON document, served at a well-known path on the agent's host, describing:

• Identity — name, description, provider, version
• Endpoint — where to send requests
• Skills — what the agent can do, each with a description and example inputs
• Authentication — what credentials the caller needs
• Capabilities — whether it supports streaming, push notifications, and which content types it handles

A client fetches the card, decides whether this agent is a fit for the task at hand, and calls it. There is no registry requirement in the base protocol — discovery can be as simple as a URL you were given, or as structured as an enterprise catalogue of cards.

The design mirrors how robots.txt and OpenAPI descriptions work: a predictable location, a predictable shape, and no coordination needed beyond publishing the file.

How the Spec Is Layered

The A2A specification separates three concerns, which is worth understanding because it explains why A2A can run over several transports:

The practical consequence: a gRPC-based agent and a JSON-RPC agent implement the same operations and can interoperate, because the semantics live in layer 2 and only the wire format changes in layer 3.

Tasks are the unit of work, and they're stateful. A2A assumes agent work is long-running — a task gets an ID, moves through states, can be polled or streamed, and produces artifacts. This is a meaningfully different assumption from a request/response API, and it's the right one for anything an agent actually does.

A2A vs MCP: The Distinction That Keeps Getting Muddled

They are not competitors, and the confusion costs people a lot of time.

A useful way to hold it: MCP gives your agent hands. A2A gives it colleagues.

Most production architectures end up with both — an agent that uses MCP servers for its own tools, and exposes an Agent Card so other agents can delegate to it. If you're mapping out how those pieces fit, our breakdown of agentic AI architecture covers the components underneath.

Where It Stands in 2026

The Linux Foundation reported that A2A passed 150 supporting organizations in its first year, with AWS, Google, Microsoft, Salesforce, and SAP among them, and the protocol landing in major cloud platforms.

Read that carefully, though. Broad vendor endorsement is not the same as broad deployment. What it tells you is that the interop layer is unlikely to fragment into three competing standards — which is the useful signal for anyone deciding whether to build against it.

When You Actually Need A2A

Skip it if:

• Your agents run in the same process or repo. Call the function.
• You have one vendor's agent and no plans for a second.
• You're still deciding whether one agent works. Protocol design is a distraction from that.

Consider it if:

• You're building an agent for other people's agents to call. Publishing an Agent Card is the low-cost way to be callable.
• You need to delegate across an organizational boundary — a partner, a supplier, a different business unit with its own stack.
• You're procuring agentic products and want to avoid a per-pair integration bill later. Asking whether a vendor supports A2A is a reasonable procurement question in 2026.

The honest position for most teams: understand the model, ask the procurement question, and don't build anything until you have two agents that genuinely need to talk.

The Governance Question Nobody Solved Yet

A2A defines how agents communicate. It does not define what one agent may permit another to do on its behalf, how liability attaches when a delegated task causes harm, or how to express constraints like "you may query this data but not retain it."

Those gaps are the live research area, and they're the same gaps that make agentic AI in cybersecurity hard. An agent that can discover and delegate to external agents has extended your trust boundary to include systems you never evaluated. The protocol gives you authentication; it does not give you authorization semantics rich enough for the real question.

Practical guardrails while the standards catch up: whitelist the agents you'll call rather than discovering freely, scope credentials per remote agent, log every delegated task with its full result, and keep a human gate on anything that changes state outside your systems.

Key Points

• A2A is an open protocol, now Linux Foundation governed, for agents built by different parties to discover and delegate to each other
• The Agent Card is the discovery primitive — a JSON capability description at a known URL
• Tasks are stateful and long-running, not request/response, which matches how agent work actually behaves
• MCP and A2A solve different problems — tools versus peers — and most systems need both
• Adoption is broad among vendors, thin among deployments. Learn it, ask about it in procurement, build against it only when you have two agents that must interoperate
• Authorization semantics are the unsolved part. Whitelist, scope credentials per remote agent, and gate state changes

If the harder problem for you is running any of this at all — the setups you keep seeing that never make it past a GitHub README — Taku mirrors a working AI setup into a desktop workspace and runs it, so you can use a power user's configuration without reproducing their environment first. It's in Beta, and the Mac app is available now.

FAQ

What does A2A stand for?

Agent2Agent. It's an open protocol for communication between AI agents built by different vendors or on different frameworks, originally released by Google and now governed by the Linux Foundation.

What is an A2A Agent Card?

A JSON metadata document that describes an agent: its identity, endpoint, skills, authentication requirements, and supported capabilities. A client fetches it to decide whether that agent can handle a task and how to call it. It's the discovery mechanism for the whole protocol.

Is A2A the same as MCP?

No. MCP connects an agent to tools and data sources it uses. A2A connects an agent to another agent it delegates to. They operate at different layers and are frequently used together in the same system.

Do I need A2A for a multi-agent system?

Not if the agents are yours and share a runtime — direct calls are simpler and faster. A2A earns its complexity when agents cross a vendor, network, or organizational boundary. Our guide to AI agent orchestration covers the in-house coordination patterns.

What transports does A2A support?

JSON-RPC 2.0 over HTTPS, gRPC, and HTTP/JSON REST. The operations are defined independently of transport, so agents on different bindings can still interoperate.

Is A2A production-ready?

Version 1.0 is stable and the Linux Foundation reports enterprise production use. Whether it's ready for your use depends less on the protocol and more on whether your authorization and audit story is ready for cross-boundary delegation — that part is not solved by the spec.