Agent-to-Agent Protocol (A2A)

Overview

The Agent-to-Agent (A2A) protocol is an open communication standard developed by Google and over 50 technology partners, launched in April 2025. It enables AI agents built on different frameworks by different vendors to discover each other, communicate, and collaborate on complex tasks—treating each other as autonomous peers rather than simple tools to invoke.

Before A2A, multi-agent systems were largely proprietary. If you built agents with one framework (say LangChain) and needed them to collaborate with agents built on another (say Google ADK or Microsoft AutoGen), you had to write custom integration code. A2A eliminates this fragmentation by defining a standard protocol for agent-to-agent communication, much like HTTP standardized web communication.

The protocol is open-sourced under the Apache 2.0 license and governed by the Linux Foundation. As of mid-2025, version 0.3 added gRPC support, signed security cards, and an extended Python SDK, with over 150 organizations now supporting the standard.

How It Works

Client-Server Architecture

A2A uses a client-server model. An A2A Client is any agent that wants to delegate work. An A2A Server is an agent that advertises capabilities and processes requests. The same agent can act as both client and server depending on the interaction.

The flow is straightforward: the client discovers available servers by reading their Agent Cards, selects the right agent for a subtask, sends a message, and receives results back as the server processes the task.

Core Protocol Objects

The A2A specification defines several core objects that structure all interactions:

• Agent Card — A JSON metadata document describing an agent’s identity, capabilities, skills, endpoint URL, and authentication requirements. Hosted at /.well-known/agent-card.json.
• Task — The fundamental unit of work, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle: submitted → working → completed (or failed, canceled, rejected). A task can also enter input-required when the server needs more information.
• Message — A single communication turn between client and server, containing a role ("user" or "agent") and one or more Parts.
• Artifact — An output deliverable produced by the server agent (e.g., a generated document, image, or structured data), identified by a unique artifactId and composed of Parts.
• Part — The smallest content unit. Three types: TextPart (plain text), FilePart (inline base64 or URI reference), and DataPart (structured JSON).

Task Lifecycle

When a client sends a message to a server, the server creates a Task and begins processing. The task lifecycle supports both synchronous and asynchronous patterns:

1. Client sends initial message → Task enters submitted state
2. Server begins processing → Task moves to working
3. Server may request more input → Task enters input-required
4. Client provides additional context → Task returns to working
5. Server produces results → Task reaches completed with Artifacts

For long-running tasks, the protocol supports Server-Sent Events (SSE) streaming and push notifications, so clients don’t need to poll for status updates.

Communication Methods

A2A supports multiple transport mechanisms:

• HTTP + JSON-RPC — The default transport. Clients send JSON-RPC requests to the server’s endpoint URL.
• Server-Sent Events (SSE) — For streaming responses. The server sends incremental TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects as the task progresses.
• gRPC — Added in v0.3 for high-throughput, low-latency scenarios. Uses Protocol Buffers for efficient binary serialization.
• Push Notifications — The server can push updates to a client-specified webhook URL for fire-and-forget patterns.

Example: Sending a Task

Here’s a simplified example of a client sending a task to a remote agent:

// JSON-RPC request to create/send a task
{
  "jsonrpc": "2.0",
  "method": "tasks/send",
  "id": "req-001",
  "params": {
    "id": "task-abc-123",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Analyze Q4 sales data and generate a summary report"
        }
      ]
    }
  }
}

// Server response
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "id": "task-abc-123",
    "status": {
      "state": "completed"
    },
    "artifacts": [
      {
        "artifactId": "report-001",
        "name": "Q4 Sales Summary",
        "parts": [
          {
            "type": "text",
            "text": "Q4 revenue increased 18% YoY..."
          }
        ]
      }
    ]
  }
}

Practical Applications

Enterprise Workflow Orchestration

In a large organization, different departments may deploy specialized agents—an HR agent, a finance agent, an IT provisioning agent. When an employee onboarding request arrives, an orchestrator agent uses A2A to delegate subtasks: the HR agent creates the employee record, the IT agent provisions accounts and hardware, and the finance agent sets up payroll. Each agent is built and maintained by its respective team, but A2A enables seamless coordination.

Supply Chain Coordination

A supply chain system might feature a root orchestration agent with specialized sub-agents for tracking, distribution, and order management. A user query like “show me inventory levels for product X” gets routed by the root agent to the order agent via A2A, which queries its backend systems and returns structured inventory data as an Artifact.

Cross-Vendor Agent Marketplaces

A2A’s vendor-agnostic design enables agent marketplaces where organizations can publish specialized agents (e.g., a compliance-checking agent, a translation agent) that any A2A-compatible client can discover and use. The Agent Card system makes this practical—clients search a registry for agents with specific skills and invoke them without knowing their implementation details.

Customer Service Escalation

A front-line customer service agent handles basic queries but uses A2A to escalate complex issues to a specialized billing agent, a technical support agent, or a returns processing agent. The input-required task state allows these specialist agents to request additional information from the customer through the front-line agent, maintaining a natural conversation flow.

Key Takeaways

• A2A is an open protocol (Apache 2.0, Linux Foundation) that standardizes how AI agents discover, communicate, and collaborate across frameworks and vendors.
• It uses a client-server architecture where agents publish Agent Cards describing their capabilities, and clients delegate Tasks through structured messages.
• Tasks are stateful with a defined lifecycle (submitted → working → completed/failed) and support long-running asynchronous workflows via SSE streaming and push notifications.
• Content is exchanged through typed Parts (text, file, structured data) within Messages and Artifacts, keeping communication flexible yet structured.
• A2A treats agents as opaque—the client doesn’t need to know the server’s internal architecture, model, or framework, enabling true vendor-agnostic interoperability.
• Transport options include HTTP/JSON-RPC (default), SSE (streaming), gRPC (high-throughput), and push notifications (webhooks).
• The protocol complements MCP (Model Context Protocol)—MCP handles agent-to-tool communication, while A2A handles agent-to-agent collaboration.