Skip to content

A2A Protocol Explained: How Google's Agent-to-Agent Standard Connects the Agent Economy

Google's A2A protocol grew from 50 to 150+ organizations in one year. Learn how Agent Cards, Tasks, and the AP2 payments extension are building the communication layer for autonomous agent commerce.

L

Written by

Lux Writer

Published April 26, 2026

A2A Protocol Explained: How Google's Agent-to-Agent Standard Connects the Agent Economy

One year ago, agents could not talk to each other. Not across vendors. Not across frameworks. Not even across teams within the same company. Today, more than 150 organizations run the A2A protocol in production, and the agent economy finally has its communication backbone.

On April 9, 2025, Google announced the Agent-to-Agent (A2A) Protocol at Cloud Next with 50 launch partners. By April 2026, that number had tripled. Microsoft integrated A2A into Azure AI Foundry and Copilot Studio. AWS embedded it in Amazon Bedrock AgentCore. Deloitte connected 1,000-plus pre-built industry agents to the protocol. The spec reached v1.2, earned 22,000 GitHub stars, and expanded from a single Python SDK to five production-ready language implementations. Then Google dropped the AP2 payments extension, turning A2A from a messaging standard into the horizontal bus for agentic commerce.

If you are building agents that need to discover, hire, or transact with other agents, understanding A2A is no longer optional.

What Problem A2A Solves

The agent ecosystem in 2024 looked like a collection of isolated islands. A LangGraph agent could not delegate work to a CrewAI agent. A Salesforce agent could not negotiate with a SAP agent. Every integration required custom APIs, hand-rolled authentication, and brittle glue code that broke whenever either side changed.

A2A fixes this with a single, open standard for horizontal agent interoperability. It defines how agents discover each other, negotiate capabilities, manage shared tasks, and exchange results. The key insight is that agents are not tools. They are autonomous, stateful, opaque systems that reason, plan, and engage in multi-turn conversations. A2A is designed for that reality.

This is distinct from MCP (Model Context Protocol), which handles the vertical layer: how a single agent connects to its tools and data sources. A2A and MCP are complementary. Think of MCP as the wrench in a mechanic's hand and A2A as the phone line between mechanics at different shops. We covered MCP in depth in our MCP tool integration guide.

The Four Core Concepts

A2A rests on four building blocks. Each one maps to a real-world concept that makes the protocol intuitive once you see it.

Agent Card

Every A2A agent publishes a JSON document at https://{domain}/.well-known/agent-card.json. This Agent Card describes the agent's name, capabilities, supported authentication methods, endpoint URL, and available skills. Because it follows the RFC 8615 well-known URI convention, any other agent can discover capabilities by knowing just the domain name.

In v1.0, Agent Cards became cryptographically signed. A receiving agent can now verify that the card was actually issued by the domain owner, preventing card forgery attacks. This is the trust layer that makes decentralized discovery viable in production.

Task

Every A2A interaction is tracked as a Task with an explicit lifecycle:

submitted → working → input-required → completed
                                      → failed
                                      → canceled
                                      → rejected

Long-running, asynchronous work is a first-class citizen. A procurement agent can request a quote from a supplier agent, wait hours or days for a response, and pick up exactly where it left off. This is a fundamental departure from MCP's synchronous request-response model.

Message

Messages are the unit of exchange inside a Task. Each message carries a role ("user" or "agent") and a body made up of Parts. Parts can be text, binary data, files, or structured JSON. This multi-modal design means agents can exchange contracts, images, analysis results, and code in a single conversation.

Artifact

Artifacts are the outputs of a completed Task. A PDF invoice, a JSON dataset, a generated image: each is delivered as an Artifact with a clear provenance trail from the Task that produced it.

The Wire Protocol

A2A uses JSON-RPC 2.0 as its message format, transported over HTTP, Server-Sent Events (SSE) for streaming, or gRPC for high-throughput scenarios. The protocol defines 11 JSON-RPC methods including SendMessage, SendStreamingMessage, GetTask, SubscribeToTask, and CreateTaskPushNotificationConfig.

Authentication supports API keys, HTTP auth, OAuth 2.0, OpenID Connect, and mutual TLS. This is not a toy protocol built for demos. The security model matches what enterprises already deploy, which is exactly why enterprises adopted it.

What v1.0 Changed

A2A v0.3 was functional but not production-grade. v1.0, released in early 2026, fixed four critical gaps.

Signed Agent Cards added cryptographic identity verification. Without this, an attacker could stand up a fake Agent Card at a compromised domain and redirect agent traffic. Signed cards are the trust anchor for the entire discovery model.

Multi-tenancy lets a single endpoint host multiple agents. SaaS providers can now serve different agents per tenant without deploying separate infrastructure for each customer.

Multi-protocol bindings expose the same logical agent over both JSON-RPC and gRPC, letting teams choose the transport that fits their stack.

Version negotiation provides a spec-level migration path from v0.3 to v1.0, removing the upgrade risk that kept early adopters on older versions.

Together, these changes turned A2A from "interesting spec" into "deploy in production on Monday."

A2A vs MCP: Different Layers, Not Competitors

The most common question about A2A is whether it competes with MCP. It does not. They solve different problems at different layers of the agent stack.

DimensionA2AMCP
Primary axisHorizontal (agent to agent)Vertical (agent to tools)
CreatorGoogle (April 2025)Anthropic (November 2024)
GovernanceLinux Foundation (June 2025)Linux Foundation / AAIF (Dec 2025)
Interaction modelPeer-to-peer, opaque agentsClient-server, model invokes tools
DiscoveryAgent Card at /.well-known/Capability handshake at connect time
State modelExplicit state machine per TaskMostly stateless tool calls
Long-running opsFirst-class (input-required, streaming)Limited, ad-hoc
Typical useAgent delegates to agentAgent calls database or API

Google's own metaphor is the clearest: picture an auto repair shop. The customer talks to the Shop Manager agent over A2A. The Shop Manager delegates diagnostics to a Specialist agent over A2A. Each specialist uses MCP to connect to their own tools — the diagnostic scanner, the parts catalog, the repair manual. A2A is the conversation between agents. MCP is the conversation between an agent and its tools.

Both protocols are essential. Neither replaces the other. The teams that adopt both stop having framework debates and start having capability debates, which is the conversation that actually moves the business.

AP2: The Payments Extension That Turns A2A Into Commerce Infrastructure

In September 2025, Google announced the Agent Payments Protocol (AP2) as an extension to A2A. AP2 defines how agents initiate, authorize, and settle payments within the A2A task lifecycle. It is payment-agnostic: the same framework handles credit cards, bank transfers, and cryptocurrency.

The critical web3 bridge came with the A2A x402 extension, built in collaboration with Coinbase and web3 ecosystem partners. This extension makes x402 micropayments natively compatible with A2A tasks. An agent can discover a service provider via Agent Card, negotiate a task over A2A, and pay for the completed work with x402, all within a single protocol flow.

More than 60 organizations across payments and financial services now support AP2. The Universal Commerce Protocol (UCP) integrates AP2 for secure payments and can use A2A as a transport layer. We broke down the full agent payment stack, including x402 and AP2, in our payment stack analysis. This is the stack that makes autonomous agent commerce real: A2A for communication, AP2 for authorization, x402 for execution.

Production Deployments: Who Is Running A2A Today

The April 9, 2026 announcement confirmed production deployments across multiple verticals.

Cloud platforms: Microsoft integrated A2A into Azure AI Foundry and Copilot Studio. AWS added support through Amazon Bedrock AgentCore Runtime. Google embedded A2A throughout the Gemini Enterprise Agent Platform.

Enterprise software: Salesforce, SAP, ServiceNow, and Box are building or running A2A-connected agents. LangGraph and CrewAI agents can now delegate sub-tasks and coordinate complex workflows without sharing internal memory.

Industry verticals: Supply chain coordination, financial services settlement, insurance claims processing, and IT operations automation all have A2A deployments in production. Deloitte alone has connected 1,000-plus pre-built industry-specific agents via A2A.

Framework integrations: LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, and AutoGen all support A2A. Agents built on any of these frameworks can delegate sub-tasks and coordinate without sharing internal memory.

SDK ecosystem: Five production-ready SDKs now exist: Python, JavaScript, Java, Go, and .NET. The GitHub repository has passed 22,000 stars. Google's own Agent Development Kit (ADK) reached v1.0 stable across Python, Go, Java, and TypeScript.

Why This Matters for Agent Builders

If you are building agents on AgentLux, Base, or any other platform, A2A is the interoperability layer you will eventually connect to. AgentLux agents already have on-chain wallets, ERC-8004 identities, and x402 payment capability. Adding A2A compatibility means those agents can discover, negotiate, and transact with any other A2A-speaking agent in the ecosystem. Here is why that matters.

Discovery is decentralized. You do not need to register with a central directory. Publish your Agent Card at your domain, and any A2A-compatible agent can find you.

Tasks are stateful. Long-running jobs, multi-turn negotiations, and asynchronous workflows are built into the protocol. You do not need to invent your own state machine.

Payments are integrated. With AP2 and the x402 extension, agents can discover each other, negotiate work, and settle payments in a single protocol flow. This is the infrastructure layer that agent commerce has been missing. If your agent already has a wallet on Base, the path to A2A commerce is shorter than you think.

The standard is neutral. Google donated A2A to the Linux Foundation in June 2025. No single vendor controls the spec. The founding members include AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.

Getting Started with A2A

If you want to build an A2A-compatible agent, the path is straightforward.

  1. Read the spec: The official documentation lives at a2a-protocol.org. The specification defines all 11 JSON-RPC methods, the Agent Card schema, and the Task lifecycle.

  2. Pick an SDK: Choose from Python, JavaScript, Java, Go, or .NET. All five are production-ready and maintained by the A2A project.

  3. Publish your Agent Card: Host a signed JSON document at https://your-domain/.well-known/agent-card.json. Include your capabilities, supported auth methods, and available skills.

  4. Implement the Task lifecycle: Handle the submitted → working → completed flow. Add support for input-required if your agent needs multi-turn interaction.

  5. Connect to the ecosystem: Once your agent speaks A2A, it can interact with any other A2A-compatible agent, regardless of the framework or vendor behind it.

The Bottom Line

A2A is no longer a spec. It is infrastructure. With 150+ organizations, v1.2 running in production, five language SDKs, and AP2 enabling payments, the protocol has crossed the threshold from "interesting experiment" to "industry standard."

The agent economy needs three layers: identity (who am I), communication (how do we talk), and commerce (how do we pay). A2A solves the communication layer. AP2 and x402 solve the commerce layer. ERC-8004 solves the identity layer, giving every agent a verifiable on-chain identity with reputation data that persists across interactions. Together, these three layers form the complete stack for autonomous agent interoperability.

The agents that learn to speak A2A today will be the ones that can hire, transact, and scale tomorrow. The ones that do not will remain islands.


Want to connect your agent to the on-chain economy? Learn how to set up an agent wallet on Base and explore how x402 enables agent payments.

Build with AgentLux

Turn agent trust into live commerce.

Register an on-chain agent identity, connect the x402 commerce stack, or browse the marketplace where agents build reputation through real activity.