A2A Protocol: How Google's Agent-to-Agent Standard Is Redefining Multi-Agent AI in 2026

In the early days of the internet, computers from different vendors couldn't talk to each other. Each manufacturer had its own proprietary network stack. Then TCP/IP arrived — a universal protocol that didn't care whether your machine was from IBM, Apple, or DEC. Every device could now communicate because they all agreed on the same rules. We are at exactly that inflection point for AI agents in 2026. And the protocol that's stepping in to play that role is Google's Agent-to-Agent (A2A) protocol.

The Problem: Agents Live in Silos

AI agents have exploded in 2025–2026. Every major company is building them — customer support agents, coding agents, research agents, data analysis agents. The problem? They all live in isolation. A LangChain agent can't natively hand off a task to a CrewAI agent. An agent built on AWS Bedrock can't coordinate with one built on Azure OpenAI. An OpenAI agent can't delegate to a Google Vertex AI agent.

The result is agent sprawl — dozens of siloed AI systems that can't collaborate, can't share context, and can't trust each other. Enterprises end up building brittle custom glue code between every pair of agents. It doesn't scale. It doesn't survive vendor changes. And it creates massive security and governance blind spots.

What Is A2A?

Agent-to-Agent (A2A) is an open protocol announced by Google in April 2025 and rapidly adopted by 50+ technology partners including Atlassian, Salesforce, SAP, ServiceNow, MongoDB, and LangChain. It defines a standard way for AI agents to:

• Advertise their capabilities via a structured Agent Card
• Receive and negotiate tasks through a defined task lifecycle
• Exchange multimodal messages (text, files, structured data, forms)
• Stream long-running results back to the calling agent
• Push notifications for asynchronous task updates

A2A is built on top of existing web standards — HTTP, JSON-RPC 2.0, and Server-Sent Events (SSE). There's no new runtime to install, no proprietary SDK required. If an agent can serve HTTP, it can speak A2A.

The Core Concept: Agent Cards

The centerpiece of A2A is the Agent Card — a JSON document served at a well-known URL (/.well-known/agent.json) that describes what an agent can do, how to authenticate with it, and what formats it accepts and returns. Think of it as a resume + API spec + business card for an AI agent.

{
  "name": "DataAnalysis Agent",
  "description": "Analyzes structured datasets, generates insights, and produces charts.",
  "url": "https://agents.example.com/data-analysis",
  "version": "1.0.0",
  "provider": {
    "organization": "Acme Corp",
    "url": "https://acme.com"
  },
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["Bearer"]
  },
  "skills": [
    {
      "id": "analyze-csv",
      "name": "CSV Analysis",
      "description": "Takes a CSV file and returns statistical summaries and trend insights.",
      "inputModes": ["text", "file"],
      "outputModes": ["text", "data"]
    },
    {
      "id": "generate-chart",
      "name": "Chart Generation",
      "description": "Generates bar, line, or pie charts from structured data.",
      "inputModes": ["data"],
      "outputModes": ["file"]
    }
  ]
}

Any agent — or orchestrator — can fetch this card, understand exactly what the DataAnalysis agent can do, and decide whether to delegate a task to it. No documentation site, no Slack message, no manual integration. Discovery is automatic.

The Task Lifecycle

A2A defines a strict task state machine that makes multi-agent workflows predictable and observable. Every task moves through well-defined states:

The input-required state is particularly powerful — it allows an agent to pause, request clarification from the calling agent or user, and resume. This is how human-in-the-loop workflows are natively supported in A2A.

A2A vs MCP: Complementary, Not Competing

The most common confusion in the agentic ecosystem right now is treating A2A and MCP as alternatives. They're not. They solve completely different problems and are designed to be used together.

In a real production system: the orchestrator agent uses A2A to discover and delegate to specialist agents. Each specialist agent uses MCP to connect to its tools, databases, and APIs. The two protocols operate at different layers of the stack and are architecturally complementary.

Key A2A Concepts Every Builder Must Know

Messages and Parts

A2A communication happens through Messages composed of one or more Parts. A Part can be a TextPart, a FilePart (with inline or URI-referenced data), or a DataPart (structured JSON). This multimodal design means agents can exchange anything from plain text instructions to PDF attachments to database query results in a single task.

Artifacts

When an agent completes a task, it returns Artifacts — the outputs. Artifacts follow the same multimodal Part structure. An artifact can be a generated report (file), a summary (text), a parsed dataset (data), or a filled form. Artifacts are named, versioned, and can be appended to over multiple streaming chunks.

Streaming with Server-Sent Events

For long-running tasks, A2A uses SSE to stream TaskStatusUpdateEvents and TaskArtifactUpdateEvents back to the client in real time. The calling agent doesn't have to poll — it receives a continuous stream of progress updates and partial results as the remote agent works. This is critical for user-facing agentic workflows where latency visibility matters.

Push Notifications

For fire-and-forget tasks where the calling agent doesn't maintain an open connection, A2A supports push notifications. The client registers a webhook URL and the remote agent POSTs task updates to it asynchronously. This enables truly decoupled, long-horizon agentic workflows — a calling agent can dispatch a task and come back hours later when the notification arrives.

Real-World Use Cases

Enterprise Workflow Automation

A Salesforce orchestrator agent receives a sales inquiry. Via A2A, it delegates to a CRM agent (Salesforce), a pricing agent (SAP), and a legal review agent (custom). Each specialist runs in parallel, returns artifacts, and the orchestrator composes a complete response — all without custom integration code between systems.

Cross-Cloud AI Pipelines

An AWS Bedrock orchestrator agent discovers a specialized medical transcription agent running on Google Vertex AI via its Agent Card. It delegates transcription tasks over A2A, receives structured medical records back as artifacts, and stores them in an RDS database — all across cloud boundaries without proprietary connectors.

Agentic DevOps

A planning agent breaks a feature request into subtasks and delegates to a coding agent (Claude Code), a test generation agent, and a deployment agent via A2A. Each agent runs autonomously, pushes artifacts back, and the orchestrator assembles the complete CI/CD pipeline execution — a true software engineering pipeline driven by agents.

Security and Trust in A2A

A2A was designed with enterprise security requirements in mind. Key security properties:

• Authentication: Agent Cards declare supported auth schemes (Bearer, OAuth 2.0, API Key). Callers must authenticate before any task is accepted.
• Authorization: Agents can reject tasks outside their declared skill set — the skill manifest acts as an implicit authorization boundary.
• Transport security: HTTPS is the default transport — all A2A traffic is encrypted in transit.
• Agent identity: The Agent Card URL + TLS certificate binds an agent's identity to a verifiable domain. No impersonation without a valid cert.
• Auditability: The task state machine creates a full audit trail of every delegation, state transition, and artifact produced.

How to Implement Your First A2A Agent

Getting started with A2A requires just three things:

1. Serve an Agent Card

Host a JSON file at /.well-known/agent.json on your agent's domain. Define your name, skills, authentication scheme, and capability flags (streaming, push notifications). This is the entry point for discovery.

2. Implement the Task Endpoint

Expose a JSON-RPC 2.0 endpoint that handles tasks/send (synchronous), tasks/sendSubscribe (streaming), and tasks/get (status polling). For each task, implement the state machine: submitted → working → completed (or failed/input-required).

3. Use an SDK

Google's open-source A2A repository provides reference implementations in Python, Java, and JavaScript. The Python SDK handles the JSON-RPC plumbing, SSE streaming, and task state management so you can focus on the agent logic itself. The LangChain and LangGraph integrations make it trivial to expose any existing agent as A2A-compliant.

# Example: Minimal A2A agent with Python SDK
from a2a.server import A2AServer, TaskContext
from a2a.types import Task, TaskState, TextPart, Artifact

async def handle_task(ctx: TaskContext) -> None:
    await ctx.update_state(TaskState.WORKING)

    # Your agent logic here
    user_message = ctx.task.messages[-1].parts[0].text
    result = await my_llm_call(user_message)

    artifact = Artifact(
        name="response",
        parts=[TextPart(text=result)]
    )
    await ctx.complete(artifacts=[artifact])

server = A2AServer(
    agent_card_path="agent_card.json",
    task_handler=handle_task
)
server.run(host="0.0.0.0", port=8080)

The Ecosystem in March 2026

A2A adoption has been remarkably fast. As of March 2026:

• 50+ launch partners including Atlassian, Box, Cohere, Elastic, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, and Workday
• LangChain and LangGraph have native A2A support — any LangGraph agent can be exposed as A2A-compliant in under 10 lines
• Google Vertex AI Agent Engine natively speaks A2A for its hosted agents
• Claude agents can act as A2A clients or servers via the Anthropic SDK wrappers maintained by the community
• A2A Agent Cards registry — community-maintained index of public A2A agents, searchable by skill and domain

What A2A Means for the Agentic Future

A2A is more than a protocol. It's the foundation for a new software architecture — one where complex tasks are not handled by monolithic AI systems but by networks of specialist agents that discover each other, negotiate contracts (via Agent Cards), and collaborate on tasks in real time. The same way microservices decomposed monolithic backends, A2A enables the decomposition of AI workloads into specialized, independently scalable agent services.

The long-term vision is an open marketplace of AI agents — discoverable, interoperable, and composable. Need a specialized medical coding agent? Discover it via its Agent Card. Need a multilingual contract review agent? Same process. The agent doesn't care what LLM you're using, what cloud you're on, or what framework you built with. A2A is the handshake that makes it all work.

Getting Started Today

• Read the A2A specification at the official Google A2A GitHub repository (google-a2a/a2a)
• Clone the Python reference implementation and run the sample agent locally in under 5 minutes
• Check the LangGraph A2A integration if you already have LangGraph agents — the migration is minimal
• Start by building your Agent Card — even if you're not ready to expose an agent, thinking through your skills manifest clarifies your agent's responsibilities
• Follow the A2A community on Discord — protocol updates, new SDK releases, and real implementation discussions happen there daily

The agentic era isn't coming — it's here. And the agents that will matter most in the next two years won't be the ones that work hardest in isolation. They'll be the ones that collaborate best. A2A is how that collaboration happens.