Agent2Agent (A2A) Protocol: How Autonomous Agents Communicate and Collaborate

Every enterprise piloting multiple AI agents eventually runs into the same problem: an agent built in one framework has no way to talk to an agent built in another. That's the coordination gap that agent-to-agent communication was built to close, and it's why the Agent2Agent protocol has grown from a Google research project to a Linux Foundation standard with more than 150 supporting organizations in under two years.

A2A defines how independent AI agents discover one another, negotiate what they can do, and delegate work across organizational and vendor boundaries. It doesn't replace the protocols an agent uses to call its own tools. It sits one layer up, handling agent-to-agent delegation the way an operator once connected calls between separate phone networks.

For teams building or securing multi-agent systems, understanding what A2A actually does, how it relates to MCP, and where the risk shows up in a real workflow, is quickly becoming a baseline requirement.

What Is Agent2Agent (A2A)?

Agent2Agent (A2A) is an open agent-to-agent protocol that lets independent AI agents discover each other's capabilities, negotiate how to interact, and delegate tasks across organizational and platform boundaries. Agent2Agent is sometimes referred to as Agent-to-Agent or A2A. Google introduced it in April 2025 with support from more than 50 technology partners, and by June 2025 the project had moved to neutral governance under the Linux Foundation, the same nonprofit that hosts Linux, Kubernetes, and MCP. One year later, more than 150 organizations, including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow, support the standard, and its core repository has passed 22,000 GitHub stars with production-ready software development kits (SDKs) in five languages.

The problem A2A solves is straightforward to state and expensive to ignore: agents built on different frameworks, by different vendors, don't share a common language. Without a shared protocol, connecting a LangGraph-based agent to a Salesforce Agentforce agent to a home-grown agent running on Amazon Bedrock means custom, brittle integration work for every new pair of agents that needs to collaborate. A2A replaces that patchwork with a shared, standardized way for any two agents to find each other and work together, regardless of what either one is built on.

How A2A Compares to, Differs From, and Complements MCP

A2A is frequently confused with the Model Context Protocol (MCP), introduced by Anthropic in 2024 and now also a Linux Foundation project. The confusion is understandable, since both protocols standardize how AI systems connect to the outside world. The difference is what's on the other end of that connection.

What each protocol actually connects

Protocol

Connects

Best Analogy

MCP

An agent to its own tools, data sources, and application programming interfaces (APIs)

An agent's hands

A2A

An agent to other agents, across vendors, frameworks, and organizations

An agent's phone line

IBM frames the relationship with a concrete example: a retail inventory agent might use MCP to query its own database for stock levels, and the moment it detects a shortage, use A2A to contact an external supplier's order-placing agent and place a purchase order automatically. One protocol connects the agent inward, to its own tools. The other connects it outward, to a different organization's agent entirely.

Why the two are designed to complement, not compete

Neither protocol tries to do the other's job. A2A's own documentation is explicit that it isn't an agent development framework like LangGraph or CrewAI, and it isn't a substitute for how an agent calls its own tools. The Linux Foundation describes the pairing directly: A2A governs how agents communicate and coordinate across organizational boundaries, while MCP governs how a single agent connects to internal tools and data. Together, they form the two halves of a working multi-agent system: one internal, one external.

Core Technical Components of A2A

A2A's specification defines a small set of building blocks that together handle discovery, task tracking, and result delivery. Five concepts do most of the work.

• Agent Card. A JSON manifest a server publishes at a well-known web address, formally /.well-known/agent-card.json, listing its identity, skills, service endpoint, and required authentication. Client agents fetch it first, the way a directory lookup precedes a phone call.
• Task. The stateful unit of work A2A is built around. Every task gets a unique ID and moves through a defined lifecycle, such as submitted, working, input-required, or completed, so agents on both sides can track progress on work that might take seconds or days.
• Message. A single turn of communication between a client and a remote agent, tagged with a role of user or agent and built from one or more Parts.
• Part. The smallest content unit inside a Message or Artifact. A TextPart carries plain text, a FilePart carries a file reference, and a DataPart carries structured JavaScript Object Notation (JSON) data, which is what makes A2A modality-agnostic rather than text-only.
• Artifact. The actual deliverable a remote agent produces, such as a document, dataset, or image, composed of one or more Parts and streamable incrementally as it's generated.

How agents actually talk: transport and delivery

A2A runs over hypertext transfer protocol secure (HTTPS) and uses JavaScript Object Notation remote procedure call (JSON-RPC) 2.0 as its default payload format, with Google's remote procedure call framework (gRPC) and a representational state transfer (REST)-style HTTP binding also supported. For anything longer than an instant response, agents have two options: Server-Sent Events (SSE) for a live stream of status and partial results, or push notifications, where the remote agent posts updates to a webhook the client registered in advance. Authentication requirements, whether API keys, OAuth 2.0, or OpenID Connect, are declared right in the Agent Card, so a client knows how to authenticate before it ever sends a request.

Opaque by design

One deliberate constraint runs through all of this: A2A treats every remote agent as an opaque system. Agents exchange declared capabilities and task results, never internal reasoning, memory, or tool implementations. That protects a vendor's intellectual property and keeps agents interoperable regardless of what's running underneath, but it also means a client agent and the security team responsible for it are extending trust to a system it fundamentally cannot inspect from the inside.

A Typical A2A Workflow Example

The building blocks above come together in a fairly consistent pattern across real deployments. Here's what that looks like end to end, using a scenario the Linux Foundation has pointed to directly: supply chain coordination.

• 1. Discovery. A retail inventory agent detects that a SKU has fallen below its reorder threshold. It needs a supplier's agent to place a purchase order, so it fetches that supplier's Agent Card from the well-known URI on the supplier's domain.
• 2. Capability match. The Agent Card lists the supplier agent's skills, its service endpoint, and its required authentication scheme. The inventory agent confirms the supplier agent can handle purchase orders and reads what authentication it needs to proceed.
• 3. Task initiation. The inventory agent authenticates, then sends a message using the message/send method, formatted as JSON-RPC 2.0, over HTTPS. This creates a new Task with a unique ID on the supplier's side.
• 4. Processing and status updates. Placing the order might require the supplier's agent to check its own inventory and confirm pricing, so it doesn't respond instantly. If the interaction supports streaming, the supplier's agent pushes status updates over SSE as the task moves from submitted to working. If the client isn't maintaining a live connection, the supplier's agent can instead post updates to a webhook the inventory agent registered when it created the task.
• 5. Artifact delivery. Once the order is placed, the supplier's agent returns an Artifact, in this case a structured order confirmation, composed of a DataPart with the order details and a FilePart with a purchase order document.
• 6. Task completion. The Task transitions to a terminal state, completed, and the inventory agent has everything it needs to update its own records, without either agent ever exposing its internal logic, pricing engine, or database schema to the other.

Why Agent-to-Agent Communication Changes the Security Conversation

A2A's design choices are also where new risk shows up. Opaque execution is a feature for interoperability and a blind spot for security: if a client agent can't see inside a remote agent, it can't verify that the remote agent is doing what its Agent Card claims. A compromised or malicious remote agent can advertise legitimate-sounding skills and still misuse the trust a task delegation implies.

The scope of what's being delegated matters, too. A2A tasks aren't simple queries; they're often multi-step work with real-world side effects, such as placing a purchase order, updating a record, or moving data between organizations. Because these interactions increasingly happen agent-to-agent rather than agent to human, the agent is the new endpoint worth watching, not just the person who kicked off the request several hops upstream.

Authentication is declared per agent in the Agent Card, which is enterprise-grade in principle, but it also means an organization adopting A2A at scale is managing authentication, authorization, and monitoring across every remote agent it interacts with, not just the ones it built. That's a materially different governance problem than securing tool calls inside a single application.

Guardrails, Boundaries, and Guardian Agents in Agent-to-Agent Systems

As agent-to-agent communication multiplies the number of trust relationships an enterprise has to manage, three concepts define what keeps that expansion from turning into exposure: guardrails, boundaries, and the emerging category of guardian agents built to enforce both in real time.

Guardrails

Guardrails are the declared, enforced constraints on what an agent is allowed to do: which tools it can call, what data it can access, and which actions require human approval. In a single-agent system, guardrails are relatively contained. In an agent-to-agent system, they have to travel. When a client agent delegates a task to a remote agent, the remote agent's guardrails, not the client's, are what actually govern what happens next. An Agent Card tells a client agent what a remote agent claims it can do; it says nothing about whether that agent's own guardrails are trustworthy or equivalent to the client's.

Boundaries

Every A2A interaction crosses a boundary: organizational, vendor, or infrastructural, and each crossing is a point where risk can be introduced or missed entirely. A2A was explicitly designed to work across these boundaries, letting agents built by different companies on different infrastructure interoperate without either side exposing its internals. That's valuable for interoperability, and it's exactly why the boundary itself needs active enforcement. A guardrail that only applies inside one agent's own environment stops working the moment a task crosses into somebody else's.

Guardian Agents

This is the gap driving what analysts have started calling guardian agents: a category described as marking a shift in AI governance from passive, after-the-fact monitoring to active, real-time protection of AI systems. A guardian agent doesn't just log what happened once a task is done. It supervises an agent's behavior, including its agent-to-agent interactions, as they happen, and can enforce policy before a risky action executes rather than flag it afterward. As agent-to-agent workflows scale, human review of every task delegation stops being realistic. Guardian agents are the response to that scale problem: security itself becoming agentic enough to keep pace with the agents it's watching.

Where This Fits Into Zenity's Approach

Governing agent-to-agent communication is an extension of the same problem Zenity's platform is built around: understanding what an agent can access, what it actually does at runtime, and whether its behavior matches its declared intent. As A2A adoption grows, that means extending visibility and policy enforcement across every remote agent an organization's agents delegate work to, not only the ones running inside its own environment.

Zenity's AI Security Posture Management capability maps agent-to-agent relationships and permissions before they reach production. Zenity’s AI Detection and Response capability, watches how those relationships actually behave at runtime, flagging tasks and tool calls that don't match an agent's expected purpose. That pairing reflects the same principle running through the rest of Zenity's platform: enforcing consistent policy from build time to runtime, regardless of which protocol, framework, or vendor is on the other end of the connection.

Zenity has described this same shift as the foundation for its Guardian Agent architecture: continuous, contextual security built to supervise, evaluate, and enforce policy on other AI agents as they operate, including the agent-to-agent interactions A2A is designed to enable. As task delegation increasingly crosses organizational lines, that kind of always-on supervision is what keeps a guardrail enforceable past the boundary where a single agent's own controls stop applying.

Multi-agent systems built on A2A are moving from pilot to production quickly, and the organizations getting ahead of it are building governance alongside the protocol itself, rather than after the first incident.

Want to see how policy enforcement and runtime visibility extend across agent-to-agent workflows in your environment? Book a demo to walk through it.

FAQs About Agent2Agent (A2A)

What is Agent2Agent (A2A)?

A2A is an open, vendor-neutral protocol that lets independent AI agents discover each other, advertise their capabilities, and delegate tasks across organizations, frameworks, and platforms without custom point-to-point integration.

What does A2A stand for?

A2A stands for Agent2Agent, sometimes written as agent to agent or agent-to-agent. It's commonly abbreviated as A2A in technical documentation.

Is A2A the same as MCP?

No. The Model Context Protocol connects a single agent to its own tools, data, and application programming interfaces. A2A connects that agent to other agents. Most production multi-agent systems use both.

Who governs the A2A protocol?

A2A was originally developed by Google and donated to the Linux Foundation in June 2025, where it's maintained by a Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow.

What transport does A2A use?

A2A communication happens over HTTPS, with JSON-RPC 2.0 as its default payload format. gRPC and a REST-style HTTP binding are also supported, and agents declare which ones they support in their Agent Card.

Does A2A support long-running tasks?

Yes. Tasks can stay open for seconds or days. A2A supports polling, Server-Sent Events for live streaming updates, and webhook-based push notifications for tasks where a persistent connection isn't practical.

What's the security risk with agent-to-agent communication?

A2A treats remote agents as opaque by design, which protects intellectual property but also means an organization is extending trust to systems it can't inspect from the inside. Authentication, authorization, and behavioral monitoring need to extend across every remote agent an organization's agents interact with, not just the ones it built internally.