With 150+ organizations and production deployments across Google Cloud, Azure, and AWS, the A2A Protocol has emerged as the open standard for agent-to-agent coordination. Here is what enterprise architects need to know about the protocol that completes the agentic mesh.
In April 2026, the A2A Protocol reached version 1.0 with more than 150 supporting organizations, production deployments across supply chain and financial services, and native integration into Google Cloud, Microsoft Azure, and AWS. A2A is not a replacement for MCP. It is the missing coordination layer that turns isolated agents into a true agentic mesh. This article breaks down what A2A actually delivers, how it complements existing standards, what changed in v1.0, and the enterprise architecture patterns that make multi-vendor agent networks practical, secure, and governable.
For the past year, enterprise agent architecture has been defined by MCP. The Model Context Protocol gave agents a standard way to discover and call tools, query databases, and access documents. It solved the agent-to-tool problem so completely that every major platform — OpenAI, Google, Microsoft, Anthropic — now supports MCP servers. But tools are only half the picture. The other half is agents talking to each other.
In a real enterprise deployment, a customer support agent should be able to delegate a billing investigation to a finance agent, a sales agent should be able to request a credit check from a risk agent, and a procurement agent should be able to negotiate delivery windows with a supplier's agent. These are not tool calls. They are peer-to-peer negotiations between autonomous systems with different owners, different data, and different objectives.
Before A2A, every one of these handoffs required a custom integration. The support team built a webhook. The finance team exposed an API. The supplier sent CSV files. The result was the same integration spaghetti that plagued pre-microservice enterprise IT, except now the participants were autonomous agents rather than human users. The agentic mesh architecture we have described requires agents to share context, tools, and data across organizational boundaries. MCP handles the tools and data. A2A handles the sharing. Without it, the mesh is a collection of silos connected by fragile point-to-point glue.
The A2A Protocol, originally announced by Google in April 2025 and now hosted by the Linux Foundation, defines a simple but powerful model for agent-to-agent interaction. The core primitive is the Agent Card: a JSON document that an agent publishes to advertise its capabilities, input requirements, output formats, authentication methods, and pricing if applicable. Think of it as a machine-readable business card combined with an API specification. When an agent needs help, it queries a directory or registry for Agent Cards matching its need, selects the most appropriate peer, and initiates a task.
The task itself is a structured conversation. The requesting agent sends a Task object with a description and optional artifacts. The receiving agent can accept the task, reject it, request clarification, or negotiate scope. During execution, the receiving agent streams status updates, and upon completion returns the result with attached artifacts and a completion status. This is fundamentally different from a tool call. A tool call is synchronous and deterministic: you send parameters, you get a result. An A2A task is asynchronous and negotiated: you propose work, the peer evaluates whether it can and should do it, and the two agents may iterate before reaching agreement.
For enterprises, this negotiation layer is critical. An agent cannot simply invoke another agent the way it calls a calculator function. The second agent may be owned by a different department with different data access rights, different compliance obligations, and different capacity constraints. A2A makes these boundaries explicit rather than hiding them behind an API abstraction.
A common misconception is that A2A and MCP are competing standards. They are not. They operate at different layers of the agent communication stack, and a complete enterprise agent architecture in 2026 uses both.
MCP connects agents to tools and data sources. It answers the question: "What can this agent do with the resources available to it?" The protocol is client-server: an agent (the client) connects to an MCP server that exposes tools, resources, and prompts. The agent calls tools, reads resources, and uses the results in its reasoning. MCP is optimized for low-latency, high-frequency interactions where the agent needs immediate access to structured capabilities.
A2A connects agents to other agents. It answers the question: "What can this agent accomplish by collaborating with peers?" The protocol is peer-to-peer: agents discover each other, negotiate tasks, and exchange results. A2A is optimized for cross-boundary, multi-turn interactions where autonomy, identity, and trust matter as much as functionality.
The relationship is analogous to the difference between a function call and an email. MCP is the function call: precise, immediate, local. A2A is the email: structured, asynchronous, cross-organizational. An agent uses MCP to query a database, generate a report, and calculate a forecast. It uses A2A to send that forecast to a planning agent in another department, negotiate assumptions, and receive a revised plan. One protocol does not replace the other. Together they complete the stack.
The initial A2A release in 2025 was a promise. The v1.0 specification, released in April 2026, is a production contract. Three changes matter most for enterprise adoption.
First, Signed Agent Cards. In v1.0, every Agent Card must be cryptographically signed, enabling identity verification and trust establishment before any task is exchanged. This means an enterprise can publish an agent to a public or shared registry and every peer that interacts with it can verify who built it, what organization operates it, and whether the signature chain is valid. For regulated industries, this is not a convenience feature. It is a prerequisite for compliance.
Second, enterprise multi-tenancy. The v1.0 specification defines how agents operate within tenant boundaries, how cross-tenant delegation works, and how data isolation is maintained when agents from different organizations collaborate. This enables service providers to host agent marketplaces and enterprise platforms to offer internal agent exchanges without compromising security boundaries.
Third, protocol negotiation and backward compatibility. A2A v1.0 agents can negotiate which protocol version to use, which authentication flows to apply, and which capability subsets to enable. This means an enterprise can upgrade its agent fleet gradually rather than replacing everything in a single cutover. The migration path from early A2A pilots to v1.0 production is defined and tested.
These changes moved A2A from an experimental protocol to a deployable standard. The evidence is in the adoption numbers: 150 organizations, integration into Azure AI Foundry, Copilot Studio, Amazon Bedrock AgentCore Runtime, and production deployments in supply chain, insurance, and financial services.
Production A2A deployments in 2026 are converging on three architecture patterns. The internal agent marketplace is the most common. An enterprise deploys multiple specialized agents — HR, finance, legal, sales, operations — each with its own Agent Card in a private registry. Other agents and human users discover these agents and delegate tasks through A2A. The orchestration layer is minimal because negotiation happens directly between peers. This pattern works best for large organizations where departmental agents already exist and need to interoperate without centralizing control.
The cross-vendor workflow is the second pattern. An enterprise uses agents from multiple vendors: a customer service platform from Salesforce, a document processing service from Google Cloud, a compliance agent from a specialty provider. A2A enables these agents to discover each other and coordinate on shared workflows without the enterprise building custom integrations for every pairwise connection. The vendor ecosystem handles the protocol compliance, and the enterprise benefits from composability.
The supply chain network is the most ambitious pattern. Organizations expose agents to their partners and suppliers through A2A, enabling automated procurement negotiations, logistics coordination, and inventory reconciliation. Because A2A tasks include structured artifacts and status tracking, multi-party workflows that previously required human account managers and weekly email cycles can execute in minutes with full audit trails. Early adopters in manufacturing and retail report 40-60% reduction in procurement cycle times.
Each pattern depends on the same foundational infrastructure: a registry for Agent Cards, authentication and authorization for cross-boundary task delegation, and monitoring for task status and exceptions. Enterprises building these foundations in 2026 are positioning themselves to scale rapidly as the agent ecosystem matures.
When agents from different vendors, departments, or organizations negotiate tasks, the security model cannot rely on perimeter defenses. The perimeter vanished the moment the first agent called a peer outside its own process boundary. A2A v1.0 addresses this with a capability-based security model built on four controls.
Identity verification through Signed Agent Cards ensures that every participant in a task can be cryptographically identified. This is the foundation: if you do not know who the other agent is, you cannot decide whether to trust it.
Task-level authorization ensures that even after identity is established, the receiving agent evaluates whether the requester is authorized for the specific task being requested. An agent may be willing to share public pricing with anyone but unwilling to share cost structures without a signed NDA recorded in its authorization policy.
Artifact scoping controls what data is attached to a task and who can access it. A2A tasks carry artifacts — documents, data extracts, calculation results — and the protocol defines how these artifacts are encrypted, how access is delegated, and how expiration is enforced. This prevents the casual data leakage that happens when agents exchange more context than necessary.
Auditability through structured task logs ensures that every negotiation, every status update, and every result transfer is recorded in a format that compliance systems can ingest. For enterprises subject to SOC 2, GDPR, or industry-specific regulations, this audit trail is not optional. It is the evidence that autonomous systems are operating within defined boundaries.
The principle is the same one we advocate for all agent governance: begin with almost no ambient authority and grant permissions explicitly, task by task, artifact by artifact. A2A's design embodies this principle at the protocol level.
Organizations beginning A2A adoption in 2026 should follow a phased approach that builds interoperability incrementally without requiring a full agent fleet rebuild. Days 1-30: inventory and catalog. Identify every agent currently deployed or planned in your organization. For each agent, define its capabilities, inputs, outputs, and ownership. Publish internal Agent Cards for the most mature agents in a private registry. Do not worry about external interoperability yet. The goal is to create visibility.
Days 31-60: connect two agents. Select a workflow that requires handoff between two internal agents — for example, a sales qualification agent delegating to a proposal generation agent, or a support triage agent escalating to a billing investigation agent. Implement A2A task negotiation between these two peers, with authentication, status tracking, and artifact exchange. Measure latency, reliability, and task completion rates. This single connection teaches your team more about the protocol than any amount of documentation.
Days 61-90: add a third agent and a governance layer. Introduce a third agent that can receive tasks from either of the first two, creating a small mesh with routing choices. Implement task logging and audit trails. Define authorization policies that restrict which agents can delegate to which peers. Test failure modes: what happens when an agent is offline, when a task times out, when an artifact is rejected. By the end of 90 days, you will have a working three-agent mesh with governance, observability, and documented runbooks.
This is not a pilot that gets thrown away. It is the foundation for scaling to ten agents, then fifty, then the full enterprise mesh. The organizations that start now will have a year of operational experience by the time A2A becomes a default requirement in vendor RFPs.
In 2025, enterprises evaluated AI platforms on model quality, prompt engineering tools, and basic orchestration. In 2026, the evaluation criteria have expanded. The question is no longer just "How good is the model?" but "How well does this platform connect to the rest of my agent ecosystem?" A platform that supports MCP but not A2A gives agents tools without peers. A platform that supports A2A but not MCP gives agents peers without capabilities. Only platforms that support both protocols enable the complete agentic mesh.
The major cloud providers have recognized this. Google Cloud built A2A and integrated it natively. Microsoft added A2A support to Azure AI Foundry and Copilot Studio. AWS embedded it in Amazon Bedrock AgentCore Runtime. Salesforce, SAP, and ServiceNow have announced A2A-compatible agent platforms. The protocol is becoming as expected as HTTPS for web services or SMTP for email.
For enterprise architects, the implication is clear: agent interoperability is now a platform decision with multi-year lock-in effects. Choosing a vendor that does not support open agent protocols in 2026 is like choosing a cloud provider that does not support REST APIs in 2010. Technically possible, strategically unwise.
The agentic mesh architecture that Extency has described — specialized agents sharing context, tools, and data across organizational boundaries — depends on standardized interoperability. MCP provides the tool and data layer. A2A provides the coordination layer. Together they transform isolated agents into a genuine workforce. The enterprises that build on these standards will scale faster, integrate more easily, and avoid the custom-integration debt that trapped previous generations of enterprise technology. The protocol war is over. The stack is MCP plus A2A. The only remaining question is how quickly your organization adopts it.
May 14, 2026
EngineeringMay 6, 2026
EngineeringMay 5, 2026
Download our free ebook for a comprehensive guide to deploying autonomous AI agents in your organization.
Get the Free Ebook