A2A Protocol v1 2026: How AI Agents Actually Talk to Each Other

Two AI agents exchanging structured messages via Agent Cards with peer-to-peer communication paths and task lifecycle states flowing between them, Google blue and green on dark background

Unlock the secret to seamless AI teamwork: discover how the A2A Protocol lets agents talk, collaborate, and scale like never before.

Summary: Learn about the A2A Protocol, the open standard for how AI agents communicate. See how Agent Cards, tasks, and streaming enable complex multi-agent systems.

Two AI agents coordinate via the A2A Protocol: exchanging structured messages, advertising capabilities through Agent Cards, and tracking task lifecycle states across a multi-agent workflow.

The Multi-Agent Communication Problem A2A Solves

Individual excellence, collective silence. That is the state of most AI agent deployments today. A shipping agent cannot ask an inventory agent a question. A customer support agent has no way to hand work to a returns agent mid-conversation. Agents have gotten remarkably good at their jobs. The problem is that each one is still doing that job alone. That is the multi-agent communication problem the A2A Protocol was built to solve.

Through most of 2025, every agent framework invented its own answer. LangChain did it one way. CrewAI did it another. AutoGen had its own approach, now unified into Microsoft Agent Framework 1.0 (released April 3, 2026), which places AutoGen in maintenance mode in favor of the unified SDK. Wanting agents from different frameworks to collaborate meant writing custom glue code. Lots of it.

Google's Agent-to-Agent Protocol (A2A) changed this. Announced on April 9, 2025, at Google Cloud Next [15] and contributed to the Linux Foundation on June 23, 2025 [14][13], A2A grew from a specification draft to a production protocol backed by over 150 organizations [12]. As of early 2026, it is version 1.0 [1] and has become the leading standard for how AI agents discover, communicate with, and delegate work to each other.

What Is the A2A Protocol?

A2A is an open protocol that defines how AI agents communicate. Think of it as HTTP for agents. Just as HTTP gave us a standard way for web clients and servers to exchange data regardless of what language they were written in, A2A gives agents a standard way to find each other, describe their capabilities, exchange messages, and collaborate on tasks.

The protocol is built on JSON-RPC 2.0 over HTTP [2]. No exotic transport layers. No proprietary protocols. If your service can handle HTTP requests, it can speak A2A.

A2A Protocol vs MCP: Clearing Up the Most Common Confusion

What trips people up most in multi-agent architecture? Conflating A2A with MCP. These are not competing standards. They solve different problems at different layers, and getting this wrong leads you to design systems around the wrong abstraction.

MCP (Model Context Protocol) was donated by Anthropic to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, on December 9, 2025 [22].

MCP connects an agent to its tools. Think of MCP as the interface an agent uses to grab a hammer, read a file, query a database, or call an external API. It is the vertical interface between an agent and the resources that agent controls.

A2A connects agents to other agents. Think of A2A as the interface agents use to coordinate with peers, delegate subtasks, and share results. It is the horizontal interface between independent collaborators.

The official A2A documentation puts it plainly: "A2A is about agents partnering on tasks, while MCP is more about agents using capabilities." [3] The original Google announcement echoes this: "A2A is an open protocol that complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents." [15]

The distinction matters because these two problems have fundamentally different shapes:

Purpose: MCP handles agent-to-tool communication. A2A handles agent-to-agent communication.
Relationship: MCP is hierarchical -- the agent controls its tools. A2A is peer-to-peer -- agents collaborate as equals.
Discovery: MCP uses tool manifests and schemas. A2A uses Agent Cards.
State: MCP calls are stateless. A2A tasks carry a full lifecycle.
Communication: MCP is request-response only. A2A adds streaming and multi-turn patterns.
Typical use: MCP is "call this API" or "read this file." A2A is "analyze this data and report back."
Scope: MCP operates within a single agent's context. A2A crosses agent boundaries.

AI Agents communication layers: MCP as vertical agent-to-tool hierarchy vs A2A as horizontal peer-to-peer agent collaboration

How MCP and A2A Work Together

Here is a concrete example. An orchestrator agent receives a customer request. It uses A2A to discover a shipping agent and delegate a routing subtask. The shipping agent uses MCP to connect to a carrier API (FedEx, UPS), a database of shipping rates, and a geocoding service. The shipping agent does its work, then responds to the orchestrator via A2A with the results.

The orchestrator never needs to know about FedEx APIs. The shipping agent never needs to know about the customer's account details. Each agent has its own tools (via MCP) and communicates results through the shared protocol (via A2A).

When to Use A2A vs MCP

This separation is powerful. You can swap out the shipping agent's internal tools without changing the A2A interface. You can replace the entire shipping agent with a different implementation, as long as it speaks A2A and advertises the same capabilities in its Agent Card. MCP governs the internal wiring. A2A governs the external collaboration.

A2A Protocol Core Concepts: Five Building Blocks for Multi-Agent Communication

Five building blocks power the A2A Protocol: Agent Cards, Tasks, Messages, Artifacts, and Streaming. Together they solve every coordination problem that surfaces when independent agents need to work together -- discovery, delegation, progress tracking, multi-turn conversation, and incremental result delivery. Each one earns its place.

Agent Cards: How A2A Agents Discover Each Other

Before agents can talk, they need to find each other and understand what the other agent can do. Agent Cards solve this. They are JSON documents that describe an agent's capabilities, endpoints, authentication requirements, and supported interaction patterns. [4]

Think of an Agent Card as a business card; except it encodes capabilities in machine-readable form. It tells other agents: here is who I am, here is what I can do, here is how to reach me, and here is how to authenticate.

{
  "name": "Shipping Logistics Agent",
  "description": "Handles package routing, delivery scheduling, and carrier selection",
  "url": "https://logistics.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "route-package",
      "name": "Route Package",
      "description": "Determines optimal shipping route and carrier",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    },
    {
      "id": "track-shipment",
      "name": "Track Shipment",
      "description": "Real-time tracking for active shipments",
      "inputModes": ["text"],
      "outputModes": ["text"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

Agent Cards live at /.well-known/agent-card.json, following the well-known URI convention defined in RFC 8615. [21][4] A client agent fetches the card, understands what the remote agent can do, and decides whether to engage. As of v1.0, Agent Cards can be cryptographically signed using JSON Web Signature (JWS, RFC 7515), so clients can verify card authenticity and integrity [9]: preventing impersonation in open marketplace scenarios.

What It Does: Provides a self-describing manifest that any agent can fetch to understand another agent's capabilities without prior knowledge. [4]

Why This Approach: The alternative is hard-coded knowledge of what every agent can do. That breaks immediately when you add a new agent, update an existing one, or want to use agents from outside your organization. Agent Cards make capability discovery dynamic and standardized.

When to Use: Any agent that accepts requests from other agents should publish an Agent Card. In multi-agent orchestration and marketplace scenarios, Agent Cards are how orchestrators and platforms discover what your agent offers.

Trade-offs:

Pro: Any agent anywhere can discover your agent's capabilities programmatically
Pro: Capability changes are reflected immediately without requiring coordination
Con: Agents must check the card before they can interact, adding one round-trip to initial contact
Con: The card describes what an agent can do, not whether it is currently healthy or under load

A2A Tasks: The Stateful Unit of Agent Coordination

When one agent wants another agent to do something, it creates a Task. Tasks are the central coordination mechanism in the A2A Protocol. [6] Each task has a unique ID, a lifecycle, and a well-defined state machine.

A task moves through these states [2]:

submitted (TASK_STATE_SUBMITTED): The remote agent acknowledged the request and queued it
working (TASK_STATE_WORKING): The agent is actively processing
input-required (TASK_STATE_INPUT_REQUIRED): The agent needs more information from the client to proceed
auth-required (TASK_STATE_AUTH_REQUIRED): The agent requires authentication to continue
completed (TASK_STATE_COMPLETED): Done, results available
failed (TASK_STATE_FAILED): Something went wrong
canceled (TASK_STATE_CANCELED): The task was canceled before completion
rejected (TASK_STATE_REJECTED): The agent declined to perform the task (terminal state, distinct from failed)
unspecified (TASK_STATE_UNSPECIFIED): Indeterminate or unknown state; the proto default/zero value

v1.0 note: State enum values changed from lowercase hyphenated (submitted, input-required) to TASK_STATE_ prefixed SCREAMING_SNAKE_CASE in v1.0. If you are migrating from v0.x, update your state comparisons accordingly.

Agentic AI task lifecycle: A2A state machine transitions from submitted through working to completed, failed, canceled, and rejected

Here is what task creation looks like over the wire:

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Route package PKG-7829 from warehouse Austin to customer in Portland, OR. Priority: next-day."
        }
      ]
    },
    "metadata": {
      "contextId": "order-ctx-4521"
    }
  }
}

v1.0 note: message/send is the pre-v1.0 JSON-RPC method name. The v1.0 canonical proto RPC name is SendMessage (unary) or SendStreamingMessage (streaming). If your implementation targets v1.0, use SendMessage instead of message/send.

The remote agent responds with a task object:

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "kind": "task",
    "id": "task-a3f8b721",
    "contextId": "order-ctx-4521",
    "status": {
      "state": "submitted",
      "message": {
        "role": "agent",
        "parts": [
          {
            "kind": "text",
            "text": "Task received. Evaluating carrier options for Austin to Portland next-day delivery."
          }
        ]
      }
    }
  }
}

The task model supports both quick request-response patterns and long-running workflows. A simple lookup completes immediately. A complex multi-step analysis takes minutes, with the client checking in periodically or subscribing to streaming updates.

Why stateful tasks matter: Contrast this with a plain HTTP request-response call. If you delegate a complex task to another agent via a REST API, you have no standard way to check progress, handle partial results, or recover when the connection drops. The A2A task lifecycle gives you all of that, built into the protocol. [6]

Messages: How A2A Agents Exchange Multimodal Content

Messages carry the actual content between agents. [5] Each message has a role (user or agent) and contains an array of parts. Parts can be:

Text (text): Plain text content
File -- raw (raw): Binary file bytes, base64-encoded in JSON (for inline binary payloads such as log dumps or images)
File -- url (url): External URI reference to file content (for large files stored externally)
Data (data): Structured JSON for machine-readable information

v1.0 note: The three separate part types (TextPart, FilePart, DataPart) were merged into a single Part message with a oneof discriminator. There is no single "file" kind; file content is either raw (inline binary) or url (external reference). Also, mimeType was renamed to mediaType in v1.0.

This multimodal design means agents can exchange text instructions alongside log files, images, or structured data in a single message. [5] A support agent can send a customer complaint (text), relevant server logs (file), and account metadata (data) to a diagnostics agent as a single coordinated message.

Messages are linked by contextId, which groups related messages into a conversation thread. [5] The contextId is a server-generated identifier that logically groups multiple related Task objects, providing context across a series of interactions. This lets agents maintain context across multi-turn workflows.

Artifacts: Streamed Deliverables in A2A

Artifacts are the results. When an agent completes work, the outputs come back as artifacts. An artifact can be a generated report, a set of shipping labels, a JSON payload with routing decisions, or a PDF invoice.

Artifacts stream incrementally using TaskArtifactUpdateEvent [7], with fields like artifactId, append (for chunked delivery), and lastChunk (signals completion):

{
  "kind": "artifact",
  "artifactId": "route-result-001",
  "parts": [
    {
      "kind": "data",
      "data": {
        "carrier": "FedEx",
        "service": "Priority Overnight",
        "estimatedDelivery": "2026-03-26T14:00:00Z",
        "cost": 47.50,
        "trackingNumber": "FX-9283746501"
      }
    }
  ],
  "lastChunk": true
}

You do not wait for a 50-page report to finish generating before you start receiving it. Artifacts arrive as they are produced. For large outputs, this matters.

SSE Streaming: Real-Time Visibility into Agent-to-Agent Delegation

For long-running tasks, the A2A Protocol supports Server-Sent Events (SSE). [10] The client sends a message and subscribes to a stream of updates. In v1.0, the canonical RPC method for combined send-and-subscribe is SendStreamingMessage (the pre-v1.0 JSON-RPC name was message/stream).

Two event types flow over the stream:

TaskStatusUpdateEvent: State transitions and progress messages [7]
TaskArtifactUpdateEvent: Intermediate and final results streamed as they become available [7]

Each SSE data field contains a JSON-RPC 2.0 object. [10] If a client's SSE connection breaks while a task is still active, it can reconnect using the SubscribeToTask method. [7] Clients can also poll using GetTask (v1.0 canonical name; pre-v1.0 alias: tasks/get) if SSE is not practical for their infrastructure.

This streaming model is critical for agent-to-agent workflows. When an orchestrator delegates to a specialist, it needs visibility: Is the specialist stuck? Does it need input? Is it almost done? SSE provides that transparency without hammering the server with poll requests.

A2A in Practice: Architecture Patterns

Four A2A architecture patterns cover most real-world deployments. Understanding which pattern fits your use case shapes how you implement agent discovery, task delegation, and cross-system integration.

Pattern 1: Hub-and-Spoke Agent Orchestration

The most common pattern. A central orchestrator agent receives requests and delegates to specialist agents:

Customer asks: "I need to return item X and get a replacement shipped"
Orchestrator decomposes the request into subtasks
Sends a return-processing task to the Returns Agent (via A2A)
Sends a replacement-shipping task to the Shipping Agent (via A2A)
Aggregates results and responds to the customer

The orchestrator never needs to know the implementation details of either specialist. It knows only what each agent's Agent Card says it can do.

AI Agents hub-and-spoke orchestration: central AI orchestrator delegating via A2A to specialist agents, each connected to tools via MCP

Pattern 2: Agent Marketplace Discovery

Agent Cards enable standardized discovery, which is what makes agent marketplaces possible. Organizations can publish agents to a marketplace, and other organizations can discover and integrate them programmatically before committing to use them. The Agent Card format lets you evaluate an agent's capabilities (what it does, what it needs for auth, what output formats it produces) without writing a line of integration code.

Google pioneered this pattern with Agentspace (launched December 2024 [16]), which was rebranded Gemini Enterprise in late 2025 and consolidated into the Gemini Enterprise Agent Platform (GA April 22, 2026) [18]. The agent marketplace model it established remains a core A2A pattern.

Pattern 3: Cross-Organization Collaboration

A2A's authentication support and well-defined boundaries make it well-suited for cross-organization agent communication. A retailer's order management agent can talk to a supplier's inventory agent, each running in separate environments with separate security contexts.

The JSON-RPC over HTTP foundation means standard API gateway patterns apply. Rate limiting, authentication, logging, and monitoring all work the same way they do for REST APIs. [2] Your ops team does not need a new runbook.

Pattern 4: Hybrid MCP + A2A Agents

The most sophisticated pattern: agents that expose both MCP and A2A interfaces. As an MCP server, the agent appears as a tool that other agents can call directly. As an A2A server, the same agent participates in multi-agent workflows with full task lifecycle management.

This dual-interface approach lets the agent serve both simple tool-call scenarios (via MCP) and complex collaborative workflows (via A2A) without duplicating internal logic.

Orchestrator Agent
     /     \
  (A2A)   (A2A)
   /         \
Shipping    Analysis
  Agent       Agent
  /   \          |
(MCP)(MCP)     (MCP)
/     \           |
FedEx  Rate DB  Data Warehouse
 API

The shipping agent uses MCP for its tools and A2A to participate in orchestration. These protocols do not compete. They operate at different layers.

Getting Started with the A2A Protocol

1. Define Your Agent Card

Create a JSON file describing your agent's capabilities and host it at /.well-known/agent-card.json [4]. This path follows RFC 8615 for well-known URIs. Every other agent that wants to work with yours will fetch this endpoint first.

2. Implement the JSON-RPC Methods

At minimum, you need [2]:

message/send (SendMessage in v1.0): Accept incoming messages and create tasks
tasks/get (GetTask in v1.0): Return task status and results

For streaming support, add:

message/stream (SendStreamingMessage in v1.0): Accept messages and return an SSE stream

3. Implement with the A2A Python SDK

Here is where it gets concrete. The A2A Python SDK (a2a-sdk v1.0.x, with v1.0.0 released April 20, 2026) [26] provides both client and server implementations. Install it with:

pip install a2a-sdk

The SDK implements Protocol Specification 1.0 with compatibility mode for 0.3 [11].

The server assembles three components: an AgentExecutor you implement, a DefaultRequestHandler that wires it to the protocol layer, and A2AFastAPIApplication that exposes it over HTTP [25]:

import uvicorn
from a2a.server.apps.jsonrpc import A2AFastAPIApplication
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.server.tasks import InMemoryTaskStore, TaskUpdater
from a2a.types import (
    AgentCard,
    AgentCapabilities,
    AgentSkill,
    Part,
    TextPart,
)

class AnalysisAgentExecutor(AgentExecutor):
    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        updater = TaskUpdater(event_queue, context.task_id, context.context_id)
        await updater.start_work()
        result = await analyze_data(context.get_user_input())
        await updater.add_artifact(parts=[Part(root=TextPart(text=result))])
        await updater.complete()

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
        updater = TaskUpdater(event_queue, context.task_id, context.context_id)
        await updater.cancel()

card = AgentCard(
    name="My Analysis Agent",
    description="Analyzes data and generates reports",
    url="https://my-agent.example.com",
    version="1.0.0",
    capabilities=AgentCapabilities(streaming=True),
    default_input_modes=["text/plain"],
    default_output_modes=["text/plain"],
    skills=[
        AgentSkill(
            id="analyze",
            name="Data Analysis",
            description="Analyzes datasets and produces insights",
            tags=["analysis", "data"],
        )
    ],
)

request_handler = DefaultRequestHandler(
    agent_executor=AnalysisAgentExecutor(),
    task_store=InMemoryTaskStore(),
)

app = A2AFastAPIApplication(agent_card=card, http_handler=request_handler).build()

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8080)

On the client side, ClientFactory.create_from_url() resolves the remote agent's card automatically and returns a typed connection [25]:

from a2a.client import ClientFactory, ClientConfig
from a2a.types import Message, Part, TextPart, Role

client = await ClientFactory.create_from_url(
    "https://my-agent.example.com",
)

async with client:
    message = Message(
        role=Role.user,
        parts=[Part(root=TextPart(text="Analyze Q1 2026 sales data for anomalies"))],
    )
    # Stream updates as they arrive
    async for event in client.send_message(message):
        if isinstance(event, tuple):
            task, update = event
            print(f"Status: {task.status.state}")
        else:
            print(f"Result: {event}")

SDK note: A2AClient is deprecated in a2a-sdk 1.0.x. Use ClientFactory.create_from_url(url) as shown above. The send_message method signature varies by client class; consult the current API docs at a2a-protocol.org/latest/sdk/python/api/a2a.client.html [25]. If your client expects a SendMessageRequest, wrap your message: SendMessageRequest(message=message).

4. Test with the A2A Inspector

The A2A Inspector [27] (an official tool from the A2A project maintainers) validates your implementation against the spec in real time. Run it against your endpoint to catch compliance issues before going live. The Technology Compatibility Kit (TCK) [28] provides a fuller suite of conformance tests organized across four compliance tiers for production readiness verification.

A2A Protocol Security: Authentication, Signing, and Transport

The A2A Protocol was designed for real-world deployment from the start. Security is not an afterthought.

Authentication Schemes: Agent Cards declare supported authentication methods (bearer tokens, OAuth 2.0, API keys). [2] Clients authenticate before sending messages. This maps to the standard API security patterns that operations teams already know. The spec's supported scheme types cover what most teams need: apiKey, http (Bearer), oauth2, openIdConnect, and mtls are all supported.

Agent Card Signing: Version 0.3 introduced cryptographic signing of Agent Cards, and Version 1.0 formalized it using JSON Web Signature (JWS, RFC 7515) with JSON Canonicalization Scheme (JCS, RFC 8785). In marketplace scenarios, this matters: without signing, a malicious actor could publish a fake Agent Card impersonating a trusted agent.

Context Isolation: Each task operates within a context boundary. A shipping agent processing a task does not automatically get access to the orchestrator's internal state or other tasks. You control what information flows across agent boundaries through the message and artifact model.

Transport Security: A2A runs over HTTPS in production. The spec mandates TLS 1.2 or higher, recommends TLS 1.3+, and specifies HSTS headers. v1.0 also formalized mutual TLS (mTLS) as a supported security scheme. Combined with authentication, agent-to-agent communication gets the same security guarantees as any REST API call. Existing infrastructure (API gateways, WAFs, rate limiters) works without modification.

Authorization Patterns: A2A defines authentication at the protocol level. Authorization (which agents can access which skills) is left to implementation. Most production deployments layer OAuth scopes or custom RBAC on top of A2A's auth mechanisms.

The A2A security model does not reinvent the wheel. It builds on the same HTTP security patterns that the industry has spent 20 years hardening. Your existing API gateway infrastructure, WAF rules, and rate-limiting policies transfer directly to A2A deployments. Operations teams do not need to learn a new security model. That was the right call.

What makes this model production-viable is how the layers compound. Each one adds a distinct control surface, so a production team can plug A2A into existing API gateway policies, WAF rules, and RBAC without rebuilding a security model from scratch. The five layers together mean you get defense-in-depth across the full agent interaction lifecycle:

Authentication declared in Agent Cards (bearer, OAuth 2.0, API keys)
Agent Card signing (introduced v0.3, formalized v1.0) prevents impersonation in open marketplaces
Per-task context isolation keeps agent state boundaries clean
HTTPS transport reuses existing WAF and rate-limiter infrastructure
Implementation-level authorization via OAuth scopes or RBAC layered on top

Real-World A2A Protocol Integration Patterns

Enterprise Service Mesh Integration with A2A

Large enterprises with existing SOA or microservices architectures treat A2A agents as another type of service on their internal network. Agent Cards get registered in service discovery systems (Consul, Eureka, or DNS-based discovery). The orchestrator agent queries the registry, fetches Agent Cards, and delegates work the same way a microservice calls downstream services.

A2A agents inherit all the operational patterns the organization already has for service-to-service communication. Circuit breakers, retry policies, observability, and deployment pipelines transfer directly. You do not need a separate runbook for A2A agents. They plug into your existing service mesh.

A2A's enterprise documentation confirms compatibility with distributed tracing (OpenTelemetry, W3C Trace Context) and API management platforms for policy enforcement.

Event-Driven Multi-Agent Coordination with Kafka and A2A

Some teams combine A2A with event streaming platforms like Kafka. [29][30] Instead of direct agent-to-agent calls, an orchestrator publishes task requests to a topic. Specialized agents consume from the topic, process the work, and publish results back. A2A's task lifecycle maps cleanly to event-driven patterns: the task states become event types.

This works well when you need loose coupling between agents or when task volume is high and bursty. The event broker handles backpressure and load balancing, while A2A provides the structured message format and task lifecycle.

The event-driven A2A pattern works particularly well for:

High-volume, bursty workloads where direct synchronous calls create backpressure
Workflows that tolerate eventual consistency over strict ordering
Multi-consumer fan-out scenarios where multiple specialist agents process the same task type
Audit logging and replay requirements, since every task event is durable in the broker

As of Q1 2026, Confluent Intelligence launched "A2A Integration for Streaming Agents" (currently in Open Preview) bringing the A2A protocol into Confluent's Streaming Agents (Confluent Cloud for Apache Flink), letting event-driven agents connect, orchestrate, and collaborate with agents on any A2A-capable platform over replayable event streams on Kafka [23]. Apache Flink FLIP-531 ("Flink Agents"), an active sub-project with contributors from the Apache Flink community including engineers from Confluent [24], adds a native event-driven agent runtime with first-class A2A, MCP, and LLM support, inheriting Flink's checkpointing and exactly-once guarantees.

A2A Protocol Industry Adoption

The A2A adoption numbers are striking. Over 150 organizations back it as of April 2026 [12], building on the launch partner cohort announced in April 2025 [15]:

Enterprise Technology: Salesforce, SAP, ServiceNow, Atlassian, Box, Intuit, Workday

AI/ML Platforms: Google Cloud, LangChain, Cohere, MongoDB

Payments and Commerce: PayPal

Supply Chain: Tyson Foods, Gordon Food Service (pioneering collaborative supply chain agents in a cross-org pilot; Gordon Food Service is actively planning to bring the system to production in Gemini Enterprise and scale it across more vendors)

Major platform integrations as of April 2026 include Microsoft (Azure AI Foundry, Copilot Studio) and AWS (Amazon Bedrock AgentCore Runtime), with Salesforce, SAP, and ServiceNow among the founding contributor organizations [12]. The Gordon Food Service and Tyson Foods cross-org supply chain pilot demonstrated the cross-organization collaboration pattern; Gordon Food Service is actively planning to bring the system to production in Gemini Enterprise and scale it across more vendors [17].

Google's Agent Development Kit (ADK) ships with native A2A support [19], and the Gemini Enterprise Agent Platform (Google's managed agent platform, rebranded from Vertex AI at Cloud Next 2026, generally available April 22, 2026) adds managed A2A deployment [18]. The community has also released the A2A Inspector [27] and Technology Compatibility Kit (TCK) [28] for development and validation.

On the standards front, the W3C AI Agent Protocol Community Group is working toward official web standards, with specifications expected in 2026-2027 [20]. A2A is no longer solely a Google project. It was contributed to the Linux Foundation in June 2025 [13]. It is on a path to becoming a web standard with multi-year governance stability.

What Comes Next for the A2A Protocol

The protocol reached v1.0 in early 2026 with confirmed production deployments across five major enterprises. What happens in the next 12 months will determine whether A2A becomes the default coordination layer for Agentic AI at scale or one option among several. These are the developments that matter:

Multi-Protocol Bindings: Version 1.0 ships three official protocol bindings: JSON-RPC, gRPC, and HTTP+JSON [2]. gRPC is production infrastructure now, not a roadmap item. Expect more frameworks to adopt the gRPC binding for high-throughput agent workloads where HTTP/1.1 overhead matters.

W3C Standardization: The push toward an official web standard means A2A is being designed for the long term. The W3C AI Agent Protocol Community Group is targeting 2026-2027 specifications [20]. This is not a Google-controlled process. It is a multi-stakeholder standards track.

Agent Marketplaces: Agent Cards are the enabling primitive here, making agents discoverable and evaluable before purchase. ISVs can monetize their agents. Enterprises can consume them without custom integration work.

Convergence with MCP: As both protocols mature, expect tighter integration patterns and shared tooling for building agents that speak both protocols natively. The hybrid MCP+A2A pattern is emerging in sophisticated deployments.

The Bigger Picture: A2A as Multi-Agent Infrastructure

We are at an inflection point. For decades, software systems communicated through APIs that humans designed and maintained. With A2A, we are building the infrastructure for software agents to discover and communicate with each other autonomously.

This is not theoretical. Salesforce, SAP, ServiceNow, Microsoft, and AWS are running A2A in production [12]. The protocol has moved past the "interesting specification" phase and into the "production infrastructure" phase.

The analogy to HTTP is apt but incomplete. HTTP standardized document retrieval. A2A standardizes collaboration. The difference matters because collaboration requires state management, capability discovery, and multi-turn interaction. Simple request-response protocols do not handle these well. A task that runs for minutes, requires mid-flight input, and streams partial results back is a fundamentally different coordination problem from fetching a web page.

If you are building multi-agent systems (or even a single agent that might someday need to talk to other agents), A2A is the protocol to learn. The ecosystem is growing fast, the specification is stabilizing at v1.0 [8], and the tooling has reached the point where you can build real systems on it.

The agents are not just learning to talk to each other. They are building the infrastructure to do it reliably, at scale, across organizational boundaries -- and the standard is already in production.

What Do You Think?

Discussion questions for the community:

A2A and MCP address different communication layers in agent systems. As you design your own multi-agent architecture, where do you find the boundary between them gets blurry? How are you handling that?
The protocol is intentionally built on JSON-RPC over HTTP rather than something more exotic. Is that the right call for adoption speed, or does it leave performance on the table for high-throughput agent workloads?
Agent Cards make capability discovery dynamic. But they describe what an agent can do, not whether it is currently healthy or under load. What operational concerns have you hit when relying on A2A for production multi-agent coordination?

Quick Review: A2A Protocol FAQ

Q: What is A2A in one sentence? A: An open protocol (JSON-RPC 2.0 over HTTP) that standardizes how AI agents discover each other's capabilities and collaborate on tasks.

Q: How does A2A differ from MCP? A: MCP connects agents to tools and data sources (vertical, agent controls tools). A2A connects agents to other agents (horizontal, peers collaborate). They are complementary. Use MCP for what your agent does with its tools. Use A2A for how your agent communicates with other agents.

Q: What is an Agent Card? A: A JSON document that describes an agent's capabilities, endpoint, authentication requirements, and supported skills. Other agents fetch it from /.well-known/agent-card.json to understand what the agent can do before engaging.

Q: What are the task lifecycle states? A: TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, and TASK_STATE_REJECTED (agent declines the task). Additional states: TASK_STATE_AUTH_REQUIRED (agent delegates authentication to the client) and TASK_STATE_UNSPECIFIED (unknown/indeterminate). Note: A2A v1.0 changed all state enum values from lowercase hyphenated names to TASK_STATE_ prefixed SCREAMING_SNAKE_CASE [9].

Q: Who backs A2A? A: Over 150 organizations including Google, Salesforce, SAP, ServiceNow, LangChain, PayPal, and others [12]. It is under Linux Foundation governance and heading toward W3C standardization.

Q: Can I use A2A with any AI framework? A: Yes. A2A is framework-agnostic. It is a wire protocol. If your agent can make and receive HTTP requests, it can speak A2A.

Q: If I am already using MCP, do I need A2A? A: It depends on your architecture. If your agent works alone with tools, MCP is sufficient. If your agent needs to delegate work to other agents, or if other agents need to delegate work to yours, A2A is the right protocol for that coordination layer. Many production systems use both.

References

A2A Protocol Official Site (2026)
A2A Protocol Specification v1.0 (2026)
A2A Protocol Docs: A2A and MCP -- Detailed Comparison (2026)
A2A Protocol: Agent Discovery (2026)
A2A Protocol: Core Concepts (2026)
A2A Protocol: Life of a Task (2026)
A2A Protocol: Streaming & Asynchronous Operations (2026)
A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication (2026)
What's New in A2A Protocol v1.0 (2026)
A2A GitHub Repository (a2aproject/A2A) (2026)
The A2A 1.0 Milestone: Ensuring and Testing Backward Compatibility, Google Developer Forums (April 21, 2026)
A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year, Linux Foundation press release (April 9, 2026)
Linux Foundation Launches the Agent2Agent Protocol Project (June 23, 2025)
Google Cloud Donates A2A to Linux Foundation, Google Developers Blog (June 23, 2025)
Announcing the Agent2Agent Protocol (A2A), Google Developers Blog (April 9, 2025)
Introducing Google Agentspace: Bringing AI agents and AI-powered search to enterprises, Google Cloud Blog (December 13, 2024)
Gordon Food Service case study, Google Cloud Customer Story (2026)
Introducing Gemini Enterprise Agent Platform, powering the next wave of agents, Google Cloud Blog (April 22, 2026)
ADK with Agent2Agent (A2A) Protocol, Agent Development Kit Documentation (2026)
W3C AI Agent Protocol Community Group (2025)
IETF RFC 8615: Well-Known Uniform Resource Identifiers (URIs) (May 2019)
Donating the Model Context Protocol and Establishing the Agentic AI Foundation, Anthropic (December 9, 2025)
Confluent Intelligence Q1 2026 Update: A2A Integration for Streaming Agents (February 26, 2026)
FLIP-531: Initiate Flink Agents as a new Sub-Project, Apache Flink Wiki (2026)
a2a-sdk Python API Documentation (2026)
a2a-sdk on PyPI (2026)
A2A Inspector (a2aproject/a2a-inspector) (2026)
A2A Technology Compatibility Kit (a2aproject/a2a-tck) (2026)
Kai Waehner, "Agentic AI with the Agent2Agent Protocol (A2A) and MCP using Apache Kafka as Event Broker" (May 26, 2025)
Sean Falconer / Confluent, "Why Google's Agent2Agent Protocol Needs Apache Kafka" (2025)

About the Author

Rick Hightower is a former Senior Distinguished Engineer and Senior Director at a fortune 100

Rick Hightower is a former Senior Distinguished Engineer at a fortune 100 focusing on delivering ML / AI insights to front line applications, and practitioner building multi-agent production systems. Follow him on Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower's SpeakerHub.

He created skilz, the universal agent skill installer, supporting 30+ coding agents including Claude Code, Gemini, Copilot, and Cursor, and co-founded the world's largest agentic skill marketplace. Connect with Rick Hightower on LinkedIn or Medium. Check out SpillWave, your source for AI expertise.

Rick has been actively developing generative AI systems, agents, and agentic workflows for years. He is the author of numerous agentic frameworks and developer tools and brings deep practical expertise to teams looking to adopt AI. He enjoys writing about himself in the 3rd person.

Rick also wrote a Claude Certified Architect (CCA) series of articles that have a lot of useful information on writing agentic AI systems. A lot of ideas captured in the CCA and the exam prep that Rick wrote echoes what you see in this article. If you want to improve your ability to create well-behaved AI agents, studying for the CCA Exam is a good place to start.

CCA Exam Prep on Agentic Development

Rick also wrote a series on harness engineering and how to improve agentic systems using harness engineering for feedback loops and adversarial agents. These articles also go hand in hand with this article.