Agent-to-Agent Protocol (A2A)

A2A is an open protocol that lets AI agents that are independent of one another — even when built on different frameworks by different companies — discover each other and collaborate directly to complete a task.

What Exactly Is A2A?

Imagine your shopping agent (running, say, on one company's infrastructure) needs to coordinate with a different shipping company's logistics agent to complete an order. These two agents aren't just built on different frameworks — neither has any direct access to the other's code or database at all. A2A is designed for exactly this scenario: a shared language that lets independent agents delegate tasks to each other, without needing to know the internal implementation details of the other side.

Why Do We Need A2A When We Have MCP?

These two protocols standardize two completely different relationships. MCP solves the "agent to tool/data" relationship (an agent connects to a database or an API). A2A solves the "agent to another agent" relationship — meaning the other side is itself an independent decision-maker with its own logic and goals, not a passive tool.

The Agent Card

Every agent that supports A2A publishes a public JSON document called an Agent Card — something like a machine-readable business card. This card includes the agent's name, a description of its capabilities (Skills), its endpoint address, and its authentication requirements. Conceptually, it plays exactly the role that a ucp.json file plays for a store; this time, the "store" is another agent.

Agent Discovery

Before any interaction, the originating agent needs to find out what the destination agent is even capable of. Per the A2A spec, every agent publishes its own Agent Card at a standard, well-known address: /.well-known/agent.json. This means discovering an unknown agent's capabilities is possible with just its domain — no manual documentation or prior coordination between two development teams required.

The Task Lifecycle

The core unit of work in A2A is a Task, which goes through defined stages:

1. submitted — the originating agent sends the task
2. working — the destination agent is processing it (it may send intermediate messages/status)
3. input-required — if more information is needed, it asks the originating agent
4. completed / failed — the task ends with a final result (Artifact) or an error

Messages & Artifacts

Agents communicate during a Task by exchanging Messages (text, a file, or structured data), and the final result is delivered as one or more Artifacts (e.g. a document, an image, or a JSON record).

Streaming Updates & Push Notifications

Many tasks don't finish instantly — "book a shipment" might take several minutes or even hours. A2A has two mechanisms for this:

• Streaming with SSE (Server-Sent Events) — when both agents stay online and connected, the destination agent can stream intermediate Task statuses over an open connection as soon as they're produced.
• Push Notifications (Webhook) — for long-running tasks where keeping a live connection open doesn't make sense, the originating agent provides a webhook address, and the destination agent sends an HTTP request to it whenever the task's status changes (e.g. from working to completed).

The choice between the two depends on whether the two agents can keep an open connection alive for the entire task execution.

A2A vs. MCP

Example: A Simple Agent Card

{
  "name": "LogisticsAgent",
  "description": "Tracking and booking shipments for online stores",
  "url": "https://logistics.example.com/a2a",
  "skills": [
    { "id": "create_shipment", "description": "Register a new shipment" },
    { "id": "track_shipment", "description": "Track shipment status" }
  ],
  "authentication": { "schemes": ["bearer"] }
}

FAQ