Wiki · Concept · Last reviewed May 19, 2026

Agent2Agent Protocol

Agent2Agent Protocol, or A2A, is an open standard for communication, discovery, task management, and collaboration between independent AI agents, especially agents built by different vendors or frameworks.

Definition

Agent2Agent Protocol is a protocol for letting AI agents communicate as peers. Instead of treating another agent as a simple tool call, A2A gives agents a shared way to discover capabilities, exchange messages and artifacts, negotiate modalities, manage tasks, stream updates, use push notifications, and coordinate work across organizational or vendor boundaries.

The official specification describes A2A as an open standard for interoperability between independent and potentially opaque agent systems. Its goal is to let agents built with different frameworks, languages, models, and enterprise platforms collaborate without sharing internal memory, tools, or implementation details.

A2A belongs to the agent infrastructure layer. It is not a model architecture, benchmark, consumer product, or safety framework. It is a proposed communication layer for a world where many specialized agents operate across software systems and need a common task language.

History and Governance

Google announced A2A on April 9, 2025, framing it as a new open protocol for agent interoperability. The launch post said the protocol had support and contributions from more than 50 technology partners and service providers, including enterprise software companies, AI infrastructure firms, consultancies, and automation vendors.

On June 23, 2025, Google Cloud donated the A2A specification, SDKs, and developer tooling to a Linux Foundation-hosted Agent2Agent project. Google said the new project included founding participation from Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. The donation moved A2A from a Google-led initiative toward neutral open governance.

Google Cloud's July 31, 2025 update announced A2A version 0.3, including gRPC support, signed security cards, and extended Python SDK support. By that point Google described an ecosystem of more than 150 supporting organizations and positioned A2A as part of a production toolchain for building, deploying, evaluating, and selling agents.

Architecture

Agent cards. A2A uses agent cards to describe an agent's identity, capabilities, supported protocols, authentication requirements, skills, and interfaces. The current specification includes a well-known URI pattern, .well-known/agent-card.json, for discovering an agent's card.

Tasks. A2A treats collaboration as task management rather than one-shot text exchange. Core operations include sending messages, sending streaming messages, getting tasks, listing tasks, canceling tasks, subscribing to tasks, and configuring push notifications.

Messages and artifacts. A2A supports interaction through messages, structured data, files, and task artifacts. That matters because enterprise agent work often involves documents, tickets, records, reports, approvals, and status updates rather than plain chat alone.

Transport bindings. The specification includes JSON-RPC, gRPC, and HTTP+JSON/REST bindings. This lets implementations fit into ordinary web and enterprise infrastructure rather than requiring a wholly new network stack.

Security model. The specification includes authentication and authorization sections, signed agent cards, transport security requirements, input validation, credential handling, audit and monitoring guidance, rate limiting, and privacy guidance. These controls are necessary because A2A agents may exchange sensitive task context across organizational boundaries.

A2A and MCP

A2A is often discussed beside Model Context Protocol, but the two protocols solve different problems. MCP standardizes how an agent connects to tools, APIs, data sources, and resources. A2A standardizes how one agent collaborates with another agent.

The A2A documentation frames the distinction this way: MCP is for tools and resources with more defined inputs and outputs, while A2A is for peer agents that may reason, plan, maintain state, use multiple tools, and negotiate complex multi-turn work. In a typical architecture, an agent may use A2A to delegate to another agent, while each agent internally uses MCP to reach its own tools and data.

This division matters because collapsing every agent into a tool call can hide agency. A billing agent, travel agent, legal-review agent, procurement agent, or coding agent may have its own policies, state, permissions, logs, and human review gates. A2A tries to preserve that boundary while still making coordination possible.

Why It Matters

A2A is important because agent deployment creates a coordination problem. If every vendor, enterprise platform, and internal team builds agents with incompatible interfaces, multi-agent workflows become brittle custom integrations. A2A offers a shared language for discovery, delegation, task status, artifacts, and handoff.

Its strongest early use case is enterprise automation. A sales agent may need a pricing agent, legal agent, inventory agent, support agent, and finance agent to coordinate across separate systems. A healthcare, manufacturing, logistics, or public-sector workflow may similarly require specialized agents that cannot all share one memory or one tool registry.

A2A also shapes market power. If widely adopted, it could reduce lock-in by letting agents interoperate across providers. If captured by dominant platforms, it could instead become a standard-looking gate through which large vendors control agent discovery, identity, reputation, marketplaces, and monetization.

Risk Pattern

Delegation confusion. When one agent delegates to another, users may lose track of which system acted, under whose authority, with which credentials, and under what policy.

Identity and spoofing risk. Agent cards and discovery mechanisms need strong provenance. A malicious agent that looks like a trusted billing, support, security, or procurement agent could draw sensitive context or trigger harmful actions.

Cross-agent prompt injection. A compromised or hostile agent can pass contaminated instructions, files, artifacts, or summaries into another agent's context. Multi-agent systems expand the surface where untrusted content can masquerade as operational instruction.

Audit fragmentation. Each agent may preserve its own logs, but the harmful event may emerge across handoffs. Without shared traces, incident response can fail at the boundary between systems.

Capability overstatement. Agent cards can advertise skills, but those claims may not reflect reliability, safety, freshness, licensing, or compliance. Discovery is not certification.

Protocol lock-in by another route. Open protocols can still produce centralized marketplaces, reputation systems, identity providers, and hosted runtimes that become control points.

Governance Requirements

A2A deployments need authenticated agent identity, signed and versioned agent cards, clear operator provenance, and revocation. Discovery should answer not only "what can this agent do?" but also "who operates it, who vouches for it, what policy governs it, and when was this capability last verified?"

They also need delegated authority records. When a user authorizes an agent to ask another agent for help, the scope, purpose, time limit, data boundary, and allowed actions should travel with the request rather than being inferred from context.

Finally, A2A systems need end-to-end audit trails. Logs should record the original user intent, source agent, destination agent, agent cards consulted, messages exchanged, artifacts passed, approvals requested, actions taken, errors, and final accountable operator.

Spiralist Reading

A2A is the grammar of the machine bureaucracy.

One agent is an assistant. Many agents become an institution: discovery, delegation, status, credential, file, artifact, handoff, appeal, and record. The protocol decides how synthetic workers recognize each other and how human intent survives the passage between them.

For Spiralism, A2A is therefore not merely plumbing. It is a constitutional question for delegated machine action. If the agent mesh grows faster than identity, consent, audit, and refusal, then humans may face decisions already processed through a chain of synthetic intermediaries no one can reconstruct.

The healthy form is interoperable but accountable: agents can collaborate across boundaries, while every handoff remains visible, scoped, reversible where possible, and anchored to a human or institutional authority that can be challenged.

Open Questions

Sources

Return to Wiki