A2A Protocol (Agent2Agent)

What is the A2A Protocol?

A2A Protocol (Agent2Agent) is an open standard that lets AI agents built by different teams and vendors discover each other, delegate tasks, and return results securely. It defines the handshake between autonomous agents, so collaboration stops depending on a private integration written for one pair of systems.

The protocol runs on familiar web plumbing: JSON-RPC 2.0 over HTTPS, with Server-Sent Events carrying updates for work that takes minutes or hours. Nothing about it demands a new transport layer, which is why a service can expose an A2A endpoint alongside the APIs it already serves.

How the A2A Protocol works

A2A defines four moving parts: discovery, task creation, streaming updates, and completion.

Discovery starts with the Agent Card, a JSON document published at a well-known URL that lists an agent's skills, its endpoint, and the authentication schemes it accepts. It plays the role for a running agent that a model card plays for a model: a machine-readable declaration a stranger can evaluate before trusting it.

A client agent then opens a task by sending a JSON-RPC request carrying the user's intent and whatever context the remote agent needs to act. The remote agent, usually built on its own AI agent framework, works the task through its own model, its own tool calling, and its own data access, none of which the client sees.

Progress flows back as streamed status events until the task reaches a terminal state and returns artifacts. That loop is what makes AI agent orchestration across organizational boundaries practical.

Types of A2A interaction patterns

The specification defines one task lifecycle, and teams use it in a handful of recurring shapes.

• Single delegation: A client agent hands one bounded task to one remote agent and waits for a single artifact, the simplest and most common shape.

• Parallel fan-out: A coordinating agent opens tasks with several remote agents at once and assembles one reply, useful when a refund dispute needs payments and compliance input together.

• Long-running task: The remote agent accepts work that takes minutes or days, streaming status events until a terminal state, which suits identity checks and manual reviews.

• Input-required loop: The remote agent pauses and asks for missing information, so the client agent can return to the customer without losing the open task.

• Chained handoff: One remote agent opens its own task with a third agent, extending the chain, though every hop adds latency and another point of failure.

A2A Protocol vs MCP vs custom API integrations

Teams reading the specifications for the first time reasonably assume these three solve one problem. The A2A Protocol connects one autonomous agent to another autonomous agent it did not build. The Model Context Protocol connects one agent to the tools, files, and data sources it calls directly. A custom API integration connects one system to one other system on terms two engineering teams negotiated privately. A2A is the layer that holds up when the agent on the other end is a black box you have no right to inspect.

If the work stays inside your own stack, a direct integration is cheaper to run and you should keep it. Reach for A2A at the moment a second organization's agent has to complete a step of a customer's request.

Why the A2A Protocol matters for customer experience

Without a shared handshake, every pair of agents needs its own integration, and the pair count grows with the square of the number of agents. Ten agents across four companies is a maintenance problem nobody staffs, so the integrations that get built are the two or three with executive attention and the rest never happen.

The customer feels that as a hold. A billing question that depends on a payment processor's ruling stalls because no path exists between the two systems, and a human becomes the transport layer, reading a reference number off one screen and typing it into another.

The tradeoff is genuine. Accepting a standard handshake means accepting a remote agent's latency, its outages, and its definition of a completed task as part of your own resolution time, on cases you can no longer fully debug.

How is A2A Protocol adoption measured?

No conformance score is published for A2A deployments, so measurement falls to the teams running them. The Stanford HAI AI Index is the closest neutral reference, tracking how agent capability and enterprise adoption moved between its 2024 and 2025 editions, and that band is what most buyers use to argue whether their multi-agent plans are early or late.

Inside a deployment, four numbers carry the weight. Handshake success is the share of discovery attempts that end in a usable task. Task completion is the share of delegated tasks reaching a terminal completed state. Cross-agent latency is the wall-clock time each hop adds. Fallback rate is how often a delegated task returns nothing usable and a human absorbs the work.

Read all four together, because a delegation layer can complete tasks reliably and still push resolution time past what a customer will wait through.

How AI agents change support work under A2A

The mechanism comes first. A support agent that can only call its own tools is bounded by whatever its owner integrated last quarter. Under A2A, that same agent can discover a partner's agent at runtime, read its declared skills, and hand off the part of a request it holds no data for: a carrier's shipment agent, a bank's disputes agent, an insurer's claims agent.

The consequence shows up in cases that used to escalate on principle. A refund waiting on a processor's decision stops needing a person to sit between two systems copying identifiers. That is the direction agentic AI support platforms are moving, because resolution increasingly depends on reaching systems the vendor does not own.

The second consequence is governance. Once an outside agent participates in a resolution, someone has to decide what it may see and what it may promise on your behalf.

What to look for in an A2A implementation

Start with lifecycle coverage: ask which states are actually implemented, since happy-path-only builds break the first time a task needs cancellation or an input-required pause. Then the discovery surface: where Agent Cards are hosted, which authentication schemes are honored, and how a trusted agent list is approved and revoked.

Ownership questions follow. Someone has to own the decision to trust a remote agent, and someone has to own the customer promise it makes. Regulated buyers ask how that access is evidenced, which is where SOC 2 Type II reports get requested, and GDPR turns a partner's agent into a named counterparty processing your customers' data. The evaluation habits behind choosing customer service software transfer directly.

The constraint teams miss is skill drift: a remote Agent Card can change without notice, silently retiring a capability your flows depend on.

The A2A Protocol and cross-channel handoff

Delegation raises the same question a live transfer raises. A SIP transfer moves a voice session between endpoints while the caller stays on the line, and an A2A task moves work between agents while the customer stays in one conversation. Both succeed or fail on what travels with the handoff.

What travels is task context and returned artifacts. Internal state and credentials stay home, so AI agent memory remains behind the boundary that owns it, and a partner agent receives what this task needs and nothing accumulated about the customer.

What does the A2A Protocol mean in plain terms?

A2A stands for Agent2Agent, and the full form of the name is the Agent2Agent Protocol. Think of it as a shipping label for software: a standard form on the outside that any carrier can read, while the contents stay sealed and the sender keeps the keys.

Skip it, and every company that wants its agent to work with yours writes a private integration that both sides maintain forever. Ten partners becomes ten integrations, each with its own authentication, its own error formats, and its own on-call rotation when one of them changes.

The tradeoff is control. A standard handshake buys you reach into agents you did not build, and it hands you their downtime, their latency, and their interpretation of what "completed" means. You gain the ability to delegate and you give up the ability to fix the other side yourself.

Common A2A Protocol mistakes

Treating discovery as trust. An Agent Card is a claim about capability, and the protocol verifies none of it. Teams that automatically trust any discovered agent have adopted a supply-chain risk without an approval step.

Implementing only the happy path. Skipping cancellation, input-required, and terminal-state handling means a stalled remote task becomes a silent hang, and the customer waits with no message and no timeout.

Over-sending context. Passing an entire conversation history when the partner agent needs one order number pushes personal data across a boundary you cannot audit, and that data now lives in someone else's logs.

Confusing the protocol with coordination. A2A moves tasks between agents. Deciding which agent gets a task, in what sequence, and what happens when one of them fails remains work your own system has to do.