What Is A2A? The Agent2Agent Communication Standard

// In plain English

An AI agent is a program that uses a language model to take actions toward a goal. The interesting future of agents is not one giant agent that does everything — it is many specialist agents that cooperate: one books travel, one handles your calendar, one files expenses. The catch is that these agents are often built by different companies, on different frameworks, running on different servers. They have no shared way to introduce themselves or hand work back and forth.

A2A, short for Agent2Agent, is an open standard that fixes exactly that. It defines a common language so that an agent built by one vendor can find another agent, ask what it can do, hand it a task, and collect the result — without either team writing custom glue code for that specific pairing.

Think of the international postal system. To mail a package from Japan to Brazil, the two postal services do not sign a private deal. They both follow shared addressing and handoff rules, so any post office can route a parcel to any other. A2A is that shared set of rules for agents: an agent from one platform can deliver a task to an agent on another platform because both speak the same protocol, the same way any web browser can open any website because both ends speak HTTP.

// Why it matters

Without a shared protocol, connecting agents from different vendors is an n-by-n problem. With 5 agents from 5 vendors, you might hand-build and maintain a separate connector for every pair that needs to talk — and each new agent multiplies the work. That is the fragmentation tax: most of your time goes into building adapters instead of building anything useful.

The whole promise of agents is that you assemble specialist capabilities like Lego bricks. But if every brick has a differently shaped connector, they do not actually snap together. A shared standard is what turns a pile of incompatible agents into a composable ecosystem.

What a shared standard buys you

• Vendor portability — swap the helpdesk agent from one provider for another without rewriting the orchestrator that calls it. You depend on the protocol, not on one vendor's API.
• Network effects — any vendor who ships an A2A-compliant agent is instantly compatible with every other compliant agent. The value of the ecosystem grows as more participants join.
• Cross-organization reach — agents at different companies can cooperate over the open web, not just agents inside one codebase.
• Built-in conventions — discovery, authentication, and long-running tasks are part of the spec, so each integration does not reinvent them.

// How it works

A2A runs over ordinary web plumbing — HTTPS — so any service that can serve and call a web endpoint can take part. Conceptually, every interaction follows the same three-beat rhythm: discover who you are talking to, delegate a task to them, then collect the result. A few core ideas make that possible.

The Agent Card: a published identity

Every A2A-compliant agent publishes a small machine-readable document, usually called an Agent Card, at a predictable address on its domain. The card is the agent's public profile: its name, a description, the list of skills it offers, the endpoint that accepts work, and which authentication methods it expects. It is the digital equivalent of a business card stapled to a services brochure — read it and you know what the agent can do and how to reach it.

{
  "name": "Invoice Processing Agent",
  "description": "Validates, categorizes, and routes supplier invoices.",
  "url": "https://finance-agent.example.com/a2a",
  "skills": [
    {
      "id": "validate-invoice",
      "name": "Validate Invoice",
      "description": "Check an invoice for format errors and policy compliance."
    }
  ],
  "authentication": { "schemes": ["Bearer"] }
}

Tasks, messages, and results

Once an agent (the caller, often an orchestrator) has read another agent's card, it sends a task — a single unit of work with its own ID and lifecycle. The two agents then exchange messages within that task: the caller passes instructions or answers follow-up questions, and the remote agent reports progress or asks for clarification. When the work is done, the remote agent returns the result — structured output, a file, or whatever the caller asked for — and the task is marked complete. Because each task has a status you can query, the caller always knows whether work is in progress, waiting on input, finished, or failed.

Long-running work

Real agent tasks can take minutes or hours, not milliseconds — researching a topic, processing a batch, waiting on a human. A2A is built for this. Instead of forcing the caller to hold a connection open and wait, the protocol lets the remote agent stream incremental progress back, or fire a notification to a callback URL when the task finishes. The caller can delegate and walk away, then pick up the result when it is ready.

// A2A vs MCP: tools versus teammates

The most common point of confusion is how A2A relates to the Model Context Protocol (MCP). They sound similar — both are open standards for agents — but they solve different problems at different layers, and most real systems use both.

The cleanest way to remember it: MCP connects one agent to its tools and data; A2A connects one agent to another agent. MCP is vertical — an agent reaching down to a database, an API, or a file system. A2A is horizontal — an agent reaching across to a peer agent, often one built by someone else entirely.

A single workflow uses both. An orchestrator agent might use MCP to call a web-search tool and read a database, then use A2A to hand a specialized sub-task to a partner company's agent — and that partner agent in turn uses its own MCP connections to do the job. The two protocols operate at different altitudes and are designed to coexist, not compete.

// A worked example

Picture an IT help-desk workflow. An employee submits a ticket: "I can't log in." A central orchestrator agent owns the workflow but knows nothing about the underlying systems. Instead, it delegates over A2A to three specialist agents, each living on a different platform:

1. It reads each specialist's Agent Card to learn the agent's skills and endpoint.
2. It hands a task to the ticketing agent ("find this user's open tickets"), an identity agent ("is this account locked?"), and a remediation agent ("reset the credentials").
3. Each remote agent does its job and returns a result. The orchestrator reads those results and replies to the employee.

The orchestrator never needs to understand the internals of the ticketing system, the identity provider, or the remediation tool — it only speaks A2A. Swap the ticketing agent for a different vendor's agent tomorrow, and as long as the new one publishes a compatible Agent Card, the orchestrator keeps working unchanged. This hub-and-spoke shape — one coordinator fanning work out to specialists — is the most common A2A pattern, and it maps directly onto the orchestrator-worker pattern you may already know.

This is why a vendor-neutral standard matters. With A2A, the orchestrator's author and each specialist's author never have to meet, agree on a custom format, or ship coordinated code. They just have to follow the protocol — exactly like the postal services that route your parcel without ever talking to each other.

// Going deeper

The discover-delegate-collect loop is the heart of A2A, but a few design topics matter once you move past the basics.

Trust and security

Because A2A lets agents from different organizations exchange work, trust is central. Transport runs over HTTPS, and an Agent Card declares which authentication schemes (API keys, OAuth, and similar) the remote agent accepts, so the caller proves who it is before any task is accepted. The standard also supports cryptographically signing an Agent Card, so a caller can verify a card genuinely came from the domain it claims and was not swapped by an attacker. For sensitive cross-organization delegation, verifying that signature before sending a task is the safe default.

Cancellation and idempotency

A2A lets a caller cancel an in-flight task, but cancellation means stop further work, not undo work already done. If a remote agent has already written data, canceling will not roll it back. For operations that must run exactly once, use stable task IDs and make the remote agent's handler idempotent — safe to retry without doubling the effect.

Cards can go stale

Agents from different organizations evolve at different speeds. A skill an agent advertised last month may have changed. A common subtle bug is caching an Agent Card forever; the safer habit is to re-read the card before delegating (or on a short refresh interval) so the caller always works from the agent's current capabilities.

Where it sits in the bigger picture

A2A is one piece of an emerging stack of agent standards: MCP connects agents to tools, A2A connects agents to other agents, and newer protocols target the agent-to-app interface. A2A is not the only agent-communication spec — others explore decentralized discovery and different transports — but its neutral Linux Foundation governance and broad industry backing have made it the default choice for cross-vendor agent communication. If you want the canonical details, the official specification is short and readable. From here, a natural next step is understanding the broader picture of multi-agent systems and why they sometimes fail.