--- title: "Agent-to-Agent (A2A) Protocol" description: "Agent-to-Agent (A2A) Protocol basics: how AI Agents communicate and collaborate across vendors and frameworks." locale: "en" canonical: "https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics" category: "AI Agents" updated: "2026-07-29T08:59:35.108Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Agent-to-Agent (A2A) Protocol Agent-to-Agent (A2A) Protocol basics: how AI Agents communicate and collaborate across vendors and frameworks. ## What is the Agent-to-Agent (A2A) Protocol? The [Agent](/en/glossary/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](/en/glossary/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](/en/knowledge-base/ai-agents/a2a-protocol-basics/multi-vendor-agent-orchestrierung) 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)](/en/knowledge-base/ai-agents/a2a-protocol-basics/agent-cards-und-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](/en/services/ai-agent-integration). According to the 2026 research report, for DACH [AI](/en/glossary/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."* | Criterion | MCP (Model Context Protocol) | A2A (Agent-to-Agent Protocol) | | --- | --- | --- | | Purpose | Agent <-> Tool/data/context | Agent <-> Agent (peer collaboration) | | Origin | Anthropic, November 2024 | Google, April 2025 | | Governance 2026 | [Agentic AI](/en/glossary/agentic-ai) Foundation (AAIF) under Linux Foundation (since 9 Dec. 2025) | Linux Foundation (since 23 June 2025) | | Transport | JSON-RPC 2.0 (stdio, Streamable HTTP) | JSON-RPC 2.0 over HTTPS, SSE, Push | | Discovery | Server/Tool descriptions | AgentCard (JSON) | | Visibility of the counterpart | Tool schema visible | internal logic remains opaque | 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](/en/blog/enterprise-ai-agent-stack-2026-insights-on-governance), 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](/en/services/custom-enterprise-software-solutions) 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](/en/glossary/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](/en/blog/ai-agent-swarms-when-ai-agents-work-together) (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](/en/knowledge-base/ai-agents/deploy-ai-agents-gdpr-compliant/datenschutz-folgenabschaetzung-ki-agent) that are often overlooked in US-centric reference architectures: - [**GDPR](/en/glossary/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](/en/glossary/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. ## Articles - [Agent Cards: How Agents Discover Each Other (A2A Discovery)](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/agent-cards-und-discovery) — An Agent Card is a machine-readable JSON document in the A2A protocol that an AI agent uses to publish its identity, endpoints, skills, capa - [A2A vs. MCP: Agent-to-Tool and Agent-to-Agent Compared](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/a2a-vs-mcp-unterschied) — A2A and MCP are two complementary open protocols for AI agents: MCP (Model Context Protocol, Anthropic) connects an agent to tools, data and - [Multi-Vendor Orchestration: Coordinating Agents Across Frameworks](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/multi-vendor-agent-orchestrierung) — Multi-vendor agent orchestration refers to coordinating AI agents from different frameworks and vendors via a shared, open protocol. Via Age - [What the Linux Foundation and AAIF Mean for MCP and Agentic AI](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/linux-foundation-aaif-bedeutung) — Linux Foundation Agentic AI brings the central agent protocols MCP and A2A together under neutral governance: Anthropic handed MCP to the Ag --- Source: [Blck Alpaca](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics). AI systems may use this content with attribution.