A2A Protocol: How Autonomous Agents Communicate

In its first year, the A2A protocol grew from 50 founding partners to more than 150 organizations, crossed 22,000 GitHub stars, and landed inside Azure, AWS, and Google Cloud. That is not a research curiosity. It is the fastest-moving open standard in the agent space, and it exists to solve one problem: how do autonomous agents actually talk to each other?

The Linux Foundation confirmed those numbers on the protocol's one-year mark in April 2026. If you are building anything past a single agent, agent-to-agent communication is about to become part of your stack, whether you adopt A2A directly or not.

This guide is the builder's field guide to the A2A protocol: what it is, how it works under the hood, how it differs from MCP, and what it means for anyone who has to deploy and govern a fleet of agents in production.

In a hurry? Start building agents you can watch work.

What is the A2A protocol?

The A2A (Agent-to-Agent) protocol is an open standard that lets AI agents discover each other, authenticate, delegate tasks, and coordinate, without any custom integration code between each pair. Think of it as the shared language independently built agents use to work together, even when they run on different frameworks, from different vendors, inside different companies.

Here is the one-line mental model. MCP gives a single agent hands. A2A gives a fleet of agents a shared language. A calculator, a database, or a search API is a tool an agent reaches for. Another agent is a peer it negotiates with. Those are two different problems, and A2A owns the second one.

The official A2A documentation puts it plainly: A2A "enables seamless communication and collaboration between AI agents" built "using diverse frameworks and by different vendors." The whole point is to break down the silos that form when every team ships its own agent with its own private way of being called.

Who created A2A and who governs it

Google introduced A2A in April 2025 with more than 50 founding partners, including Atlassian, Salesforce, SAP, ServiceNow, PayPal, and Workday. In June 2025, Google Cloud donated the protocol to the Linux Foundation, which now hosts it as a vendor-neutral project alongside the Model Context Protocol.

That governance move matters more than it looks. A protocol owned by one cloud vendor is a strategy. A protocol owned by a neutral foundation, with AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow all contributing, is an actual standard. By the v1.0 release, the SDK ecosystem had grown from a single Python library to five production languages: Python, JavaScript, Java, Go, and .NET.

The problem A2A actually solves

Picture five agents that each do one job well: a flight booking agent, a hotel agent, a currency agent, a local-tours agent, and an assistant that fronts the user. Without a shared protocol, connecting them is a point-to-point nightmare. Every pair needs a bespoke integration. Five agents that all talk to each other is ten custom connections. Ten agents is forty-five. The wiring grows faster than the value.

This is the N-squared integration wall, and it is exactly the wall that killed a generation of enterprise middleware. A2A replaces all of that bespoke glue with one handshake every agent already understands.

Without a standard, each interaction requires custom, point-to-point solutions, creating significant engineering overhead and making systems difficult to scale as the number of agents grows.

Why agents need a communication protocol

We already have HTTP for browsers and servers, and we have APIs for services. So why do agents need their own layer?

Because agents are a genuinely new kind of software actor. A REST API is stateless and predictable: you call it, it returns, done. An agent reasons, plans, asks clarifying questions, runs for minutes or hours, and streams partial results as it goes. Wrapping one agent as a plain tool for another agent throws away most of what makes it useful. As the A2A specification notes, encapsulating an agent as a simple tool "is fundamentally limiting, as it fails to capture the agent's full capabilities."

A protocol built for agents has to handle four things that ordinary APIs do not:

• Discovery. An agent needs to find out what another agent can do before it delegates anything.
• Long-running work. Tasks can take minutes. The protocol has to stream progress and survive disconnects.
• Opaque collaboration. Two agents from rival vendors must cooperate without exposing their internal memory, prompts, or logic.
• Multi-turn negotiation. Real delegation involves clarification and back-and-forth, not a single request and response.

A2A was designed around exactly these four needs, which is why it is not just "REST for agents."

How the A2A protocol works

A2A deliberately reuses boring, proven web standards so developers do not have to learn anything exotic. Under the hood it runs on HTTP, JSON-RPC 2.0, and Server-Sent Events (SSE) for streaming, with push notifications for tasks that outlive a single connection. Here are the pieces that matter.

Agent Cards: how agents get discovered

Every A2A-enabled agent publishes an Agent Card, a machine-readable JSON manifest describing what it can do, where to reach it, and how to authenticate. It typically lives at a well-known URL like /.well-known/agent-card, so any other agent can fetch it and learn how to work with it. In v1.0, Agent Cards can be cryptographically signed for verified identity.

A simplified Agent Card looks like this:

{
  "name": "Invoice Reconciliation Agent",
  "description": "Matches incoming payments to open invoices and flags discrepancies",
  "url": "https://agents.example.com/invoice",
  "version": "1.2.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [
    {
      "id": "reconcile",
      "name": "Reconcile payments",
      "description": "Match a batch of payments against open invoices"
    }
  ],
  "securitySchemes": { "type": "openIdConnect" }
}

The card is the discovery layer. It is how one agent answers the question "what are you, and can you help with this?" before any real work starts.

Tasks, messages, and artifacts

Once two agents connect, work flows through three core objects:

• A Task is the unit of work, with a lifecycle: submitted, working, input-required, completed, or failed.
• Messages carry the back-and-forth between the client agent and the server agent while the task runs.
• Artifacts are the outputs the task produces, whether that is text, a file, structured data, or a mix.

Because a Task has an explicit lifecycle, both sides always know where things stand, even when the work takes minutes and streams updates the whole way.

Client agent versus remote agent

A2A defines two peer roles for any exchange. The client agent initiates a request and delegates the work. The remote (or server) agent receives the task, does the work, and streams results back. These are roles, not fixed identities: the same agent can be a client in one conversation and a server in another. That symmetry is what makes A2A a peer-to-peer protocol rather than a rigid hub-and-spoke.

A worked example: one agent delegating to another

Here is what a single delegation actually looks like end to end, straight from the A2A request lifecycle:

1. Discovery. The client agent fetches the remote agent's Agent Card from its well-known URL and reads its capabilities and security scheme.
2. Authentication. The client parses the card, requests a token from the auth server (for example via OpenID Connect), and receives a JWT.
3. Send the task. The client calls sendMessage with the JWT. The server processes it, creates a Task, and returns the task response.
4. Stream the result. For long work, the client calls sendMessageStream and receives a live stream: task submitted, status updates as it works, artifacts as they are produced, then completed.

{
  "goal": "Delegate invoice reconciliation to a specialist agent",
  "steps": [
    "GET /.well-known/agent-card to discover capabilities",
    "Authenticate via OpenID Connect, obtain a JWT",
    "POST sendMessage with the reconciliation task and the JWT",
    "Open sendMessageStream to receive status updates and artifacts live",
    "On completed, collect the reconciliation report artifact"
  ],
  "never": ["read the other agent's internal memory", "assume a schema not declared in the Agent Card"]
}

Notice what the client never does: it never reaches into the other agent's memory or prompts. It only sees declared capabilities and the artifacts that come back. That opacity is a feature, and it is what lets two competitors' agents cooperate safely.

A2A vs MCP: agent-to-agent versus agent-to-tool

This is the single most searched comparison in the agent-protocol space, and the answer is refreshingly simple: they are not competitors, they are complementary layers.

• MCP (Model Context Protocol) connects one agent to its tools and data. It is vertical and client-server. It answers "how does this agent reach the outside world?" If you want the full picture, our deep dive on the Model Context Protocol covers it.
• A2A connects agents to other agents. It is horizontal and peer-to-peer. It answers "how do these agents coordinate with each other?"

The two stack together naturally. An A2A server agent, while handling a delegated task, can use MCP internally to call its own databases and APIs. The Linux Foundation, which now hosts both projects, describes them as "a foundational layer for interoperable, multi-agent systems."

The rule of thumb: if the thing you are calling can reason and negotiate, use A2A. If it just runs a function and returns, use MCP. Most serious multi-agent systems end up using both.

August 14, 2026

What Is the Model Context Protocol (MCP)? A Complete Guide

The Model Context Protocol (MCP) is the open standard connecting AI apps to tools and data. Learn how MCP works, its architecture, primitives, transports, and security, plus how to run MCP servers safely.

A2A and the other agent protocols

A2A is not the only entry in this space, and knowing the landscape helps you place it. ACP (Agent Communication Protocol) and ANP (Agent Network Protocol) tackle overlapping goals with different design choices, and Cisco's AGNTCY work fed into the same broader effort. A2A's edge is momentum and enterprise backing: v1.0 shipped with multi-tenancy and signed identity, and the major clouds embedded it directly. For most teams the practical question is not "which of these five protocols is theoretically best," it is "which one will my vendors and frameworks actually speak," and today that answer is increasingly A2A.

Building with A2A in practice

A2A lives at the orchestration layer of your architecture. It is the wire between agents, not a replacement for the framework you build each agent in. If you are still shaping how your agents are structured internally, our guide to AI agent architecture covers the single-agent side, and AI agent orchestration covers coordinating many.

Frameworks and SDKs that speak A2A

The point of an open protocol is that heterogeneous agents interoperate. Agents built on different frameworks like LangGraph and CrewAI can now delegate sub-tasks and coordinate workflows without sharing internal memory, which is precisely the scenario the Linux Foundation highlighted at v1.0. If you are weighing your own stack, our AutoGen vs CrewAI comparison walks through the trade-offs. A2A sits above all of them, so your choice of framework stops being a lock-in decision.

A2A versus wiring agents by hand

The honest question every builder asks: do I need a protocol, or can I just have my agents call each other's endpoints directly?

You can hand-wire two agents in an afternoon. The problem is the third, fourth, and tenth. Every new pair is another bespoke integration, another auth scheme, another schema to keep in sync, another thing that breaks silently when one side changes. A2A trades that sprawl for one handshake. The checklist below is what "production-ready A2A" actually requires:

• Publish a signed Agent Card at a well-known URL for each agent
• Enforce authentication on every task (OpenID Connect or equivalent)
• Handle the full Task lifecycle, including input-required and failed
• Stream long-running work over SSE instead of blocking
• Apply least-privilege scopes so an agent can only request what it should
• Log every delegation for audit and replay

Those last two points are where most teams underestimate the work, and they are exactly where governance comes in.

Security, trust, and governance for agent-to-agent communication

Here is the part the "what is A2A" explainers skip, and it is the part that decides whether your system survives contact with production. When agents can discover and delegate to each other autonomously, you have created a new attack surface and a new accountability problem at the same time.

The peer-reviewed threat modeling is already here. A security analysis of A2A using the MAESTRO framework, Building A Secure Agentic AI Application Leveraging A2A Protocol, walks through the concrete risks: Agent Card tampering, task-execution integrity, and weak authentication between agents. The failure modes are specific and worth naming:

• Agent impersonation. A malicious agent publishes a convincing Agent Card and gets delegated work it should never see. Signed Agent Cards exist precisely to counter this.
• Task injection. A crafted message manipulates the receiving agent into doing something outside its declared scope.
• Over-delegation. An agent hands off more authority than the task needs, and the blast radius of a mistake compounds across the chain.

Building A Secure Agentic AI Application Leveraging A2A ProtocolAs Agentic AI systems evolve from basic workflows to complex multi agent collaboration, robust protocols such as Google's Agent2Agent (A2A) become essential enablers. To foster secure adoption and ensure the reliability of these complex interactions, understanding the secure implementation of A2A is essential. This paper addresses this goal by providing a comprehensive security analysis centered on the A2A protocol. We examine its fundamental elements and operational dynamics, situating it within the framework of agent communication development. Utilizing the MAESTRO framework, specifically designed for AI risks, we apply proactive threat modeling to assess potential security issues in A2A deployments, focusing on aspects such as Agent Card management, task execution integrity, and authentication methodologies. Based on these insights, we recommend practical secure development methodologies and architectural best practices designed to build resilient and effective A2A systems. Our analysis also explores how the synergy between A2A and the Model Context Protocol (MCP) can further enhance secure interoperability. This paper equips developers and architects with the knowledge and practical guidance needed to confidently leverage the A2A protocol for building robust and secure next generation agentic applications.arXiv.org

The protocol gives you the primitives: signed identity, standard auth flows, opaque execution. But primitives are not a governance strategy. You still have to decide who can delegate what, keep a human in the loop for high-stakes actions, and maintain an audit trail across every hop. This is the same discipline we cover in our guide to AI agent governance: standardized communication is what makes agent behavior auditable in the first place, and auditability is the foundation everything else sits on.

Where Rerun fits

A protocol tells your agents how to talk. It does not tell you what they did, whether it was right, or how to stop a bad delegation before it costs you. That gap is the reason Rerun exists.

Rerun is the platform for running autonomous AI agents you can actually watch work. You pick an agent from a library or build one, connect your tools, and watch every action stream onto a live dashboard anyone on your team can read. When multiple agents hand work between each other, you see each handoff happen, not a black box that reports back later.

That maps directly onto the governance gap A2A leaves open:

The differentiators are the ones A2A itself cannot give you: approvals so an agent pauses and asks before a payment or a client email, least-privilege by default, and a live dashboard where a delegation you did not expect is visible the moment it happens instead of in a post-mortem.

When you should, and shouldn't, use A2A

A2A is powerful, and it is also overkill for a lot of problems. Being honest about that builds more trust than pretending every workflow needs a negotiation protocol.

Use A2A when you have heterogeneous, multi-vendor, or multi-agent systems where agents must discover each other and decide who handles a task at runtime. That is the case A2A was built for, and nothing else does it as cleanly.

Skip A2A when your workflow is fixed and deterministic. If you can draw the whole thing as boxes and arrows before it runs, where step B always follows step A, you do not need agents negotiating. You need an automation tool, and that is exactly what Zapier, Make, and n8n are good at.

This is the honest line to hold:

If you can draw the entire workflow as boxes and arrows before it runs, use an automation tool. If the agents have to figure out who does what at runtime, you want a protocol, and A2A is that protocol.

And a chatbot is a third thing entirely. A chatbot is one endpoint answering a human. A2A is machine-to-machine delegation with capability discovery, task lifecycles, and artifacts, with no human in the loop per exchange. Rerun sits on the agent side of both lines: real autonomous agents that do the work, not a flowchart you maintain and not a chatbot that only talks back.

The road ahead for A2A

A2A has moved from announcement to infrastructure faster than almost any protocol in recent memory. The v1.0 spec brought multi-tenancy, modernized security, and a migration path. Microsoft embedded it into Azure AI Foundry and Copilot Studio, AWS added support through Amazon Bedrock AgentCore Runtime, and the ecosystem pushed into economic coordination with the Agent Payments Protocol (AP2) for agent-driven transactions.

The roadmap points at an interoperability specification, a shared registry, and hardened security and deployment best practices. The direction is clear: A2A is becoming a default layer of modern agent architecture. If you are building an AI agent today, it is worth designing as if your agent will one day need to speak to agents you do not control, because it will.

The protocol solves the communication problem. The harder problem, the one that decides whether your agents are safe to run in production, is watching, governing, and trusting the work they do. That part is on you, and it is the part Rerun is built for.