Agent-to-Agent (A2A) Protocol

What is the Agent-to-Agent (A2A) Protocol?

The Agent-to-Agent (A2A) Protocol is an open standard for how autonomous AI Agents communicate with one another - across process, system, platform, and vendor boundaries. While a single Agent accesses Tools, data, and external systems via the Model Context Protocol (MCP), A2A governs the layer above: the collaboration between independent Agents. The central conceptual step of A2A is that it defines how Agents talk, not how they think. The internal logic of a remote Agent - its Prompts, its model, its memory - remains opaque. This is precisely what allows a Salesforce Agent, for instance, to invoke a SAP Agent without either side exposing its internal structures.

A2A was introduced in April 2025 at Google Cloud Next with more than 50 partners and was initially Google-driven. As early as 23 June 2025, Google handed over the specification, the SDKs (Python, TypeScript), and the developer tooling to the Linux Foundation. As a result, A2A is no longer a vendor standard but a vendor-neutral, openly governed standard - a key argument for decision-makers evaluating long-term platform independence.

Agent-to-agent communication: the technical core

A2A deliberately builds on established web standards to keep the barrier to entry low for enterprises. The most important building blocks:

• Transport. JSON-RPC 2.0 over HTTPS. Streaming is handled via Server-Sent Events (SSE); for long-running tasks, optional Push Notifications are provided.
• Task lifecycle. Tasks pass through defined states: submitted -> working -> input-required -> completed | failed | canceled. This explicit lifecycle is the contractual core between two Agents - it makes clear when an Agent is waiting on a follow-up query (input-required) and when a result is available.
• Messages and Artifacts. A2A supports multi-part messages (text plus multimodal content, such as forms). The result of a task is one or more Artifacts.
• Three interaction modes. Synchronous (single request/response), asynchronous polling, and streaming/push for long-running Tasks.

This architecture makes it possible to expose an internal multi-agent flow (such as a LangGraph orchestration with durable state) externally as an A2A endpoint with an AgentCard - the internal and external layers compose cleanly.

Agent Cards and Discovery

The heart of discoverability (Discovery) in A2A is the AgentCard. Every Agent publishes a JSON document describing:

• the endpoint through which the Agent can be reached,
• its capabilities and supported skills,
• the modalities (text, forms, multimodal),
• the supported authentication schemes.

Via the AgentCard, a calling Agent finds out what another Agent can do and how it may address it - without any inside view of its implementation. In practice, the AgentCard is therefore the decisive lever: if a provider publishes an AgentCard for each of its productized Agents, customer systems - Salesforce Agentforce, SAP Joule, Microsoft Copilot Studio - can invoke these Agents from within their own environment without building a customer-specific integration. According to the 2026 research report, for DACH AI agencies this is one of the most important product-strategic levers of all.

One open point for 2026: there are commercial incentives for individual vendors to augment AgentCards with proprietary extensions. The central signal to watch for the portability of A2A is therefore whether the AgentCard remains a portable JSON document or becomes vendor-specific.

A2A vs. MCP: complementary, not competing

The most frequent question from tech leads in the DACH region is: "A2A or MCP?" The answer from the leading providers (Google, Salesforce, Microsoft, IBM) is clear and consistent: both, for different layers. The official formula is: "MCP is for capabilities (agent-to-tool). A2A is for collaboration (agent-to-agent)." Microsoft's own multi-agent guidance puts it operationally: "Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging."

MCP is sometimes also used for agent-to-agent purposes, by exposing an Agent as an MCP "server" with tool-shaped capabilities. This works, but it is not the intended use of MCP - Anthropic, Google, and Microsoft consistently recommend A2A for genuine peer collaboration. In the convergent stack of 2026, the rule is therefore: MCP as the standard for the Tool layer, A2A as the standard for the Agent layer.

The Linux Foundation and the consolidation of the protocol landscape

A2A sits at the center of a remarkable standardization. At the handover to the Linux Foundation on 23 June 2025 (Open Source Summit North America, Denver), AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow were founding members; by now more than 100 companies support the protocol (source: Linux Foundation, 2025). The repository and canonical documentation are located at github.com/a2aproject/A2A and a2a-protocol.org respectively.

This bundling has consolidated the fragmented protocol landscape:

• ACP -> A2A. IBM's Agent Communication Protocol (ACP, March 2025) was merged into A2A on 29 August 2025 under LF AI & Data. The official LF blog: "the ACP team is winding down active development and contributing its technology and expertise to A2A." The design principles of ACP (REST, async-by-default) live on in A2A.
• AGNTCY as an overlay. Cisco's AGNTCY project (donated to the Linux Foundation on 29 July 2025, with Dell, Google Cloud, Oracle, and Red Hat as formative members) is not a competitor to A2A but a layer above it for discovery, identity, and observability. The Open Agent Schema Framework (OASF) explicitly accepts A2A AgentCards and MCP server descriptions as input formats - "A2A agents and MCP servers are discoverable through AGNTCY directories."
• NANDA as a research vision. The MIT Media Lab project NANDA conceptually builds on MCP and A2A, but in 2026 is predominantly research-oriented and not a basis for production architecture decisions.

The honest status in 2026: MCP plus A2A form the convergent industry standard, AGNTCY is the rational add-on where cross-vendor identity matters, and NANDA remains a long-term vision.

A2A in DACH practice: platforms and deployments

For DACH companies, A2A is the inter-agent protocol they encounter most frequently - because their existing Salesforce, SAP, Microsoft, and ServiceNow landscapes are the entry points. Concrete examples from the research report:

• SAP Joule Studio 2.0 / Joule Work (Sapphire 2026, GA Q4 2026): bidirectional A2A, so that third-party Agents can natively invoke Joule Agents and vice versa. For the SAP-heavy DACH landscape, this is, according to the report, the most important multi-agent platform development of 2026.
• Salesforce Agentforce 360 Multi-Agent Orchestration: A2A as the cross-vendor handshake for delegation to third-party Agents; internal handoffs run via the Atlas Reasoning Engine.
• Microsoft Agent 365 / Copilot Studio: A2A support in Work IQ since April 2026.
• Google Agentspace and ServiceNow Now Assist: native A2A and A2A as a cross-platform handshake, respectively.

As a documented DACH flagship, the report names Allianz Project Nemo - a hierarchical seven-agent system (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) for claims cases that went live in under 100 days and achieved an 80% reduction in processing and settlement time for eligible cases (source: Allianz, 2025) - with an explicit Human-in-the-Loop at the payout step.

Compliance and audit (informational, not legal advice)

The following notes are informational and do not replace legal advice. A2A chains have structural compliance consequences that are often overlooked in US-centric reference architectures:

• GDPR DPA chain (Art. 28). Every Agent provider is potentially a processor; multi-agent setups lengthen the DPA chain. Every A2A hop is potentially a separate processor relationship with its own data processing agreement.
• Cross-border transfer (Art. 44-49). With a hybrid Salesforce/SAP/Microsoft/Anthropic stack across US-EU clouds, the rule is: you do not carry out one Transfer Impact Assessment, but one per cross-border agent-to-agent hop. Standard Contractual Clauses (SCCs) and TIAs remain mandatory.
• EU AI Act (high-level). Who is provider and who is deployer in a Salesforce-to-SAP-to-Anthropic A2A composition? The cautious reading: each vendor is the provider of its own Agent, the integrating organization is the deployer of the composed system. This allocation is not yet conclusively settled in 2026; corresponding statements are to be regarded as provisional until implementing acts provide clarity.
• Audit trail. Every A2A message can be audit-relevant. It is recommended to propagate a continuous trace ID through every A2A task and every MCP call, to pin model versions, and to log the AgentCards used. The audit-agent pattern from Allianz Project Nemo is regarded as a DACH-relevant blueprint: auditability belongs in the agent topology, not just in the logging pipeline.

Outlook and practical note

In 2026, A2A has matured from a Google standard into a vendor-neutral, openly governed Linux Foundation project with more than 100 supporters. The structurally strongest safeguard - the Linux Foundation governance - stands against open questions: whether A2A achieves genuine cross-vendor interoperability in production, or fragments through proprietary AgentCard extensions, is the central signal to watch in the coming quarters.

For practice in the DACH region, the pragmatic recommendation is: MCP for Tools, A2A for Agents - anything else is a deliberate deviation from the convergent stack and should be justified. Those acting as a provider or deployer should publish AgentCards, since they are the cross-system contract that determines whether an Agent participates in the 2026 enterprise ecosystem. AGNTCY and NANDA deserve a place on the watchlist but, in 2026, do not belong on the critical path of a multi-agent program. The sensible adoption sequence for large enterprises: first standardize MCP server policy, then introduce A2A within a single platform, subsequently extend to a second one, build an AgentCard registry - and add cross-vendor identity (AGNTCY) only once the volume justifies it.