A2A Protocol Explained for Retailers 2026

The Agent2Agent (A2A) protocol is an open standard that lets AI agents find each other, hand over tasks and exchange results. For retailers, it can connect a customer’s shopping agent to an agent run by the store. Model Context Protocol (MCP) handles a different connection: giving an AI application access to tools and data.

An A2A connection can carry a product request between agents. Reading stock or taking payment needs the store’s own systems and the relevant commerce rules too. The retail commerce protocols guide explains how these standards fit together.

What the Agent2Agent Protocol Does

A2A gives independent agents a shared way to communicate, even when different vendors build them. The receiving agent decides how to complete the task using its own tools. It can keep its internal reasoning and implementation private.

An agent publishes an Agent Card, a structured description of its skills and how another agent can reach it. The card also describes supported connections and authentication requirements. A requesting agent uses those details to send a suitable task.

The reply can be a message or a tracked task. A task can continue over time, request more input or return a result when complete. That helps when answering a request takes several exchanges instead of one immediate response. The A2A specification defines those exchanges.

Google created A2A and donated it to the Linux Foundation. The project’s current home is the Agentic AI Foundation, which the Linux Foundation hosts. Its announcement of A2A joining the foundation explains the governance. The familiar name Google A2A describes its origin, while the standard has open project governance.

A2A vs MCP

A2A connects agents to each other. MCP connects an AI application to external tools and data, such as a catalogue search service. A retailer can use both in the same shopping workflow.

In a hypothetical shopping example, a customer asks their agent to find a waterproof jacket in navy. The customer’s agent sends the request to a retailer’s agent over A2A. The retailer’s agent uses an MCP catalogue tool to find matching jackets and read available sizes. It then sends the results back over A2A.

The two connections have different jobs. A2A lets the store’s agent handle a request as its own task. MCP gives that agent a defined way to call a tool. The official MCP introduction describes this access to external systems.

An outside shopping agent can also call a retailer’s MCP tools directly if the retailer exposes them with suitable permissions. That route doesn’t require a second agent to handle the request. Read the guide to Shopify’s MCP connections for that platform’s approach.

Where Google A2A Shows Up in Shopping

A2A carries communication between shopping and merchant agents, while commerce standards define what they exchange and how a purchase is authorised. Agent Payments Protocol (AP2) is available as an extension for A2A. It adds verifiable payment authorisation to agent commerce.

A2A support alone doesn’t give an agent permission to spend a customer’s money. The AP2 documentation describes that separate payment layer. Our guide to AP2 explains the purchase authorisation in more detail.

Universal Commerce Protocol (UCP) also has an A2A checkout binding. A business that supports this connection advertises its Agent Card through its UCP profile. Shopping platforms can then exchange structured checkout information with the business agent.

For example, imagine an outside agent helping a customer buy a desk lamp. It reaches a retailer’s agent and asks for an available lamp with delivery to the customer’s postcode. The retailer’s agent returns a suitable item and delivery options. If both sides support the relevant checkout capability, they can continue into a checkout exchange.

That example describes a supported design, not a promise that every shopping assistant can reach every store. Both sides need compatible capabilities and access. A standard supplies the shared format. The retailer or its provider supplies the working connection. These connections are part of agentic commerce, where agents carry out shopping tasks for customers.

Does Your Store Need to Support A2A

Your store needs A2A when a chosen shopping channel must communicate with your store’s agent over that protocol. For most retailers, the practical route is through a commerce platform or agent provider. Building a protocol service becomes relevant when your team owns a custom agent and its outside connections.

Start with the shopping channel you want to serve. A vendor’s A2A label tells you less than a demonstrated request from that channel to your store’s catalogue. Ask the vendor these questions.

• Which outside agents can reach our store, and which shopping tasks work today?
• Where is our Agent Card, and which A2A versions and connection methods does it support?
• How do you authenticate the outside agent and limit its access to customer information?
• Can an agent read product details only, or can it create and update a basket?
• Which checkout and payment standards do you support, and where does customer authorisation happen?
• What happens when stock changes or a task fails, and how can our team inspect the exchange?

Ask for a demonstration that changes a product choice midway through the conversation. Then have the outside agent request an unavailable item. The store’s agent must return the actual availability and a usable response without treating an earlier result as current stock.

Choose A2A support for a named shopping workflow. If your provider can demonstrate that workflow and its permissions, you can assess the value of the connection before committing to custom development.