Back to writing

Article

What Is the A2A Protocol?

A plain-language walkthrough of Agent2Agent — the open protocol for getting AI agents to talk to each other.

What is A2A?

A2A stands for Agent2Agent. It's a protocol — like HTTP or MCP — but built specifically for communication between AI agents. It's open and vendor-neutral, developed and announced by Google in April 2025, and has since been donated to the Linux Foundation.

What is an agent?

With the massive evolution of AI and machine learning, one term comes up constantly: AI agents. An agent is a software system powered by an LLM (Large Language Model), capable of working toward a specific goal without human intervention. There are plenty of these around today — coding agents, for instance, are built specifically with coding capabilities in mind.

Why is A2A needed?

As mentioned above, AI agents are generally good at specific tasks (some are multi-talented, but let's set those aside for a moment). Broadly, agents fall into two categories:

  1. Single-purpose agents — bound to a specific task
  2. General-purpose agents — multi-tasking capability

Picture an agent working through a task that hits something it can't handle on its own — not capable enough to continue. In that moment, it needs help from another agent that is capable of doing that piece of work. That's exactly where A2A comes in: one agent needs to talk to another agent, and that conversation needs a standard protocol to start and continue. A2A was introduced to make that possible.

How does A2A work?

Consider two agents that need to communicate. The agent that initiates the conversation — the one calling another agent — is referred to as the A2A client, while the agent that receives the request and exposes the APIs to handle it is the A2A server.

A2A communication generally happens by exchanging structured JSON messages over JSON-RPC 2.0 (a simple protocol for making requests between two systems in JSON format), transported securely over HTTPS.

The Agent Card

Every A2A server publishes an Agent Card — like an identity card for the agent. It's a small JSON document containing the necessary identity information and capabilities, including the agent's:

  • Name
  • Description
  • Endpoint URL
  • Authentication schemes it accepts
  • Skills (capabilities)
  • Protocol version, and a few other metadata fields
{
  "name": "Agent Name",
  "description": "Agent description and purpose",
  "version": "1.0.0",
  "url": "/some-endpoint-url",
  "protocolVersion": "0.3.0",
  "preferredTransport": "JSONRPC",
  "capabilities": {
    "streaming": true
  },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text"],
  "skills": [
    {
      "id": "skill-id",
      "name": "Skill Name",
      "description": "Skill description and capabilities",
      "tags": []
    }
  ]
}

Starting a task

The A2A client discovers a server through its published Agent Card. Once the client has discovered and resolved the server, it initiates the relevant task by sending a message as a JSON-RPC 2.0 request: 

{
  "message": {
    "role": "user",
    "parts": [
      { "kind": "text", "text": "How to develop an AI Agent?" }
    ]
  }
}

The A2A server then creates a task with a unique task ID, the skill ID needed to handle it, the input payload — text, structured JSON, files, or images — and any other metadata from the client's request. The server then hands the task over to the agent capable of doing that work.

The task state machine

Every A2A server follows the same state machine to move a task through to completion:

submitted → working → input-required → completed | failed | canceled

Once the server hands the task to an agent, the state moves to submitted and then working. If the agent accepts the task but hasn't started yet, it stays in submitted until work actually begins. If the agent needs more details partway through to complete the task, it asks the necessary questions and the state moves to input-required.

How does the server send responses?

There are a few ways a server can respond to a task:

  1. Synchronous
  2. Streaming — SSE (Server-Sent Events)
  3. Callback URL

These must be declared as agent capabilities in the Agent Card, and a client should read them before initiating a task so it knows what response mechanism to prepare for.

Wrapping up

So, that's how the Agent2Agent protocol works, at a high level. I hope this gave you a useful perspective and something to think about — the references below are worth a look if you want to go deeper.

References