AI Agent Interoperability Standards: MCP, A2A, ARD, and the Path to a Unified Agent Ecosystem

The Tower of Babel Problem

The AI agent ecosystem has a communication problem. Thousands of specialized agents exist, each capable of remarkable things within their domain. But they cannot talk to one another. A financial-analysis agent built on one platform cannot coordinate with an inventory-management agent running on another. The result is brittle data silos, fragmented workflows, and a massive loss of compounding value.

Just as HTTP and REST standardized web communication and unlocked decades of innovation, an emerging layer of open agent communication protocols is doing the same for AI. Major technology vendors—Google, IBM, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP—are actively building these standards, and the space is consolidating under the Linux Foundation. This guide explains the protocols that matter in 2026: what they do, how they differ, and how to architect systems that use them together.

Table of Contents

The Problem: Agents Without a Common Language

Before protocols, connecting an agent to a tool meant writing custom integration code for every pairing. Connecting five agents to ten tools required up to fifty bespoke integrations, each a maintenance liability. Connecting agents built by different vendors on different models was even worse—essentially impossible at scale.

The industry needed standards for three distinct problems:

1. How does one agent reach the systems it needs? (agent-to-tool)

2. How do two agents that don't share a codebase work together? (agent-to-agent)

3. How does an agent find the right capability in the first place? (discovery)

These are fundamentally different questions requiring fundamentally different answers. The industry has responded with a layered protocol stack, each layer addressing one of these problems.

Model Context Protocol (MCP): The USB-C for AI Tools

MCP is the standard for model-to-tool communication. Originally developed by Anthropic in November 2024, it has become the de facto standard for connecting AI applications to data sources, tools, and services.

How MCP Works

MCP uses a client-server architecture over JSON-RPC. An MCP server exposes a defined set of tools, resources, and prompts that any compliant client can call. Tools and data sources either run inside or connect via API to the MCP server, which advertises its capabilities via standard input/output (stdio) for local resources, HTTP, or server-sent events (SSE) for remote resources.

Think of MCP as the wiring between a single agent and its hands: a CRM, a database, a Slack workspace, an internal API. By mid-2025, the community had built thousands of active MCP servers, with pre-built servers for systems like Google Drive, GitHub, Postgres, and Slack.

MCP 2026: A Major Evolution

The July 2026 release candidate represents the largest revision of the protocol since launch. The headline change is that MCP is now stateless at the protocol layer. A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection can now run behind a plain round-robin load balancer. The initialize/initialized handshake is removed; each call is now a single self-contained request that any server instance can handle.

Other key changes include:

  • Extensions Framework – Server-rendered UIs through MCP Apps and long-running work through the Tasks extension
  • Authorization Hardening – Alignment with OAuth and OpenID Connect deployments
  • Formal Deprecation Policy – Enables protocol evolution without breaking existing implementations

What MCP Does Not Do

MCP does not let two independent agents coordinate. An MCP server exposes tools to a client. It has no concept of a peer agent with its own goals, its own model, and its own authority to act.

If your procurement agent needs your finance agent to approve a payment, MCP has nothing to say about that conversation. The finance agent is not a tool to be called; it is an actor with its own reasoning, its own access controls, and its own right to refuse. That is a horizontal problem requiring a different protocol.

Agent2Agent Protocol (A2A): Cross-Vendor Agent Collaboration

A2A is the open specification for cross-vendor AI agent communication. Originally introduced by Google in April 2025 and donated to the Linux Foundation, A2A defines how agents discover each other, publish agent cards, negotiate capabilities, exchange messages, and manage long-running tasks across different runtimes.

How A2A Works

Each agent publishes an "Agent Card"—a JSON file that outlines the agent's capabilities. Other agents query that card to decide what work to delegate. The protocol assumes the agents on either side were built by different teams, run on different infrastructure, and may have different status semantics.

A2A carries long-running task IDs and partial-result streams. Unlike a simple REST API, instrumenting only the request/response edges misses most of the failure surface. The protocol includes:

  • Agent Cards – Capability discovery and negotiation
  • Messages – Structured message exchange
  • Task Lifecycle – Long-running task semantics
  • Authentication – Delegated, tenant-scoped auth

The ACP Consolidation

In August 2025, IBM Research and Google announced that IBM's Agent Communication Protocol (ACP) would join forces with A2A under the Linux Foundation's LF AI & Data umbrella. ACP development is winding down; its assets and expertise are being contributed directly to A2A. Kate Blair (IBM Research, who led ACP) joined the A2A Technical Steering Committee alongside representatives from Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP.

For developers, this consolidation produces a clear division of labor: MCP for model-to-tool communication, unified A2A for agent-to-agent communication.

Production Adoption

A2A crossed 150 supporting organizations and reached production-grade enterprise adoption by April 2026. It is now reaching production adoption across Salesforce, Google Workspace, and Microsoft Copilot ecosystems. Most cross-vendor agent stacks now treat A2A and MCP as the two required protocols.

Agentic Resource Discovery (ARD): The Discovery Layer

Even with MCP for tools and A2A for agent collaboration, a critical gap remains: how does an agent discover that a capability exists in the first place?

ARD is an open specification for publishing, discovering, and verifying AI capabilities across the web. Developed with partners including Microsoft, Google, GoDaddy, and Hugging Face, ARD allows tools and services to be securely shared and connected, regardless of their underlying framework, protocol, or provider.

How ARD Works

ARD relies on two primitives: catalogs and registries.

Catalogs – An organization publishes a catalog describing its available capabilities, hosted directly under the organization's own domain. Ownership of that domain serves as the cryptographic foundation for identity and trust. The catalog describes capabilities including MCP servers, A2A agents, OpenAPI tools, or even other nested catalogs.

Registries – Registries act as search engines for the agentic web. They crawl published catalogs, index their contents, and make them searchable. When an agent submits a discovery request, a registry returns matching capabilities along with the metadata required to verify the publisher and establish trust before connecting.

ARD separates discovery from execution. It answers the discovery question—where is the capability and can it be trusted—then steps out of the way, letting agents connect over each artifact's native protocol.

Many have described ARD as the "DNS for AI agents," and the analogy is apt: it enables agents to find capabilities the way browsers find websites.

MCP vs. A2A: Complementary, Not Competing

Most enterprises still treat these as competing standards. They are not. They sit at different layers of the stack, and a serious agent deployment runs both.

Dimension MCP A2A
Purpose Agent → tool / data source Agent → another agent
Discovery Server resource list Agent Card
Trust Unit Tool scope Tenant + agent identity
Long-Running Less common (now supported via Tasks extension) First-class via task IDs
Auth Model Token, scoped to resource Delegated, scoped to peer

An agentic application might use A2A to communicate with other agents, while each agent internally uses MCP to interact with its specific tools and resources. MCP is about agents using capabilities; A2A is about agents partnering on tasks.

Architecting Systems with the Full Protocol Stack

A production agent stack in 2026 runs all three layers.

The Vertical Layer: MCP

Every agent needs access to tools and data. MCP provides a standardized interface for that access. Your agent connects to MCP servers for databases, business tools (CRM, ERP), repositories, and external APIs.

The Horizontal Layer: A2A

When tasks span multiple agents or organizational boundaries, A2A enables coordination. Your agent uses A2A for cross-platform handoff, multi-team workflows, and vendor-neutral collaboration.

The Discovery Layer: ARD

When an agent needs a capability it doesn't already know about, ARD enables discovery. The agent queries an ARD registry, finds the right capability, verifies trust, and then connects using MCP or A2A as appropriate.

A Practical Example

Consider an enterprise deployment with a Salesforce sales agent and a Google Workspace research agent. The sales agent identifies a prospect and needs market research. It queries an ARD registry, discovers the research agent's Agent Card, and calls it over A2A, passing the prospect's industry and segment. The research agent queries its tools via MCP—search APIs, document repositories, and internal databases—and returns synthesized findings. The sales agent then uses MCP to update the CRM with the research results.

Emerging Standards and Alternatives

Beyond the core three, several emerging standards and alternatives are worth monitoring.

Universal Tool Calling Protocol (UTCP)

Introduced in response to MCP, UTCP takes a simpler approach. Rather than MCP's client-server architecture, UTCP exposes tools and data sources to the model using the tool's native endpoint. It tells the model how to interact with the tool the same way a human would. Proponents argue this is more performant and secure, eliminating the overhead and attack surface of MCP's client-server architecture. Despite this, UTCP remains a niche protocol.

Agentic Resource Discovery (ARD) Draft Specification

ARD is still a draft specification, but it is gaining momentum as the industry recognizes the need for a discovery layer. With partners including Microsoft, Google, GoDaddy, and Hugging Face, ARD has strong industry backing.

AI Agent Interoperable Protocol Framework (AIPF)

The IETF is developing AIPF as a layered framework identifying the key building blocks and protocol suite required for interoperable agent-to-agent communication.

Collaborative Human-Agent Protocol (CHAP)

MCP standardizes agent access to tools and data, and A2A standardizes agent-to-agent interoperability. Neither defines the shared workspace in which humans and agents perform accountable work together. CHAP addresses this gap, defining a protocol for workspaces, participants, tasks, artefacts, and an append-only evidence log.

Autonomous Agent Interchange Format (AAIF)

AAIF is an open, vendor-neutral specification for the portable definition of AI agents. The multi-agent LLM platform ecosystem, as of mid-2026, comprises more than a dozen actively developed frameworks: LangGraph, CrewAI, and the native agent APIs of OpenAI, Anthropic, and Google.

China's National Standards

China has unveiled national standards governing interoperability among AI agents, covering seven core components: overall architecture, identity codes, identity management, agent descriptions, agent discovery, interaction protocols, and external tool invocation.

Security Considerations

Security vulnerabilities continue to dog MCP and other protocols. The OWASP Top 10 for Agentic Applications 2026 outlines the most critical security risks: Agent Goal Hijack, tool use, identity, supply chain, code execution, memory, inter-agent communication, cascading failures, human–agent trust, and rogue agents.

For A2A, the security model is delegated and scoped to peer identity. Each agent must authenticate its peer and authorize the requested action. The Five Eyes nations have issued coordinated guidance specifically for agentic AI deployment, identifying risk categories including privilege escalation, design and configuration flaws, behavioral unpredictability, cascading structural failures, and accountability deficits.

Organizations adopting these protocols should:

  • Implement least-privilege credentials for MCP servers
  • Use isolated sandboxes for tool execution
  • Authenticate all A2A peer connections
  • Maintain replayable audit trails for all interactions
  • Apply input sanitization at every boundary

The Road Ahead

The protocol landscape is consolidating rapidly. From competing specifications, the industry has converged on a layered stack: ARD for discovery, MCP for tool access, and A2A for agent collaboration. This simplifies architectural decisions and accelerates the building of a genuinely interoperable agent ecosystem.

Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026. As agent adoption accelerates, the need for interoperability standards will only grow.

The cross-vendor problem that A2A solves—how to let a Salesforce sales agent invoke a Google Workspace research agent in a different cloud, owned by a different team—is not going away. Without a protocol, the integration is bespoke per pair, and the surface area scales N². With A2A it scales N + 1.

The question is no longer whether to use these protocols. It is how quickly you can adopt them.

Key Takeaways

  • MCP is the standard for model-to-tool communication. It provides a universal interface for agents to access tools, data sources, and services.
  • A2A is the standard for cross-vendor agent collaboration. It enables agents built by different teams on different infrastructure to work together.
  • ARD provides the discovery layer. It enables agents to find capabilities across the web, verifying trust before connecting.
  • The three protocols are complementary, not competing. A production agent deployment runs all three: ARD for discovery, MCP for tools, A2A for agent collaboration.
  • Security must be designed in. MCP has known vulnerabilities; A2A requires delegated authentication. Organizations must implement least-privilege credentials, sandboxes, and audit trails.
  • The industry is consolidating around open standards. The Linux Foundation hosts both MCP and A2A, with broad vendor support including Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP.
  • Protocol adoption is accelerating. Gartner predicts 40% of enterprise applications will feature agents by the end of 2026. Interoperability standards are essential for this vision.

Frequently Asked Questions

What is the difference between MCP and A2A?

MCP connects agents to tools and data sources. A2A connects agents to other agents. They are complementary, not competing, standards.

What is ARD and how does it relate to MCP and A2A?

ARD is a discovery layer that helps agents find capabilities. It sits "in front" of MCP and A2A, enabling agents to discover tools and other agents before connecting to them.

Do I need all three protocols?

For production agent systems, yes—at least in principle. ARD handles discovery, MCP handles tool integration, and A2A handles agent collaboration.

What happened to IBM's ACP protocol?

ACP joined forces with A2A under the Linux Foundation in August 2025. ACP development is winding down; new work should target A2A.

What is an Agent Card in A2A?

An Agent Card is a published JSON description of what an agent can do. Other agents query this card to decide what work to delegate.

References

Comments

Post a Comment