Update (June 2025): Google donated A2A to the Linux Foundation with founding members including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. The partner count has grown to over 150 organizations, and the protocol reached v0.2 with support for stateless interactions.
Google recently introduced a protocol called Agent2Agent (A2A) that addresses how LLM-powered systems can communicate with each other in enterprise environments.
Released on April 9, 2025, this open protocol attempts to solve a significant challenge in enterprise adoption of autonomous agents: how to enable systems built on different frameworks and by different vendors to exchange information effectively.
Update: A2A reached v1.0 in March 2026
The A2A specification shipped v1.0.0 on March 12, 2026, with breaking changes from v0.2: renamed fields, simpler request IDs and updated OAuth 2.0 flows. Version 0.3 (July 2025) had already moved the Agent Card to /.well-known/agent-card.json and added card signatures.
The spec now defines three bindings: JSON-RPC, gRPC and HTTP+JSON/REST. See the v1.0.0 release notes and the current specification.
A2A serves as a communication protocol for LLM-powered agents. Today, most autonomous agents operate independently - a customer service chatbot typically can’t access information from an inventory management system, even when both contain information needed to resolve a customer issue.
This separation limits what these systems can accomplish. Each agent’s knowledge remains restricted to its specific domain, preventing potentially useful collaboration.
A2A provides a standard communication method that allows different systems to share information and work together on tasks - regardless of which company built them or their underlying technology.
The technical implementation uses existing standards including HTTP, SSE (Server-Sent Events), and JSON-RPC, which should simplify integration with current IT infrastructure.
Google built the protocol around five principles: supporting natural agent capabilities (beyond treating agents as simple tools), using existing standards, incorporating security by default, handling long-running tasks, and supporting multiple types of media beyond just text.
The architecture centers on a few key elements. For discovery, agents publish “Agent Cards” – metadata files that describe their capabilities, authentication requirements, and supported interaction formats. These help other agents understand what services they can provide.
When one agent (the “client agent”) needs assistance from another (the “remote agent”), it creates a “task” – the basic unit of work in the A2A protocol. Tasks move through various states (submitted, working, input-required, completed, failed, canceled) with agents sending updates about their progress.
A useful aspect of A2A is how it handles complex interactions. If an agent needs additional information to complete a task, it can request that input from the original agent. The protocol supports streaming for updates during long-running tasks and push notifications for agents to receive alerts when disconnected tasks finish.
Rather than creating general-purpose agents that attempt to handle everything, organizations could develop specialized agents with deeper expertise in specific areas, then allow them to collaborate on more complex workflows.
There are reasons to be cautious about how widely this approach might be adopted. Many previous attempts at creating universal standards for technology interoperability have had limited success. XMPP for chat protocols and RSS for content distribution both faced challenges from proprietary alternatives. A2A might encounter similar difficulties if major technology providers prefer their own closed systems.
The protocol doesn’t clearly address how to resolve conflicts when agents disagree about how to handle a task. Whose interpretation takes priority? This lack of conflict resolution mechanisms could become problematic in complex scenarios.
Security considerations are also important. While A2A includes authentication mechanisms, connecting previously separate systems increases potential security vulnerabilities. A weakness in one agent could potentially affect connected systems.
Despite these considerations, Google has partnered with more than 50 technology companies including Atlassian, Box, Cohere, Intuit, PayPal, Salesforce, SAP, ServiceNow, UKG and Workday, as well as service providers like Accenture, BCG, Capgemini, Cognizant, Deloitte, HCLTech, Infosys, KPMG, McKinsey, PwC, TCS, and Wipro.
This suggests there’s interest in exploring interoperability between different systems rather than maintaining completely isolated approaches.
For enterprises, A2A could potentially help address data silos without requiring extensive integration projects. Specialized agents could exchange information across different platforms when needed. For example, in a hiring process, an HR agent might coordinate with other specialized systems to handle candidate sourcing, interview scheduling, background checks, and onboarding procedures.
The documentation mentions that A2A complements other approaches like Anthropic’s Model Context Protocol (MCP), which focuses on providing tools and context to individual agents rather than enabling communication between agents.
The key question is whether enough organizations will adopt this standard. For A2A to have significant impact, it needs widespread implementation. If that happens, it could change how LLM-powered systems operate - enabling more collaboration between specialized systems.
However, this requires overcoming the tendency of technology companies to develop proprietary solutions they can control more directly. While Google has gathered initial support from various organizations, economic factors often influence whether technical standards achieve widespread adoption.
Rao Surapaneni from Google Cloud noted: “To maximize the benefits from agentic AI, it is critical for these agents to be able to collaborate in a dynamic, multi-agent ecosystem across siloed data systems and applications. Enabling agents to interoperate with each other, even if they were built by different vendors or in a different framework, will increase autonomy and multiply productivity gains, while lowering long-term costs.”
