A2A protocol: enterprise agent-to-agent interoperability

In April 2025, Google Cloud announced the A2A (Agent2Agent) protocol at Google Cloud Next, presenting it as an open standard for AI agent interoperability across vendors and frameworks. The launch announcement listed more than 50 partner organisations from the enterprise software ecosystem. At April 2026, A2A is the most credible candidate for a cross-vendor inter-agent communication standard, but its enterprise consequence depends on adoption decisions that are still being made.

What follows is a working analysis of A2A: what the protocol actually does, how it differs from MCP, where it sits in the 2026 vendor landscape, and the procurement implications for enterprises selecting agent platforms in the next 12-18 months.

What A2A specifies

A2A defines a protocol for agent-to-agent communication. The specification covers four primary concerns:

Capability discovery. Each agent publishes an “agent card” that describes what the agent can do, what inputs it expects, what outputs it produces, and what authentication or trust requirements apply. Other agents query the card to determine whether to delegate a task to this agent. The mechanism is conceptually similar to OpenAPI’s role in REST API discovery; the implementation is JSON over HTTP.

Task delegation. An agent can delegate a structured task to another agent with explicit parameters, expected outputs, and timeout/retry semantics. Delegation can be synchronous (the requesting agent waits for the response) or asynchronous (the requesting agent receives a task ID and polls or subscribes for updates).

Structured message exchange. Inter-agent messages follow a documented schema with explicit fields for sender identity, recipient identity, message type, content, and metadata. The structure makes the inter-agent path uniformly loggable and uniformly enforceable.

Streaming responses. Long-running tasks can stream partial results to the requesting agent via Server-Sent Events. This matters for agentic workflows where intermediate progress is useful to the requester before the full task completes.

The protocol is built on JSON-RPC 2.0 plus Server-Sent Events. The choice of foundation is deliberate: enterprise networks already understand JSON-RPC and SSE; A2A is designed to be deployable through existing API gateways and observability infrastructure rather than requiring new substrate.

The reference implementation and the specification are at the A2A protocol announcement.

How A2A differs from MCP

A2A and MCP address different layers of the agentic AI stack.

MCP (Model Context Protocol) addresses agent-to-tool communication. An agent uses MCP to connect to a database, a search engine, a file system, an enterprise SaaS service, or any external resource. The agent calls the MCP server; the MCP server returns structured data or executes a structured action.

A2A (Agent2Agent Protocol) addresses agent-to-agent communication. An agent uses A2A to delegate to or coordinate with another agent. The requesting agent is the principal; the responding agent operates with its own identity and policy posture and returns results subject to its own constraints.

The boundary between MCP and A2A is structural. An MCP server is a passive component that responds to tool calls without independent agency; an A2A endpoint is an active agent that may take its own actions, may have its own tool surface, and may further delegate to other agents. An enterprise agent system in 2026 typically needs both protocols: MCP for the tool surface and A2A for the inter-agent surface.

The two protocols’ compatibility is also structural. An A2A endpoint’s exposed capabilities can be implemented internally using MCP for the agent’s tool surface; an MCP server is not a substitute for A2A because it lacks the agent semantics. The full MCP analysis is at /mcp-enterprise-agent-tooling/ (claim AM-038).

Why an open inter-agent protocol matters

Three structural reasons make a cross-vendor inter-agent protocol high-leverage for enterprises.

Vendor lock-in reduction. Enterprises increasingly want the option to compose agents from multiple vendors. A code-generation agent from Anthropic, a customer-service agent from Salesforce, a compliance-review agent from a specialist vendor, all coordinating in the same workflow. Without a cross-vendor protocol, this composition requires bilateral integrations that grow combinatorially with the agent count and that vendors have an economic incentive to limit. With A2A, the composition becomes portable across vendor boundaries.

Audit substrate consistency. The 14-field audit substrate from the Article 12 template (claim AM-046) requires uniform logging across the agent surface. A multi-agent system using bilateral vendor integrations produces inconsistent log formats; assembling a regulator-ready audit package requires reconciling the differences. A protocol-standard inter-agent path produces uniformly-formatted logs that populate the substrate fields consistently.

Threat-surface reduction. The cross-agent prompt-injection class (claim AM-045) propagates through inter-agent communication paths. A documented protocol with clear semantics is easier to reason about and to defend than vendor-specific bilateral integrations. Broker-mediated multi-agent patterns (claim AM-049) are structurally easier to implement when the inter-agent format is standard.

The 2026 vendor landscape

The April 2025 launch partner set was broad. The April 2026 commitment landscape is uneven.

Strongly committed. Salesforce, ServiceNow, SAP, MongoDB, Atlassian, Workday, Box, Cohere, Deloitte, Elastic, Glean, Intuit, and others from the original launch partner set have shipped or are shipping A2A support in their enterprise agent platforms. The pattern is consistent: enterprise SaaS vendors with multi-tenant agent capabilities see A2A as a procurement-friendly differentiator and have invested accordingly.

Implicitly aligned. Most agentic-AI-framework projects (LangChain/LangGraph, AutoGen, CrewAI) are A2A-compatible by design or via straightforward extensions. The framework ecosystem’s economic incentive is portability, which aligns with A2A’s positioning.

Notably absent. Microsoft and Anthropic have not publicly committed to A2A as of April 2026. Microsoft’s Copilot platform has its own internal multi-agent primitives optimised for the Microsoft 365 ecosystem; the platform’s economic incentive is ecosystem stickiness rather than cross-vendor interoperability. Anthropic’s Managed Agents include context-isolation primitives that have not been publicly mapped onto A2A; Anthropic’s positioning has emphasised platform-neutrality but with internal primitives rather than committed adoption of the Google-led standard.

Enterprise consequence of the absences. A protocol that includes Salesforce, ServiceNow, and SAP but excludes Microsoft and Anthropic is partially useful: it covers cross-SaaS agent workflows, but it does not cover the most-deployed enterprise agent platforms. The consequence for enterprises is that A2A adoption needs to be planned with the gaps in mind: deployments that include Microsoft Copilot or Anthropic Managed Agents will need bilateral integrations or platform-specific bridges into the A2A surface.

The vendor-comparison piece (claim AM-039) covers the per-vendor positioning in detail; the procurement question for cross-vendor deployments in 2026 is whether the vendor’s A2A commitment matches the enterprise’s interoperability requirement.

Adoption trajectory through 2027

Based on the April 2026 state, the trajectory pattern is similar to MCP’s trajectory but lagged by approximately 12 months.

H1 2026 (current). Specification matures. Reference implementations stabilise. Early-adopter enterprises run A2A in pre-production with launch-partner vendors. Microsoft and Anthropic positioning remains uncommitted.

H2 2026. Specification reaches deployment-grade stability. Production A2A deployments emerge in the launch-partner ecosystem. Microsoft and Anthropic make positioning decisions: either commit, propose alternative, or remain uncommitted. The decision determines the protocol’s enterprise reach.

2027. Widespread enterprise adoption among the launch-partner ecosystem. Procurement processes routinely require A2A support. Cross-vendor agent workflows become a category of enterprise architecture rather than a bespoke integration project.

2028+. A2A or its successor becomes the cross-vendor agent interoperability standard. Enterprise agent stacks with multiple vendors are normal. Bilateral integrations become legacy.

The trajectory is sensitive to two inflection points. First, the Microsoft-Anthropic positioning decision in late 2026; both committing accelerates the trajectory by approximately 6 months, both holding out delays it by approximately 12 months. Second, the EU AI Act enforcement guidance after 2 August 2026; if regulator guidance on Article 9 risk-management implicitly favours standardised inter-agent paths, A2A adoption accelerates as a compliance-driven choice.

Procurement implications

For agent platform procurement in 2026, A2A is now a question to ask, not yet a requirement to enforce.

The question. “What is your A2A protocol support timeline, including reference-implementation maturity, native support in production deployments, and inter-vendor interoperability test results?” The answer pattern reveals the vendor’s positioning: shipped support, committed roadmap with dates, evaluating, no commitment.

The decision. For deployments going into production in 2026 that are single-vendor or contained, A2A is a watch item not a requirement. For deployments planning cross-vendor extensions or going into production in late 2026 and beyond, A2A support from each participating vendor should be a procurement requirement. The transition point is approximately Q4 2026; deployments past that point should expect A2A as the cross-vendor standard.

The risk-management documentation. Capture the A2A maturity assumption in the deployment’s Article 9 risk-management documentation. If the protocol’s trajectory shifts (Microsoft commits, Anthropic commits, the protocol stalls, a competitor emerges), the deployment’s risk profile changes and the documentation needs to update. The 60-day review cadence on the deployment captures the trajectory check.

What A2A does NOT solve

The protocol addresses inter-agent communication. It does not address:

• Inter-agent trust. A2A provides the format; the trust framework (which agents should be allowed to delegate to which, with what scope, under what circumstances) is the deploying enterprise’s responsibility. The seven-control surface from claim AM-043 still applies.
• Inter-agent semantics. A2A standardises the message format, not the meaning. Two A2A-compatible agents that interpret the same task differently still produce inconsistent results; the protocol makes the inconsistency visible but does not resolve it.
• Inter-agent regulatory scope. When an A2A delegation crosses organisational or jurisdictional boundaries, the data-residency, contract-binding, and liability-allocation questions are not solved by the protocol. The cross-organisational federated agent pattern needs additional regulatory thinking that A2A enables but does not provide.

The full state of enterprise agentic AI is at /state-of-enterprise-agentic-ai/ (claim AM-040). The MCP analysis on the parallel agent-to-tool layer is at /mcp-enterprise-agent-tooling/ (claim AM-038). The multi-agent architecture playbook that A2A’s adoption strengthens is at /multi-agent-architecture-playbook/ (claim AM-049).

A2A’s enterprise consequence is not the protocol itself. It is what the protocol makes possible: portable cross-vendor multi-agent workflows with uniform audit substrate and a common defence against the cross-agent prompt-injection class. The 2026 trajectory is the watch item.