FinWikiPublic-source finance field guide
日EN

Agent2Agent (A2A) · cross-vendor agent interoperability protocol

ConfidenceLikely
Updated2026-07-03
Review by2027-01-03
Sources12Machine-translatedOriginal (JA)
#agent-economy#protocol#a2a#agent2agent#interoperability#google
On this page

Wiki route

This entry sits beside AI Agent payment protocols overview because agent commerce needs a non-payment coordination layer before money moves. Read it against AP2 · Google Agent Payments Protocol and agent payment protocol comparison for the payment boundary, agent identity bridge for identity and authorization, and Claude Code extension architecture for a contrasting tool / extension surface. Use systems index for the broader software interoperability layer and payments index for the regulated payment boundary.

Key facts

  • Agent2Agent (A2A) is an open protocol created by Google for secure agent-to-agent communication and collaboration across vendors, platforms, and frameworks. •
  • Google announced A2A on 2025-04-09 with support from more than 50 technology and service partners, then transferred the specification, SDKs, and developer tooling to a Linux Foundation-hosted project on 2025-06-23. •
  • The Linux Foundation described A2A as vendor-neutral under its governance, with more than 100 supporting companies at launch and more than 150 supporting organizations by 2026. •
  • A2A is the discovery / delegation / messaging layer: agents advertise capabilities, exchange messages, manage tasks, and collaborate without exposing private memory, internal tools, or implementation state. •
  • The protocol standardizes Agent Cards, including the recommended public discovery path https://{agent-server-domain}/.well-known/agent-card.json. •
  • A2A is distinct from AP2: AP2 is the payment / mandate layer for agent-led commerce, while A2A is the peer-agent communication layer that AP2 can extend or ride on. •
  • A2A is complementary to MCP: MCP connects an agent to tools and resources, while A2A connects independent agents to each other across organizational boundaries. •
  • By 2026, A2A had cloud-platform support across Microsoft Azure AI Foundry / Copilot Studio, Amazon Bedrock AgentCore Runtime, and Google Cloud surfaces such as ADK, Agent Engine, Cloud Run, Gemini Enterprise, and AI Agent Marketplace. •

Mechanism / How it works

A2A treats agents as peers rather than as hidden function calls. A client agent discovers or is configured with a remote agent, inspects the remote agent’s Agent Card, chooses an interaction mode and authentication scheme, then sends task-oriented messages. The remote agent can return immediate results, stream progress, or continue a long-running task whose state and artifacts can be fetched later.

The Agent Card is the discovery primitive. It is a JSON document describing the remote agent’s identity, provider, endpoint URL, supported capabilities, authentication requirements, input / output modes, and skills. The public-web pattern is deliberately simple: publish the card under /.well-known/agent-card.json so another agent can fetch it with HTTP GET. Enterprise deployments can also use curated registries or private configuration when public discovery would expose sensitive capabilities.

The protocol’s core operation is delegation, not settlement. A recruiting agent can hand off background checks to a compliance agent; an incident-response coordinator can route log analysis to an observability agent and remediation research to another agent; a commerce agent can discover a merchant or payment agent before a payment layer is invoked. A2A supplies the shared language for the handoff: messages, tasks, artifacts, status updates, streaming, push notifications, and protocol-version negotiation.

That boundary matters for the adjacent standards:

Layer What it standardizes Relation to A2A
A2A Agent discovery, peer messaging, task state, delegation, and multimodal exchanges Horizontal agent-to-agent fabric
MCP Tool and resource access for an agent, such as databases, APIs, files, or local functions Vertical agent-to-tool interface
AP2 User authorization mandates and payment accountability for agent-led commerce Payment / commerce extension that can compose with A2A

In production clouds, A2A has become a way to avoid one-off adapters between agent frameworks. Microsoft describes A2A support for Azure AI Foundry and Copilot Studio; AWS documents A2A support in Amazon Bedrock AgentCore Runtime, including authenticated Agent Cards at /.well-known/agent-card.json; Google Cloud documents native A2A build / deploy / marketplace flows across ADK, Agent Engine, Cloud Run, Gemini Enterprise, and AI Agent Marketplace.

Origin & evolution

Google announced A2A in April 2025 as an open protocol for agent interoperability, positioning it as complementary to Anthropic’s MCP. The original design principles were pragmatic web alignment: HTTP, SSE, JSON-RPC, enterprise authentication / authorization, support for long-running tasks, and modality-agnostic content parts rather than a text-only chat pipe.

In June 2025, Google donated A2A to the Linux Foundation. The donation included the specification, SDKs, and developer tooling, and the Linux Foundation framed the project as a neutral home for agent interoperability. Foundational participants named in the donation announcement included Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.

By 2026, the project had shifted from launch-stage signaling to platform integration. The Linux Foundation reported more than 150 supporting organizations, version 1.0 as the first stable specification, Signed Agent Cards for cryptographic identity verification, multi-protocol support, and cloud integrations. Google Cloud also moved A2A into its own product surfaces: ADK for building A2A agents, Agent Engine / Cloud Run / GKE for deployment, Gemini Enterprise for registering external A2A agents, and AI Agent Marketplace for distribution.

The strategic reading is that A2A tries to become the inter-agent control plane. It does not decide who pays, who holds funds, or which wallet / card / bank rail settles the transaction. Instead, it makes agents legible and reachable to each other. That is why the protocol is most useful when read beside AP2 and agent payment protocols: AP2 can prove user authorization to transact, but A2A lets the relevant agents find each other, delegate work, and preserve task context before and after the payment step.

Sources

Discovery

Keep reading

Related

Read next