A2A Protocol: Google's Agent-to-Agent Standard

Your AI agent can search the web, query databases, and generate reports. It's impressive in isolation. But ask it to coordinate with another team's agent to book a flight, reserve a hotel, and schedule local tours for a customer? That's where things fall apart.

A2A, or Agent-to-Agent protocol, is Google's answer to this coordination problem. Released in April 2025, donated to the Linux Foundation in June 2025, and now backed by over 150 organizations including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow, A2A gives AI agents a standard way to discover each other, exchange messages, and collaborate across organizational boundaries. Think of it as HTTP for the agentic era: a shared protocol that lets agents built by different teams, using different frameworks, running different models, actually work together.

We'll build intuition through a running example: a multi-agent travel booking system where a coordinator agent talks to separate flight, hotel, and activities agents, each owned by a different company.

The Multi-Agent Ceiling

Single-agent systems hit a wall quickly. Consider that travel booking scenario. You could build one monolithic agent that handles flights, hotels, activities, and payments. But that agent needs API keys for every airline, every hotel chain, every tour operator. It needs domain expertise in fare classes, room types, and cancellation policies. It grows into an unmaintainable mess.

Splitting responsibilities across specialized agents is the obvious fix. An airline builds a flight agent. A hotel platform builds a booking agent. A local tours company builds an activities agent. Each team maintains their own agent with their own models, tools, and business logic.

But here's the catch: how do these agents actually talk to each other?

Before A2A, the answer was custom integrations. Every pair of agents needed bespoke glue code. Agent A speaks one format; Agent B speaks another. Authentication is different everywhere. There's no standard way for an agent to say "here's what I can do" or "I need more information before I can finish this task." Fragile, tightly coupled systems broke the moment any team changed their API.

Gartner predicts that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025. A2A solves this interoperability problem. It doesn't replace what agents do internally. It standardizes how they communicate externally.

How A2A Works

A2A follows a client-server model between agents. One agent (the client) sends requests to another agent (the server). Both sides remain opaque to each other, meaning neither agent needs to know the other's internal architecture, which model it uses, or what framework it's built on.

A2A client-server architecture showing coordinator agent communicating with remote server agents

Three boring, battle-tested standards form the foundation:

• HTTPS for secure transport
• JSON-RPC 2.0 for structured request/response messaging
• Server-Sent Events (SSE) for streaming updates

No custom binary formats. No proprietary transports. Any language or framework that can make HTTP requests can speak A2A. Version 0.3.0 added optional gRPC support for higher-performance deployments, and the Python SDK reached v0.3.24 as of February 2026.

In our travel example, the coordinator agent acts as the A2A client. It discovers remote agents, checks their capabilities, and sends tasks. Each service agent (flight, hotel, activities) runs as an A2A server, exposing skills through a standardized interface.

Here's the communication flow:

1. Fetch each remote agent's Agent Card to learn what it can do
2. Create a Task by sending a message via message/send or message/stream
3. Wait while the server agent processes the task, potentially asking for more input
4. Watch as the task reaches a terminal state (completed, failed, or canceled)
5. Collect Artifacts (the actual results) from each task

Every exchange follows JSON-RPC 2.0. A request to book a flight looks something like:

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "id": "req-001",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Find round-trip flights from SFO to NRT, March 15-22, economy class, max budget \$1200"
        }
      ]
    }
  }
}

Agent Cards: Business Cards for AI

Before a client agent can send tasks to a server agent, it needs to know what that agent can do. Agent Cards fill this gap.

An Agent Card is a JSON document hosted at a well-known URL (/.well-known/agent-card.json, updated from agent.json in v0.3.0 based on IANA feedback following RFC 8615). It describes the agent's identity, capabilities, supported input/output types, authentication requirements, and available skills. Think of it as a machine-readable business card.

Here's what the flight agent's Agent Card might look like in our travel system:

{
  "name": "SkyRoute Flight Agent",
  "description": "Searches and books flights across 400+ airlines worldwide",
  "url": "https://api.skyroute.com/a2a",
  "version": "2.1.0",
  "protocolVersions": ["0.3.0"],
  "provider": {
    "organization": "SkyRoute Technologies",
    "url": "https://skyroute.com"
  },
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "authentication": {
    "schemes": ["Bearer"],
    "credentials": "OAuth 2.0 via https://auth.skyroute.com"
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "flight-search",
      "name": "Flight Search",
      "description": "Search available flights by route, date, class, and budget"
    },
    {
      "id": "flight-booking",
      "name": "Flight Booking",
      "description": "Book a selected flight with passenger details"
    }
  ]
}

Notice how the skills array breaks capabilities into distinct units. Your coordinator doesn't need to understand how the flight agent searches fares internally. It just needs to know the agent accepts text or JSON input describing a route and returns structured flight data.

Capabilities tell the client whether the server supports streaming (SSE) and push notifications, which matters for long-running tasks. Searching flights might take seconds, but booking with payment processing could take minutes.

Authentication uses schemes aligned with the OpenAPI specification. Agent Cards can also be digitally signed using JSON Web Signatures (JWS) to verify authenticity, a feature added in v0.3.0 that matters when discovering agents from third parties.

The Task Lifecycle

Every interaction in A2A revolves around Tasks. When the coordinator sends a message to the flight agent, the protocol creates a Task with a unique ID and tracks it through a defined lifecycle.

A2A task lifecycle showing states from submitted through completion or failure

What makes input-required particularly powerful is its support for multi-step workflows. Imagine the coordinator asks the flight agent to book a flight, but the agent needs the passenger's passport number. Instead of failing, it transitions to input-required, sends a message explaining what it needs, and waits. Once the coordinator gathers the information (perhaps by asking the user), it responds and the task moves back to working.

Here's what that exchange looks like:

{
  "jsonrpc": "2.0",
  "id": "req-002",
  "result": {
    "id": "task-flight-42",
    "contextId": "trip-tokyo-2026",
    "status": {
      "state": "input-required",
      "message": {
        "role": "agent",
        "parts": [
          {
            "kind": "text",
            "text": "I found 3 flights matching your criteria. To book, I need: (1) passenger full name as on passport, (2) passport number, (3) date of birth."
          }
        ]
      }
    },
    "kind": "task"
  }
}

Streaming and Artifacts

For tasks that take time, A2A supports streaming via SSE using message/stream. Instead of waiting for the entire response, the client receives incremental updates as TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects.

Artifacts represent concrete task outputs. In our travel example, the flight agent might produce an artifact containing structured JSON with flight options, prices, and booking references. Because artifacts stream incrementally, the coordinator starts receiving flight options as they're found rather than waiting for the full search to finish.

For disconnected scenarios (mobile apps, serverless functions), A2A also supports push notifications. Clients register a webhook URL, and servers send HTTP POST requests whenever the task hits a significant state change.

A2A vs MCP: Complementary, Not Competing

If you've been following the AI tooling space, you've probably encountered MCP (Model Context Protocol). A natural question: does A2A replace MCP?

No. They solve different problems at different layers.

A2A vs MCP showing complementary roles for tool access and agent collaboration

MCP is vertical. It connects an agent to its tools: databases, APIs, file systems, search engines. MCP standardizes tool use and function calling so an agent can work with any MCP-compatible tool server. In December 2025, Anthropic donated MCP to the Linux Foundation's newly formed Agentic AI Foundation (AAIF), co-founded with OpenAI and Block. MCP's Python and TypeScript SDKs have surpassed 97 million monthly downloads.

A2A is horizontal. It connects agents to other agents across organizational boundaries. It's how your agent collaborates with agents it doesn't control, built by teams it's never met, running on infrastructure it can't access.

In our travel system, the coordinator uses MCP internally to access its customer preferences database, call a calendar API, and read travel policy documents. When it needs to search flights, it uses A2A to delegate that task to the external flight agent, which in turn might use MCP to connect to airline GDS systems.

Most production systems will use both. Google has been explicit about this: A2A complements MCP rather than competing with it.

Enterprise Adoption and Governance

A2A has moved fast from proposal to production standard:

• April 2025: Google announces A2A with 50+ initial partners including Atlassian, Langchain, MongoDB, PayPal, Salesforce, SAP, and ServiceNow
• June 2025: Google donates A2A to the Linux Foundation for vendor-neutral governance
• August 2025: IBM's ACP protocol merges into A2A; IBM joins the Technical Steering Committee
• December 2025: Anthropic donates MCP to the newly formed AAIF under the Linux Foundation, with Google, Microsoft, and AWS as platinum members
• Early 2026: Version 0.3.0 ships with gRPC support, signed Agent Cards, and the updated /.well-known/agent-card.json path; partner count passes 150 organizations

Enterprise adoption is already real. Adobe is using A2A to make its distributed agents interoperable with Google Cloud's ecosystem. S&P Global Market Intelligence adopted A2A for inter-agent communication across its data services. Microsoft added A2A support in Azure AI Foundry and Copilot Studio. SAP wired A2A into its AI assistant Joule. System integrators including Accenture, Deloitte, and PwC are building A2A into their enterprise AI practices.

Linux Foundation governance matters for a practical reason: no single company controls the spec. If you're committing your agent architecture to A2A, you're not betting on Google's continued interest. Community consensus drives evolution, and the Apache 2.0 license means you can implement it without licensing concerns.

Building with A2A

Google's Agent Development Kit (ADK) offers the fastest path to A2A. If you already have an ADK agent, wrapping it for A2A is surprisingly straightforward:

from google.adk import Agent
from google.adk.a2a import to_a2a

# Your existing agent
flight_agent = Agent(
    name="SkyRoute Flight Agent",
    model="gemini-2.5-pro",
    instructions="You are a flight search and booking specialist...",
    tools=[search_flights, book_flight, manage_booking]
)

# Expose it as an A2A server
a2a_server = to_a2a(
    agent=flight_agent,
    skills=[
        {
            "id": "flight-search",
            "name": "Flight Search",
            "description": "Search flights by route, date, class, and budget"
        }
    ],
    port=8080
)

a2a_server.start()

Calling to_a2a() handles Agent Card generation, JSON-RPC endpoint setup, task lifecycle management, and SSE streaming. Your agent's internal logic stays untouched.

On the client side, consuming an A2A agent looks like this:

from google.adk.a2a import A2AClient

# Discover the flight agent
client = A2AClient("https://api.skyroute.com/a2a")
card = client.get_agent_card()

print(f"Agent: {card.name}")
print(f"Skills: {[s.name for s in card.skills]}")

# Stream results
for event in client.stream_message(
    message="Find round-trip flights SFO to NRT, March 15-22, economy, max \$1200"
):
    if event.type == "artifact":
        print(f"Found flight: {event.artifact.parts[0].text}")
    elif event.type == "status":
        print(f"Status: {event.status.state}")

You're not locked into ADK, though. A2A is just HTTPS + JSON-RPC. Broad ecosystem support already exists:

• Spring AI released A2A server-side integration via Spring Boot autoconfiguration
• Amazon Bedrock AgentCore Runtime supports A2A natively, with agents built on Strands, LangGraph, or CrewAI all communicating via A2A
• LangChain has A2A endpoint support
• IBM's BeeAI framework uses A2A natively after the ACP merger

Any framework that can serve HTTP can implement A2A from scratch.

Error Handling Between Agents

Cross-agent error handling needs thought. When the flight agent fails, the coordinator needs enough context to decide whether to retry, try a different agent, or inform the user. A2A addresses this through structured error responses where the task transitions to failed with a human-readable message explaining what went wrong. Because failure messages are text (not just error codes), the coordinator can reason about the failure and make intelligent decisions about next steps.

Multi-Agent Travel Booking: Putting It Together

Let's walk through the complete flow of our travel booking system.

Multi-agent travel booking system showing coordinator delegating tasks to specialized agents via A2A

A traveler says: "Plan a 7-day trip to Tokyo, March 15-22. Budget is $3,000 total. I want direct flights if possible, a hotel near Shibuya, and at least two cultural activities."

Step 1: Discovery. Fetch Agent Cards from three registered service URLs. Read each card's skills to confirm the flight agent can search and book, the hotel agent covers Tokyo, and the activities agent lists Japanese cultural experiences.

Step 2: Parallel task dispatch. Create three A2A tasks simultaneously using message/stream so the traveler sees incremental results.

Step 3: Negotiation. Finding three flight options, the flight agent needs to know morning vs. evening departure preference. It transitions to input-required. Meanwhile, hotel and activities agents continue working independently.

Step 4: Aggregation. As artifacts arrive, the coordinator assembles a unified itinerary. Noticing the cheapest hotel sits 40 minutes from the recommended cultural sites, it asks the hotel agent for alternatives closer to Asakusa.

Step 5: Completion. All three tasks reach completed. Combined artifacts show a total cost of $2,847, and the full itinerary is presented to the traveler.

Every agent in this flow is built by a different company, using a different framework, possibly running a different LLM. A2A gives them a shared language.

When to Use A2A

Use A2A when:

• Multiple agents from different teams or organizations need to collaborate
• You want agents to remain opaque (protecting IP, proprietary logic, internal tools)
• Tasks are long-running and require back-and-forth negotiation
• You need a vendor-neutral standard that won't lock you into one framework
• Your architecture requires dynamic agent discovery at runtime

Don't use A2A when:

• All your agents are internal, share the same codebase, and can call each other directly
• You just need tool/function calling within a single agent (use MCP instead)
• Your communication pattern is simple request-response with no state (a REST API is simpler)
• Latency is critical and you can't afford JSON-RPC + task lifecycle overhead
• You're building a prototype and don't need cross-organization interoperability yet

Conclusion

A2A solves a real problem at the right layer. Agents that could only talk to tools through protocols like MCP can now talk to each other. Agent Cards provide discovery. Task lifecycle management handles the messy reality of multi-step, potentially long-running collaboration. And backing from AWS, Google, Microsoft, Salesforce, SAP, and 150+ other organizations under Linux Foundation governance means this isn't going away.

Adoption is accelerating. IBM's ACP merged in. Microsoft wired it into Copilot Studio. Amazon Bedrock AgentCore added native support. With Gartner forecasting 40% of enterprise apps embedding AI agents by end of 2026, the interoperability plumbing A2A provides is becoming infrastructure, not optional.

If you're building AI agents, start with a single agent and MCP for tool access. When you hit the point where agents from different teams need to collaborate, that's when A2A earns its place in your architecture.

Frequently Asked Interview Questions

Q: What problem does A2A solve that existing protocols like REST or gRPC don't?

A2A adds an agent-specific communication layer on top of standard transport protocols. Unlike raw REST, it provides Agent Cards for capability discovery, a stateful task lifecycle with states like input-required for multi-turn negotiation, and streaming via SSE for long-running tasks. REST gives you request-response; A2A gives you structured agent collaboration with built-in state management.

Q: How does A2A handle situations where a server agent needs additional information mid-task?

The server agent transitions the task to input-required and includes a message explaining what it needs. The client receives this update (via polling, SSE, or push notification), gathers the information, and sends a follow-up message that moves the task back to working.

Q: Explain the difference between A2A and MCP. Can they be used together?

MCP connects an agent vertically to its tools and data sources. A2A connects agents horizontally to other agents across organizational boundaries. An agent might use MCP internally to query databases and call APIs, then use A2A externally to delegate subtasks to specialized agents from other teams. Most production multi-agent systems will use both.

Q: What are Agent Cards and why are they important?

Agent Cards are JSON documents hosted at /.well-known/agent-card.json that describe an agent's identity, skills, authentication requirements, and protocol capabilities. They enable dynamic discovery, letting a client agent programmatically find and evaluate server agents without hardcoded integrations. Cards can be digitally signed with JWS for authenticity verification.

Q: How would you design error handling in a multi-agent A2A system?

Start with descriptive failed task states so the coordinator can reason about failures. Add retry logic with exponential backoff for transient errors, maintain a registry of fallback agents per skill, and set task-level timeouts to prevent indefinitely hanging tasks.

Q: What security considerations apply when deploying A2A agents in production?

A2A supports OAuth 2.0, API keys, and OpenID Connect for authentication. Agent Cards can be digitally signed with JWS, and the spec supports W3C DID for identity. Beyond the protocol, plan for rate limiting per client agent, input validation on task messages, audit logging, and network-level controls restricting which agents can communicate.

Q: When would you NOT recommend using A2A?

When all agents belong to the same team and share infrastructure, direct function calls or an internal message queue are faster and simpler. A2A's overhead only pays off when agents cross organizational or trust boundaries. For tool access within a single agent, MCP is the right choice.