A2A (Agent2Agent protocol)

Overview

The Agent2Agent protocol, written A2A, is an open standard that lets AI agents talk to other AI agents. One agent can find another, learn what it can do, hand it a task, follow its progress and receive the result, even when the two agents were built by different companies, on different frameworks and with different models.

Think of a general contractor renovating a house. The contractor does not lay tiles or wire the electrics personally. They find a tiler and an electrician, check what each one offers, agree on the job, follow progress and accept the finished work. The contractor does not need to know which tools the electrician owns or how they learned the trade. They only need a shared way to describe jobs, ask questions and hand over results. A2A is that shared way of working for software agents.

This page covers what A2A is, its history, how discovery and tasks work, a worked example, its strengths and weaknesses, how it differs from MCP, and how to deploy it safely.

What it is

A2A defines how a client agent sends work to a remote agent and how the two exchange messages and results. Each remote agent publishes an Agent Card, a JSON document that says who it is, what skills it offers, which endpoints and protocol bindings it supports and how callers must authenticate.

The core objects are few.

A2A deliberately treats the remote agent as opaque. The caller does not see its prompts, tools, memory or reasoning. It sees only the card, the messages and the artifacts. This protects each vendor's internals and keeps the contract between agents small and stable.

Where it came from

Google announced A2A in April 2025 with a group of technology and consulting partners. The motivation was practical. Companies were deploying agents from many vendors: a CRM agent, an IT service agent, an HR agent, custom internal agents. These agents could not coordinate, so people copied information between them by hand.

In June 2025 Google donated A2A to the Linux Foundation. IBM's Agent Communication Protocol, a similar effort, merged into A2A in August 2025, which reduced fragmentation. The specification reached version 1.0 in March 2026. In August 2026 the project moved into the Agentic AI Foundation, which also stewards MCP, so the two main agent protocols now share a neutral home.

How it works

Discovery through the Agent Card

A remote agent serves its card at a well-known address, /.well-known/agent-card.json on its domain. Version 0.3 used the name agent.json, so older material may show that path. Clients can also get cards from a registry or from static configuration.

The card lists the agent's skills in plain language, with examples, and an ordered list of supported interfaces. Each interface names a protocol binding, an endpoint URL and a protocol version. The client walks the list and uses the first interface it supports. The card also declares capabilities such as streaming and push notifications, and the authentication schemes the agent accepts.

Protocol bindings

Version 1.0 defines three equivalent bindings: JSON-RPC over HTTP, gRPC, and HTTP with JSON in a REST style. The specification requires them to behave the same, so a client can pick the one that fits its stack. Clients send an A2A-Version header; a server that does not support the requested version returns a version error.

Sending a message and creating a task

The client sends a message to the remote agent. The agent can answer directly with a message, for quick exchanges, or create a task for real work. By default the call waits for a result. A client can ask for an immediate return instead and then follow the task in the background.

Task states

A task moves through a small set of states.

The interrupted states are what make A2A conversational. A travel agent might reply "input required: which dates?" and wait. The client answers within the same task, and work resumes.

Following progress

There are three ways to follow a task. The client can poll by asking for the task by id. It can stream updates over server-sent events, if the agent declares streaming. Or it can register a webhook and receive push notifications, if the agent supports them. Push notifications carry a token from the client's configuration, and the specification recommends timeouts, retries with backoff and refusal to call private network ranges, which protects against server-side request forgery.

Security

A2A builds on ordinary web security: HTTPS, OAuth 2.0 and OpenID Connect, API keys or mutual TLS, as declared in the card. Identity and authorization happen at the HTTP layer, not inside messages. An agent can expose a richer, authenticated extended card to callers who have signed in, while the public card stays minimal.

Key concepts and terms

A worked example

A company runs three agents: a procurement agent built in-house, a supplier-risk agent bought from a vendor, and a finance approval agent from another vendor.

A buyer asks the procurement agent: "Order 500 industrial sensors from the cheapest approved supplier, if the risk is acceptable."

1. The procurement agent reads the supplier-risk agent's card from its well-known URL. The card lists a skill called "assess supplier risk", the JSON-RPC binding and OAuth client credentials as the required scheme.
2. It obtains a token and sends a message with three candidate suppliers as structured data. The risk agent creates a task and reports working.
3. The procurement agent subscribes to the stream. A few minutes later the task completes with an artifact: a risk score and a short rationale per supplier. One supplier is flagged for late deliveries.
4. The procurement agent picks the cheapest acceptable supplier and sends the purchase to the finance agent, again through A2A.
5. The finance agent replies input required: the order exceeds the buyer's limit, and it needs a cost centre and a manager approval. The procurement agent asks the buyer, who supplies the cost centre. The manager approves through the finance agent's own interface, which uses the auth required state.
6. The finance task completes with an artifact containing the purchase order number.

No agent saw another agent's prompts or tools. Each vendor kept its internals private, and the buyer received one coherent answer.

Strengths and limitations

Strengths

• Cross-vendor interoperability. Agents built on different stacks can cooperate without custom glue code.
• Opacity by design. Vendors expose capabilities without revealing prompts, models or data.
• Long-running and interactive work. Tasks, interrupted states, streaming and push notifications fit real business processes.
• Familiar web foundations. HTTP, JSON, gRPC, OAuth and TLS are well understood by security teams.
• Neutral governance. Foundation stewardship and a 1.0 release make it a safer long-term bet.

Limitations

• Coordination cost. Every delegation adds latency, tokens and failure points. Many problems do not need several agents.
• Trust between agents. A2A authenticates callers but cannot tell whether a remote agent's answer is correct or honest.
• Error propagation. A wrong artifact from one agent can quietly mislead the next.
• Version transitions. Implementations that still use the 0.3 card path or message shapes need migration.
• Observability across boundaries. Tracing a request through several vendors' agents requires shared trace identifiers and logging agreements.

How it compares with alternatives

A simple rule: use MCP when the thing on the other side is a tool that does exactly what it is asked. Use A2A when the thing on the other side is an agent that decides how to do the work. Many systems combine both: the procurement agent above reaches its own database through MCP and reaches the other vendors' agents through A2A.

Role in tabular foundation models

Much enterprise work between agents is about tables: supplier lists, transactions, inventory, claims. A2A's structured data parts and artifacts carry such data cleanly. A specialised agent built around a tabular foundation model can sit behind an A2A endpoint and offer skills such as forecasting a column, scoring rows for risk, filling missing values or matching records between two systems. Client agents delegate the analysis and receive artifacts with predictions and uncertainty, without needing to know how the model works.

Because results cross organisational lines, artifacts should carry provenance: which data snapshot was used, how the model was evaluated and how confident the result is. The held-out reports described in this site's documentation are an example of the kind of evidence an analysis agent can attach to its answers.

Practical guidance and best practices

1. Start with one delegation. Prove value with a single client and remote agent before building a network.
2. Write skills for machines and people. Describe each skill clearly, with input and output examples, so client agents choose correctly.
3. Keep the public card minimal. Publish identity and interfaces publicly; put detailed skills behind the authenticated extended card if they are sensitive.
4. Use structured data parts. Exchange typed JSON rather than prose when the receiver will compute on the content.
5. Handle interrupted states. Build clients that can answer input required and auth required, not only wait for completion.
6. Set timeouts and budgets. Limit how long and how often a task can run, and cancel stuck tasks.
7. Validate artifacts. Check schema and plausibility before passing results on. Treat remote output as untrusted input.
8. Propagate trace ids. Pass a correlation id through every hop so incidents can be traced end to end.
9. Secure webhooks. Verify tokens and task ids on push notifications, handle duplicates and never let agents call internal addresses.
10. Pin protocol versions. Send the version header, test against the versions you claim and plan migrations from 0.3.

Common mistakes

• Using A2A where a tool call would do. Wrapping a simple function as an agent adds latency and cost.
• Serving the card at the old path only. Clients following v1.0 look for agent-card.json.
• Ignoring interrupted states. Clients that only expect completion hang when the remote agent asks a question.
• Passing prose between agents. Free text loses structure and invites misreading.
• Trusting remote answers blindly. A confident artifact can still be wrong.
• No cancellation. Forgotten tasks keep consuming resources.

Frequently asked questions

What is A2A in one sentence?

A2A is an open protocol that lets AI agents from different vendors discover each other through agent cards, delegate tasks, exchange messages and receive results.

Who created A2A and who governs it?

Google announced it in April 2025 and donated it to the Linux Foundation in June 2025. Version 1.0 was released in March 2026, and in August 2026 it moved into the Agentic AI Foundation, which also stewards MCP.

What is an Agent Card?

It is a JSON document, served at /.well-known/agent-card.json, that describes an agent's identity, skills, supported interfaces and protocol versions, capabilities such as streaming, and required authentication.

What is the difference between A2A and MCP?

MCP connects an agent to tools and data that do exactly what they are asked. A2A connects an agent to other agents that decide how to do the work themselves. They are complementary, and many systems use both.

Which transports does A2A support?

Version 1.0 defines JSON-RPC over HTTP, gRPC, and HTTP with JSON. The three are required to be functionally equivalent. Streaming uses server-sent events, and push notifications use webhooks.

Can an A2A task ask the caller a question?

Yes. A task can enter the input required state to ask for more information or auth required to ask for a credential. The client answers within the same task and work continues.

Does A2A expose the remote agent's prompts or tools?

No. Remote agents are opaque. Callers see only the card, the messages and the artifacts, which protects each vendor's internal design.

How should I secure an A2A deployment?

Use HTTPS, OAuth or mutual TLS as declared on the card, scope credentials narrowly, verify webhook tokens, block calls to private network ranges, validate artifacts and log every task with a trace id.

When should I not use A2A?

When one team owns all the logic, when a deterministic API call is enough, or when latency and cost must be minimal. A single agent with good tools is often simpler and more reliable.

Glossary

• Agentic AI Foundation: the Linux Foundation project that stewards A2A and MCP.
• Artifact: an output produced by an A2A task.
• Correlation id: an identifier passed across services to link logs and traces.
• gRPC: a high-performance remote procedure call framework.
• JSON-RPC: a lightweight remote procedure call format based on JSON.
• Mutual TLS: TLS in which both sides present certificates.
• OAuth 2.0: an open standard for delegated authorization.
• OpenID Connect: an identity layer on top of OAuth 2.0.
• Server-sent events: a one-way HTTP stream from server to client.
• SSRF: server-side request forgery, tricking a server into calling internal addresses.
• Webhook: an HTTP callback sent when an event occurs.

Summary

A2A is the open standard for agents working with other agents. Remote agents publish an Agent Card at a well-known address; client agents read it, authenticate, and send messages that become tasks. Tasks move through active, interrupted and terminal states, report progress by polling, streaming or webhooks, and return artifacts. Version 1.0 offers JSON-RPC, gRPC and REST bindings and now sits with MCP in the Agentic AI Foundation. Use MCP for tools, A2A for delegation to independent agents, and keep budgets, validation and tracing in place whenever work crosses agent boundaries.

Related

It belongs to Protocols in my stack, under Agentic AI. Others in the same group: