A2A protocol

The A2A protocol (Agent-to-Agent) is an open communication standard that allows AI agents built on different frameworks or by different vendors to discover each other's capabilities, exchange structured data, and coordinate tasks without exposing their internal logic or memory.

As agentic AI deployments grow more complex, a single monolithic agent rarely handles every step of a customer interaction on its own. Organizations often run specialist agents for authentication, payment processing, order management, and escalation routing. Without a shared protocol, connecting those agents requires bespoke integrations for every pairing. The A2A protocol provides a common language so that agents from any vendor or runtime can interoperate, lowering the cost of building multi-agent systems and reducing the fragility that comes with point-to-point wiring.

How the A2A protocol works in practice

Introduced by Google in April 2025 and now stewarded by the Linux Foundation, A2A runs over HTTPS and uses JSON-RPC 2.0, so it slots into existing enterprise infrastructure. Each participating agent publishes an Agent Card, a JSON document served at a well-known HTTP endpoint that declares the agent's identity, supported skills, authentication, and API version. A client agent fetches the card to learn what a remote agent can do before initiating any task.

Coordination happens through a Task object passed between client and server agents. Tasks support three patterns: synchronous request-and-response, Server-Sent Events streaming for incremental output, and asynchronous push notifications for long-running workflows. This matters in customer service, where some sub-tasks complete in milliseconds while others, such as a refund approval, may take minutes.

• Agent Card: A JSON contract that advertises the agent's skills, input formats, and authentication scheme, enabling capability discovery without custom documentation.
• Task lifecycle: Tasks move through states from submitted to working, then to completed, failed, or cancelled, giving orchestrators visibility into what each agent is doing at any moment.
• Opacity: Agents collaborate without sharing internal memory, proprietary logic, or tool configurations, protecting intellectual property and limiting blast radius if one agent is compromised.
• Complementarity with MCP: The A2A protocol handles agent-to-agent coordination; the Model Context Protocol (MCP) handles agent-to-tool connectivity. In practice, a well-designed multi-agent system uses both.

Why the A2A protocol matters for customer experience

Modern customer service involves tasks that cross functional boundaries. A customer calling about a delayed shipment might trigger lookups in a logistics system, a refund decision in a billing system, and a follow-up message in a CRM. Each of those actions could be handled by a specialist agent. The A2A protocol provides the connective layer that lets an AI agent orchestration layer route sub-tasks to the right specialist and aggregate the results into a coherent response, all within a single customer interaction.

The protocol also improves resilience. Because tasks carry explicit state and each agent publishes its own contract, a failure in one agent does not require rebuilding the entire integration. An orchestrator can detect a failed task, log it for AI observability review, and either retry with the same agent or route to an alternative. That kind of graceful degradation is difficult to achieve with ad-hoc integrations.

Limitations are real. The A2A protocol is still maturing; early adopters report that consistent Agent Card versioning across large vendor ecosystems requires governance discipline. The protocol also does not address model-level concerns such as prompt injection or hallucination, so teams must layer AI guardrails on top. And because agents collaborate without revealing internal state, debugging cross-agent failures can be harder than debugging a single monolithic agent.

Deploying A2A in a production support environment

Teams adopting A2A typically start by mapping which parts of their support workflow genuinely benefit from specialist agents, since the protocol adds coordination overhead that is not worth paying for simple single-step tasks. Authentication and identity verification, order management, and AI agent handoff to human representatives are common first candidates. Agent Cards should be versioned from the start, and changes to a card's skill schema should go through the same review process as an API change. Monitoring task-level state in a centralized log is essential for diagnosing latency and failure patterns across an agent graph. For a broader look at how agentic architectures are reshaping support operations, see the Google A2A announcement and specification.

For a deeper dive, download Decagon's guide to agentic AI for customer experience.