A2A (Agent-to-Agent) is an open protocol for AI agents built on different frameworks to discover each other, exchange structured tasks, and collaborate without exposing their internal state, memory, or tools. Google announced A2A on April 9, 2025 with 50+ launch partners, donated it to the Linux Foundation later that year, and by the one-year mark on April 9, 2026 the protocol counted 150+ supporting organizations, 22,000+ GitHub stars, and production deployments inside Microsoft Azure AI Foundry, Amazon Bedrock AgentCore, and Salesforce Agentforce. The mechanism is small: an agent publishes a signed Agent Card describing what it can do, a calling agent posts a JSON-RPC task to the endpoint, the task progresses through a defined lifecycle, and the result returns either synchronously, over Server-Sent Events, or via a callback URL. The protocol's relevance to commerce sits in delegation: a shopping agent delegates price comparison to a specialist agent, then delegates checkout to a merchant-side agent, with A2A defining the wire format the whole way down. This article is the technical primer — what A2A is, how the task envelope and Agent Card work, who runs it in production, how it relates to MCP and x402, and why agentic commerce stacks treat A2A as the spine that holds the rest of the protocols together.
​

A2A is an open, vendor-neutral protocol that lets AI agents built on different frameworks discover, authenticate, and delegate tasks to one another over JSON-RPC 2.0 atop HTTPS. Originally developed by Google and donated to the Linux Foundation in 2025, A2A reached 150+ supporting organizations by April 9, 2026 and is treated as the standard agent-to-agent transport across major cloud platforms.
​

The protocol's full name is Agent2Agent. The shorthand A2A is the form used in Google's announcement, the Linux Foundation press materials, and every cloud-platform integration page. Its purpose is narrow: standardize how one agent finds another agent, verifies its identity, and hands off a unit of work without either side exposing its internal model, prompt history, tool roster, or execution state. That opacity is the design contract. An A2A server agent takes work and returns a result; the calling agent does not see how the work happens, and the server agent does not see how the request was generated. Both sides retain proprietary internals, which is what made A2A acceptable to enterprise vendors who would not otherwise expose their internal agent infrastructure.
​

The reference implementation lives at github.com/a2aproject/A2A, Apache 2.0 licensed, with five language SDKs (Python, JavaScript, Java, Go, .NET) and the official specification at a2a-protocol.org. The current production version is v1.0 (released March 12, 2026), which formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification. The repository carries 22,000+ stars at the one-year mark. The Linux Foundation cites the SDK breadth as the reason cross-runtime adoption moved fast: an agent built in Python can call a .NET agent and a Go agent in the same task graph without serialization shims.
​

Governance moved off Google in two phases. The April 9, 2025 launch was a Google project with 50+ partners. The donation to the Linux Foundation's Agentic AI Foundation later that year placed the spec under neutral stewardship, the same foundation that hosts MCP. By the time the one-year press release shipped, the eight headline supporters were AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow, with the broader 150-organization pool spanning agent platforms, framework vendors, and end-user enterprises across regulated industries.
​

Sister protocol Agent Payments Protocol (AP2), which builds on A2A for payment authorization, reached 60+ supporting organizations at its September 2025 launch. That overlap, with A2A as the messaging substrate, AP2 layered on for payment intent, and x402 as one possible settlement rail, is the canonical layering visible in production agentic commerce stacks. A2A by itself does not move money. It moves tasks, and one of those tasks can be "complete this purchase."
​

A2A uses JSON-RPC 2.0 over HTTPS as its message envelope. An A2A server publishes a signed Agent Card at a well-known URL listing its skills, endpoint, and auth requirements. Calling agents post tasks to the endpoint, the tasks move through a defined lifecycle, and results return synchronously, via Server-Sent Events, or asynchronously via callback URLs.
​

Three primitives carry the protocol: the Agent Card, the task envelope, and the lifecycle state machine. Each is small in isolation, and the surface area of a basic A2A integration is roughly the size of a single REST endpoint plus an SDK call.
​

Every A2A server agent publishes an Agent Card, a JSON metadata document, at the well-known path /.well-known/agent-card.json. The card lists the agent's name and description, its endpoint URL, the authentication schemes it accepts (bearer tokens, OAuth 2.0, AWS SigV4 in AgentCore deployments), the skills it advertises with input/output schemas, the protocol versions it negotiates, and any rate limits or pricing it wants to surface to callers. Amazon Bedrock AgentCore's A2A protocol contract documents this layout precisely. Agents run stateless streamable HTTP servers on port 9000, and the agent card is the discovery anchor for everything that follows.
​

v1.0 formalized signed Agent Cards. The card is signed with a key whose public key is published under the same domain, letting a calling agent verify both the integrity of the metadata and the domain ownership of the server in a single check. That signature path is what made A2A acceptable to enterprises with strict identity controls. Without it, any host could publish an Agent Card claiming any skill set.
​

Once a calling agent has resolved an Agent Card, it posts a task to the endpoint as a JSON-RPC 2.0 request. The body carries a unique task ID, the skill ID being invoked, the input payload (text, structured JSON, files, or media), and any metadata about urgency or callback expectations. JSON-RPC 2.0 was chosen because it is well-understood, language-agnostic, and already tooled across every backend ecosystem the SDKs target. The same wire format handles MCP, which simplifies the proxy and gateway layer for stacks that route both protocols. HTTPS is non-negotiable in production: the reference servers, the AWS contract, and the Microsoft Foundry endpoint all require TLS.
​

A task moves through a defined state machine: submitted → working → input-required → completed | failed | canceled | rejected. The A2A specification codifies the transitions. `submitted` means the task has been accepted but not started. `working` indicates processing. `input-required` is a pause that lets the server agent ask for additional context, returning to `working` once the caller responds. The four terminal states end the task permanently and cannot restart. That non-restartability is intentional, forcing calling agents to make explicit decisions about retry semantics rather than reusing stale state.
​

A2A supports three call patterns, and the right one depends on the workload. Synchronous request/response works when the task is fast and the caller can block, like a price-comparison call returning in under a second. Streaming via Server-Sent Events (SSE) suits long-running tasks where intermediate results are useful, like a research agent sending partial findings as it crawls. Asynchronous push notifications via callback URLs handle tasks that take minutes or hours: the calling agent registers a webhook, the server agent does the work, and the result lands on the webhook when ready. Calling agents discover which patterns a server supports from the Agent Card.
​

Agent Cards declare which auth schemes the server accepts. Bearer tokens and OAuth 2.0 are the defaults for cross-organization calls. SigV4 is the path inside AWS AgentCore. Mutual TLS appears in some enterprise integrations. Whatever the scheme, the protocol enforces a strict opacity contract: the calling agent never sees the server agent's prompt, model, tools, or memory, and the server agent never sees the calling agent's internal state. Both sides exchange tasks and results, nothing more. A Salesforce Agentforce agent calling a Microsoft Foundry agent does not learn anything about Microsoft's prompts or models, and vice versa.
​

By April 9, 2026, A2A was running in production inside Microsoft Azure AI Foundry, Amazon Bedrock AgentCore Runtime, and Salesforce Agentforce 3, plus enterprise deployments at IBM, Cisco, SAP, and ServiceNow. The Linux Foundation's one-year press release named these as the headline cloud platform integrations and confirmed enterprise production usage in regulated industries.
​

Three named cloud-platform deployments anchor the production landscape. Each is worth examining individually because the integration shape differs.
​

Microsoft Azure AI Foundry. Microsoft shipped A2A integration into Azure AI Foundry and Copilot Studio across late 2025 and early 2026. The April 2026 release notes for Microsoft Foundry list "Add an A2A agent endpoint to Foundry Agent Service (preview)" as a supported feature, letting a Foundry-hosted agent invoke any A2A-compliant external agent endpoint as a tool. The .NET A2A SDK shipped alongside Microsoft Agent Framework 1.0 GA on April 3, 2026. Azure's "Agent Factory" framing positions MCP and A2A as the two open standards Foundry treats as first-class: MCP for tool access, A2A for agent-to-agent.
​

Amazon Bedrock AgentCore Runtime. Amazon added native A2A support to Bedrock AgentCore Runtime in late 2025 and broadened it to the AWS Marketplace in November 2025. AWS's launch post details the contract. Containers run stateless streamable HTTP servers on port 9000, the Agent Card lives at the well-known URL, and the runtime supports both SigV4 and OAuth 2.0. The integration is framework-agnostic. Agents built on Strands, OpenAI Agents SDK, LangGraph, Google ADK, or the Claude Agents SDK can all run as A2A servers inside AgentCore, and AWS Marketplace now lets customers procure third-party A2A servers and deploy them into AgentCore Runtime.
​

Salesforce Agentforce 3. Salesforce announced A2A general availability at TDX 2026 as part of its "Control and Orchestrate" release alongside Agent Fabric. Salesforce's positioning treats A2A and MCP as a paired open-standard set: MCP for accessing Salesforce data and external tools, A2A for delegating work across agent systems built on different platforms. An Agentforce agent can now resolve a customer request that spans a Microsoft Copilot agent and an internal Salesforce agent without either side losing context.
​

Beyond the cloud-platform anchors, the Linux Foundation's April 2026 release names IBM, Cisco, SAP, and ServiceNow among the production users, with adoption in regulated sectors reflected in the auth schemes the protocol added (signed Agent Cards being the most consequential). The 150-organization pool spans framework vendors (LangChain, CrewAI), agent-platform startups, and end-user enterprises that publish their own internal agent fleets. A2A is the only agent-to-agent protocol with adoption that crosses every major cloud and the major enterprise-software vendors at the same time.
​

A2A and MCP are complementary, not competitive. MCP standardizes how an agent talks to tools and data (vertical, single-agent context), while A2A standardizes how agents talk to each other (horizontal, multi-agent delegation). Most production agent stacks run both — MCP for the tool layer, A2A for inter-agent coordination — and the Linux Foundation hosts both protocols under the same Agentic AI Foundation umbrella.
​

The most common new-developer mistake is treating A2A and MCP as alternatives. They are not. They sit at different layers of the agent stack and solve different problems. The table below summarizes the four dimensions where they differ most.

A concrete example clarifies the layering. A user asks a shopping agent built on Salesforce Agentforce to "find the cheapest 1TB SSD under $80 and ship it." The Agentforce agent uses MCP to read its product catalog. To delegate the price-comparison search to a specialist agent built on Microsoft Foundry, it uses A2A: fetch the Foundry agent's Agent Card, post a task with the SKU and budget, receive a structured result. Once a winning SKU is selected, the Agentforce agent uses A2A again to delegate the checkout call to the merchant-side agent. That merchant agent uses MCP internally to call its order-management tools, and uses AP2 (built on A2A) to obtain a signed user mandate for the $79.99 purchase. Settlement then runs on the merchant's chosen rail: Stripe Shared Payment Tokens, an x402 stablecoin transfer, or a card processor.
​

Each protocol shows up exactly once at its own layer. The A2A specification's "A2A and MCP" section codifies the same layering: MCP solves the agent's relationship to its tools, A2A solves the agent's relationship to other agents. MCP is what lets a single agent be more capable. A2A is what lets a population of agents be more capable together. MCP integrations are tool-by-tool, each tool a unit of capability the agent can pull. A2A integrations are agent-by-agent, each agent a unit of capability the calling agent can delegate to without owning. Cloud-platform vendors care about both because MCP grows the surface area of any one agent, and A2A grows the surface area of the agent network.
​

A2A by itself is a messaging and delegation protocol — it does not move money. Agent-to-agent payments happen by composing A2A with one or more payment protocols on top: AP2 for the user-consent mandate, x402 for stablecoin settlement over HTTP, or a traditional card processor for fiat. The "A2A x402 extension" developed by Google with Coinbase, Ethereum Foundation, and MetaMask is the canonical pairing for crypto-native flows.
​

The composition is straightforward to describe and worth walking through. When a calling agent delegates a task that has a price (run a query against a paid dataset, complete a checkout, settle a B2B invoice), the workflow layers three protocols. First, A2A handles the messaging — the calling agent finds the server agent's Agent Card, posts the task, and the server agent advertises its price. Second, AP2 attaches a signed payment mandate to the task — the user (or the calling agent acting under delegated authority) signs an intent confirming the agent is authorized to spend up to a specific amount with the named counterparty. Third, settlement happens on whatever rail the merchant accepts. Google's AP2 launch announcement describes 60+ payment-rail partners on launch day including Adyen, American Express, Ant International, Coinbase, Mastercard, PayPal, Revolut, Salesforce, and Worldpay.
​

For stablecoin-native flows, the canonical pattern is the A2A x402 extension. Coinbase's launch page describes the integration: A2A handles agent identity and task messaging, while x402's HTTP 402 mechanism handles the actual stablecoin transfer. The flow returns a 402 response with payment terms when the server agent expects payment, the calling agent signs an EIP-3009 USDC transfer authorization, retries the task with a `PAYMENT-SIGNATURE` header, and the server agent confirms onchain settlement before returning the task result. The pattern works because A2A's task envelope is HTTP-native — adding the 402 path and the payment header is a localized change, not a protocol fork.
​

The total stablecoin market sat at $318 billion as of DeFiLlama's April 29, 2026 snapshot, with USDT at $189.5 billion and USDC at $77.3 billion as the two dominant agent-payment tokens. The volume that flows specifically through agent-to-agent pairings is small relative to the total stablecoin float but growing fast — x402 alone reported 165 million transactions across roughly $50 million in cumulative protocol volume by mid-April 2026 per the x402 explainer, and the A2A x402 extension is one of the channels feeding that count.
​

In agentic commerce, A2A is the spine connecting shopping agents, specialist agents, and merchant agents into a single delegated transaction. A typical purchase moves through three or four agents (shopper, price comparison, merchant, fulfillment) and each handoff uses A2A. Without it, every agent platform would need bilateral integrations with every other platform.
​

Three properties of A2A make it specifically useful for commerce as opposed to other multi-agent workloads.
​

The first is opacity. Merchants do not want to expose inventory models, pricing logic, or fraud rules to the calling agent. The opacity-by-design contract, where the calling agent sees only the task interface and never the implementation, is what lets large retailers integrate without revealing internals. A merchant agent published as an A2A server can advertise "search inventory," "quote price," "place order," and "track shipment" without exposing the inventory database, the pricing engine, or the fraud-detection layer behind them.
​

The second is delegation chains. Commerce flows are rarely two-party. A user's shopping agent delegates price comparison to a specialist agent, which itself delegates a query to a market-data agent, which itself delegates a real-time-pricing call to an exchange agent. A2A's task envelope and lifecycle work cleanly through deep delegation chains because each task is independent and each Agent Card is independently resolvable. The user's agent does not need to know the topology.
​

The third is payment composability. The A2A x402 extension and AP2's reliance on A2A as a transport mean payment instruments can attach to any task that needs them without an out-of-band integration. Agentic payments systems built around A2A inherit the same task envelope for free, which is why payment-rail vendors who joined AP2 (Adyen, Mastercard, PayPal, Worldpay) treated it as a near-drop-in extension rather than a parallel build.
​

The 2026 agentic commerce stack has a clear shape. MCP at the bottom for tool access. A2A above for agent delegation. AP2 for payment authorization on top of A2A. x402 or a card processor for settlement. The protocols-compared piece covers the alternatives in detail. The through-line is that A2A is the connective tissue and the other protocols layer onto it. Google's Universal Commerce Protocol (UCP) for instance assumes A2A as the agent transport underneath its broader merchant-journey spec.
​

A2A solves agent-to-agent transport. It does not solve identity attestation outside its own scope, settlement finality, or schema standardization across skill catalogs. Production deployments pair A2A with AP2 for consent, with x402 or card rails for settlement, and with vertical-specific schemas for the actual task payloads — A2A defines the envelope, not the contents.
​

Three tradeoffs are worth flagging in any A2A integration evaluation.
​

The first is the limit of opacity. The same property that made A2A acceptable to enterprise vendors also limits the protocol's expressiveness for use cases where shared context would be valuable. Two collaborating agents that need to reason about a shared mental model cannot do so through A2A alone. They exchange tasks and results, not state. For workflows where shared state is core (multi-agent simulations, long-horizon planning), A2A is a transport, not a coordination model. Teams running into this limit typically layer a shared-state protocol on top, often through MCP-mounted memory tools.
​

The second is the schema problem. A2A standardizes the envelope but not the contents of skill payloads. Two e-commerce agents that both advertise a "search inventory" skill might use entirely different input schemas. One expects a SKU and zip code, the other a free-text query and category tree. Cross-platform skill compatibility requires either out-of-band schema agreements or vertical-specific extensions on top of A2A. The Linux Foundation's working groups are building these vertical schemas, but the protocol does not enforce them at the wire level.
​

The third is settlement and dispute. A2A transports tasks that may resolve into payments, but A2A itself does not record finality, handle chargebacks, or enforce payment guarantees. Those properties come from the payment protocol underneath. A merchant agent that completes a task with an x402 stablecoin settlement has no chargeback path. A merchant agent that completes the same task with a Stripe Shared Payment Token has the card-network dispute window. Selecting the right payment rail to compose with A2A is a separate engineering decision.
​

Sources and methodology. Adoption and integration figures verified against the Linux Foundation A2A one-year press release, the a2aproject GitHub repository, and the A2A specification at a2a-protocol.org. Cloud-platform integrations cross-checked against vendor docs at AWS, Microsoft Foundry, and Salesforce. Stablecoin supplies pulled from DeFiLlama on April 29, 2026. Figures refresh quarterly.
​

A2A defines the agent-to-agent message envelope, but the dollars an agent owes still settle on a specific chain. When a merchant agent accepting USDC on Solana receives a task from a calling agent holding USDC on Base, A2A marks the task complete only after the stablecoin moves between chains. Eco handles that cross-chain stablecoin orchestration.
​

Eco operates as a stablecoin execution network across 15 chains, abstracting routing, solver selection, and finality so an A2A integration does not have to ship its own bridging logic per merchant. For agent platforms composing A2A with stablecoin settlement (the A2A x402 extension is the canonical pattern), Eco fills the gap between the messaging layer and the network where the stablecoin balance actually lives. Settlement-chain selection becomes its own engineering surface once an agent platform's merchant network spans more than one chain. Cross-chain agent payments walks through the tradeoffs in more depth.
​