Agent-to-Agent Protocol (A2A) — how AI agents discover and coordinate with each other

What is Agent-to-Agent Protocol (A2A)?

A2A is an open protocol introduced by Google in April 2025 — now hosted by the Linux Foundation's Agentic AI Foundation — that defines how AI agents discover each other, share capability descriptors (agent cards), and coordinate multi-step tasks across organizational and platform boundaries.

By the numbers

• 150+ — organizations backing the Agent2Agent protocol within its first year (Linux Foundation)
• 22,000+ — GitHub stars on the core a2aproject repository as the protocol marks year one (Linux Foundation)
• 3× — growth in A2A supporter count from Google's April 2025 launch to Linux Foundation year-one milestone (Google Developers Blog)

Why it matters

Multi-agent workflows are emerging fast. A user's personal assistant agent talks to a vendor's shopping agent talks to a payment-network agent — each agent has its own scope, capabilities, and trust boundary. Without a standard, every multi-agent coordination is custom integration. A2A standardizes the discovery + handshake + coordination layer.

A2A solves the "how do agents find each other" problem. Pre-A2A, an agent needing to call another agent had no standard way to discover its endpoint, learn its capabilities, or negotiate authentication. Every integration was bespoke. A2A defines a uniform agent card — a JSON document describing what an agent can do — and a discovery mechanism that solves the discovery layer the way OpenAPI solved API description. The card carries capability descriptors, skills, and the endpoint contract.

Multi-agent flows are the next major UX shift. Today: one user, one agent, one service. Tomorrow: a personal assistant agent coordinates with multiple vertical agents (shopping, scheduling, financial planning) to complete tasks the user describes once. A2A is the substrate that makes this composable — each cross-agent step is an A2A task with a defined state machine.

Enterprise adoption signals are strong. Google's launch partner roster (April 2025) included Atlassian, Box, Cohere, Datadog, Deloitte, Elastic, EPAM, JetBrains, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and UKG. The Linux Foundation's Agentic AI Foundation — Dec 2025, with eight platinum members including Cloudflare and AWS — is the standardization venue. The center of gravity is converging.

A2A and MCP are complementary, not competing. MCP covers agent-to-service ("my agent calls Stripe's MCP server to charge a customer"). A2A covers agent-to-agent ("my agent coordinates with Salesforce's agent to update a CRM record across the workflow"). Sites that ship both surfaces are addressing the full agent stack — and Google's framing of the layered stack ("Build with ADK, equip with MCP, communicate with A2A") makes the composition explicit.

Where it's heading

Multi-agent flows enter mainstream UX in 2026-2027. Today most agent interactions are single-agent; coordinating multi-agent flows is mostly research-and-pilot. By 2027, expect personal-assistant agents (ChatGPT, Claude, Gemini) to routinely coordinate with vertical agents via A2A. The signal to watch: the first consumer-grade flow where the user doesn't notice the cross-vendor hand-off.

A2A authorization spec emerges. Today, A2A auth is implementer's choice. The Linux Foundation Agentic AI Foundation is the likely venue for standardization. Expect a per-agent identity verification spec — parallel to OAuth scopes for HTTP APIs — by 2027.

MCP and A2A converge at the transport layer. Currently slight format differences. Convergence pressure is high — agents want one protocol to learn. Expect either MCP gaining A2A semantics or A2A using MCP's transport. The working-group activity at the Linux Foundation is the leading indicator.

Agent cards become a discoverability primitive. Similar to how /.well-known/openid-configuration made OAuth discovery standard, /.well-known/agent-card.json will likely standardize for A2A discovery. The next layer up: agent-card directories and search surfaces that index public cards across the SaaS top-1000.

Common mistakes

• Treating A2A as an alternative to MCP. They solve different problems. Most services need MCP; some services additionally need A2A. Picking one and skipping the other leaves either the service or the agent surface uncovered.
• Shipping an agent card with empty / placeholder descriptions. The card is the agent's pitch to other agents. Generic descriptions get ignored — agents downstream have no signal for when to call you. Treat the card with the same care as a public API spec.
• Not implementing task lifecycle correctly. Agents that don't update task status correctly create coordination failures in multi-agent flows. Test the state machine explicitly — partial failures and timeouts are the common bugs.
• Skipping authentication. A2A endpoints without auth are footguns. Use OAuth or capability tickets, not no-auth. The same auth discipline that applies to MCP servers applies here — see MCP Authorization for the pattern.
• Building an agent without a reason. Not every service needs an agent. If your value is data + simple actions, an MCP server is enough. Agents are for workflows + decision logic that benefit from being callable by other agents.

Frequently asked

Related

• Agent Protocols (FRONTIER HUB) — A2A is one of the two foundational protocols (alongside MCP) for the agent layer.
• Model Context Protocol (PARAMETER) — Companion protocol — MCP covers agent-to-service where A2A covers agent-to-agent.
• NLWeb (PARAMETER) — NLWeb builds on Schema.org markup; A2A builds on agent cards. Different layers, complementary roles.
• Salesforce AppExchange (PARAMETER) — Salesforce was an A2A launch partner — listing on AppExchange now signals A2A-compatibility in the routing layer.