Wiki · Concept · Last reviewed June 23, 2026

Agent2Agent Protocol

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

Category: Concept / Agent Infrastructure Published: June 23, 2026 Modified: June 23, 2026 Last reviewed: June 23, 2026 Tags: A2A, AI Agents, Agent Identity, Interoperability, MCP, Audit Trails

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 communication and task layer for a world where many specialized agents operate across software systems and need a common language for delegation, status, artifacts, and handoff.

That definition should stay operational. A2A does not make an agent reliable, authorized, compliant, or safe. It gives systems a standard interaction surface; the surrounding deployment still has to prove identity, consent, scopes, data handling, auditability, incident response, and human oversight.

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.

As of the June 23, 2026 review, the official A2A specification page identifies 1.0.0 as the latest released version. The A2A community's v1.0 announcement describes it as the first stable, production-ready version, guided by a technical steering committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. The v1.0 materials emphasize multiple protocol bindings, version negotiation, signed Agent Cards, multi-tenancy support, cleaner operation names, and migration from earlier versions.

Architecture

Agent cards. A2A uses Agent Cards to describe an agent's identity, provider, version, capabilities, skills, supported interfaces, security schemes, and security requirements. The v1.0 specification also defines Agent Card signatures using JWS and JSON canonicalization, authenticated extended Agent Cards, and caching expectations. Discovery is useful only if clients verify provenance and do not treat self-advertised skills as certification.

Tasks. A2A treats collaboration as task management rather than one-shot text exchange. Core operations include SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, push-notification configuration methods, and GetExtendedAgentCard. The v1.0 operation names matter because older 0.3 examples use different method names.

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 v1.0 specification includes JSON-RPC, gRPC, and HTTP+JSON/REST bindings, with equivalence requirements across bindings. This lets implementations fit into ordinary web and enterprise infrastructure rather than requiring a wholly new network stack.

Versioning and extensions. A2A v1.0 uses version signaling, per-interface protocol versions, and extension declarations so clients and agents can negotiate capabilities without assuming every implementation supports the same features. That helps migration, but it also means audits should record the exact protocol version, binding, and extensions used in a run.

Security model. The specification includes authentication and authorization sections, security schemes aligned with common API patterns, 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.

The public signal is broad but still early. The A2A partners page lists many vendors, platforms, consultancies, and infrastructure companies, while the official community hub points to integrations in several agent frameworks. That establishes ecosystem interest; it does not prove that production deployments are secure, interoperable, or governed well.

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.

Agent-card poisoning. Agent Cards are both metadata and model-facing context. Misleading descriptions, stale versions, malicious skill claims, or forged signatures can steer routing and task delegation before any ordinary tool call occurs.

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.

Cascading failure. A weak handoff can turn one agent's error into a multi-agent chain: bad status, false confidence, repeated retries, duplicated external messages, or conflicting updates across systems.

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.

Multi-tenant A2A endpoints need tenant isolation, routing controls, rate limits, and clear separation between public Agent Cards and authenticated extended Agent Cards. A public discovery card should not leak sensitive capabilities, internal URLs, privileged workflows, or customer-specific configuration.

High-impact handoffs should require human or policy review before irreversible side effects. The review should name the source agent, destination agent, requested task, data to be shared, credentials or scopes involved, expected artifact, and rollback path.

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

Source Discipline

A2A claims should name the protocol version and binding. Version 0.3 and version 1.0 differ in operation names, Agent Card structure, security features, version negotiation, multi-tenancy, and migration expectations. A tutorial, SDK page, or vendor connector may still target 0.3 while the main specification advertises 1.0.0 as the latest released version.

Separate protocol status from deployment status. The official specification can show how A2A is supposed to work; a vendor announcement can show planned support; a GitHub sample can show an implementation pattern. None of those sources independently proves that a real enterprise agent mesh is safe, reliable, audited, or compliant.

For security claims, prefer the official specification, release notes, Linux Foundation or project governance materials, NIST agent-identity work, OWASP agentic risk categories, and reproducible implementation reports. Treat partner lists and marketing quotes as adoption signals, not as evidence of security or interoperability.

When describing a deployed A2A system, record the agent card, signature status, provider, protocol version, transport binding, authentication method, delegated scopes, task IDs, artifacts, push-notification endpoints, tenant routing, approvals, and incident contact. Without those details, "uses A2A" is too vague to govern.

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