What Is the A2A Protocol

The Agent2Agent (A2A) Protocol is an open standard for communication between AI agents. Whichever framework or vendor built them, agents that implement A2A can discover each other, delegate tasks, and exchange results without exposing their internals.

Why A2A

Consider a user who asks an AI assistant to plan an international trip. The task needs several specialized agents:

• A flight booking agent
• A hotel reservation agent
• A local tour recommendation agent
• A currency conversion agent

Without a shared protocol, integrating these agents runs into familiar problems:

• Agents forced to act as tools: A common workaround is wrapping each agent as a tool, the way MCP exposes tools. But agents are built to negotiate directly, and wrapping them limits what they can do. A2A exposes agents as they are, with no wrapping.
• Custom point-to-point integrations: Every pair of agents needs its own bespoke connection, creating heavy engineering overhead.
• Slower innovation: Each new integration requires new development.
• Hard to scale and maintain: Complexity grows quickly with the number of agents and interactions.
• Security gaps: Ad hoc communication rarely comes with consistent security measures.

Example scenario

A user asks an AI assistant to “plan an international trip”. The assistant realizes it must call several specialized agents. If those agents were developed and deployed independently, they cannot collaborate, or even discover what the others can do.

With A2A, the agents talk to each other through shared methods and data structures. The assistant becomes an orchestrator: it gathers results from each A2A-enabled agent and presents one complete travel plan.

  graph LR
    User[User] --> Assistant[AI Assistant<br/>A2A Client]
    Assistant -->|A2A| F[Flight Booking Agent]
    Assistant -->|A2A| H[Hotel Reservation Agent]
    Assistant -->|A2A| C[Currency Conversion Agent]
    Assistant -->|A2A| T[Local Tours Agent]

Core benefits

• Secure collaboration: Communication runs over HTTPS and execution stays opaque, so collaborating agents cannot see each other’s inner workings.
• Interoperability: Breaks down silos between agent ecosystems built by different vendors and frameworks.
• Agent autonomy: Agents keep their own capabilities and autonomy while collaborating.
• No custom integrations: One protocol reaches agents on your machine, in the cloud, or hosted by a vendor, across teams, projects, and companies.
• Long-running operations: Streaming with Server-Sent Events (SSE) and asynchronous execution are built in.

Design principles

Where A2A fits in the agent stack

A complete agent system typically combines four kinds of building blocks:

• A2A: standardizes communication among agents, across organizations and frameworks.
• MCP: connects models to data and external resources.
• Agent frameworks (for example LangGraph, CrewAI, ADK): toolkits for building agents.
• Models: the foundation of an agent’s reasoning, any large language model.

Each layer answers a different question: a framework builds the agent, MCP gives it context, a runtime hosts it, and A2A connects it to other agents.

A2A and MCP

MCP reduces the complexity of connecting agents to tools and data. Tools are typically stateless and perform specific, predefined functions (a calculator, a database query). A2A lets agents collaborate as agents (or as users) rather than through tool-like calls, supporting multi-turn interaction where agents reason, plan, delegate, negotiate, or ask for clarification.

A2A crosses the boundary between agents; MCP stays within one agent, connecting it to APIs and enterprise applications. For a deeper comparison, see A2A and MCP .

A2A and agent frameworks

A2A is a communication protocol and does not depend on how an agent is built. LangGraph, CrewAI, ADK, or a custom stack: any agent that implements A2A can work with any other. The protocol neither depends on nor favors a single framework.

Lifecycle of a request

A typical A2A request spans three stages: agent discovery, authentication, and the messaging APIs (SendMessage and SendStreamingMessage).

1. Agent discovery: The client fetches the server’s Agent Card to learn its capabilities and endpoint.

  sequenceDiagram
    participant Client
    participant Server as A2A Server
    Client->>Server: GET /.well-known/agent-card.json
    Server-->>Client: Returns Agent Card

2. Authentication: The client reads the security schemes declared in the Agent Card and obtains a token first when one is required.

  sequenceDiagram
    participant Client
    participant Auth as Auth Server
    Client->>Client: Parse securitySchemes from the Agent Card
    alt securityScheme is openIdConnect
        Client->>Auth: Request a token using the declared auth details
        Auth-->>Client: Returns JWT
    end

3. Sending messages: The client selects an interface from the Agent Card’s supportedInterfaces, then sends a message with SendMessage (single request/response) or SendStreamingMessage (a stream of task updates).

  sequenceDiagram
    participant Client
    participant Server as A2A Server
    Client->>Client: Select an interface from supportedInterfaces
    Client->>Server: SendMessage (with token)
    Server-->>Client: Returns Task or Message
    Client->>Server: SendStreamingMessage (with token)
    Server-->>Client: Task (submitted)
    Server-->>Client: TaskStatusUpdateEvent (working)
    Server-->>Client: TaskArtifactUpdateEvent (artifact)
    Server-->>Client: TaskStatusUpdateEvent (completed)

With the HTTP+JSON binding these two operations map to POST /message:send and POST /message:stream; see the specification for details.

What’s next

• Want the overall picture, including the background, participants, and the three protocol bindings: read the introduction .
• Prefer a hands-on approach: build your first agent with the Python tutorial .
• Want the foundations: read the key concepts .
• Want to go deep: the specification is the source of truth for every capability, method, and data structure.

Source: Official A2A documentation