Agent Communication Protocols: A2A, ACP, MCP Explained

Multi-agent systems aren't complicated APIs. They're distributed systems in which autonomous, non-deterministic processes delegate and negotiate work with one another, often across organizational boundaries, with no shared runtime and no guaranteed ordering. General-purpose REST APIs were designed for human callers. An agent communication protocol has to solve an entirely different class of problems.

Agent Identity Doesn't Work Like Service Identity

In a conventional microservices architecture, identity is resolved at the gateway. A service authenticates once, and the infrastructure handles the rest. Agents operate differently: they initiate tasks, spawn subagents, negotiate mid-execution, and surface results asynchronously, sometimes hours after the original request. At each handoff, the receiving agent needs to know not just who's calling, but what that caller is authorized to delegate, which capabilities it's advertising, and which trust context it carries.

Authentication mechanisms designed for stateless API calls don't carry that context. A dedicated agent communication protocol has to encode identity, capability scope, and delegation authority as first-class fields in every message, not as metadata bolted onto an HTTP header.

Capability Negotiation at Runtime

What makes the agent-to-agent communication protocol problem genuinely hard is the discovery step. When agent A needs to delegate a subtask, it can't rely on a static service registry compiled at build time. Agents get deployed, updated, and retired continuously. The protocol must support runtime capability advertising so that agents can locate peers with the right skills, negotiate what those peers can actually do, and establish a shared task contract before work begins.

Without structured capability negotiation, multi-agent systems degrade into brittle point-to-point wiring, where every new integration requires a custom adapter and every agent update risks breaking downstream consumers.

Asynchronous Execution at Scale

Long-running agent tasks entirely break the synchronous request-response model. A task delegated to a research, code-generation, or procurement agent may take minutes or hours to complete. The orchestrator needs to suspend, receive incremental status updates, handle partial failures, and resume, all without holding an open connection.

What is agent communication protocol design without asynchronous execution as a core primitive? Incomplete. Ad hoc integration at scale produces cascading failures: one stalled agent blocks an entire delegation chain, and without a structured protocol layer, there's no standardized way to detect the failure, reroute the task, or surface the state to a human operator who needs to intervene.

Three protocols emerged between late 2024 and mid-2025 to address distinct layers of the multi-agent stack. They reflect different design priorities, sponsoring organizations, and assumptions about where the hardest problems in agent communication actually lie.

Google's Agent2Agent protocol targets peer-level agent coordination: how independent agents discover each other, negotiate tasks, and exchange structured work across vendor boundaries. Donated to the Linux Foundation in June 2025 with support from more than 100 organizations, A2A has rapidly established itself as the leading open standard for agent-to-agent communication protocol design at enterprise scale.

IBM Research built the ACP agent communication protocol to solve a narrower but equally pressing problem: how agents running inside heterogeneous enterprise environments exchange multimodal messages through a REST-native interface without requiring framework alignment. In August 2025, IBM and Google announced that ACP's development would converge with A2A under the Linux Foundation's LF AI & Data umbrella, with ACP's stateful workflow concepts being contributed directly into A2A.

Anthropic's Model Context Protocol operates at a different layer entirely. MCP standardizes the vertical connection between an LLM and the tools, data sources, and APIs it needs to act on, rather than the horizontal coordination between peer agents. Where A2A governs what agents say to each other, MCP governs what an agent can reach.

Mapping all three protocols against each other, before examining any one in depth, clarifies what an agent communication protocol can specify and what it can't.

None of the three is infrastructure on its own. Each one defines a message format and a transport mechanism, the equivalent of a network protocol rather than the network itself, which means an organization still has to build or buy the layer that actually runs, connects, and governs the agents speaking that protocol.

A2A's core design premise is that agents from different vendors, running on different infrastructure, should be able to collaborate without exposing their internal implementation. The protocol achieves interoperability at the communication boundary, not through shared runtimes or framework alignment.

Agent Cards: The Capability Advertisement Layer

Every A2A-compliant agent publishes an Agent Card, a JSON document served at a well-known endpoint (/.well-known/agent-card.json). The card declares the agent's identity, its supported capabilities, accepted input modalities, authentication requirements, and the endpoint URL where it receives tasks. Agent Cards are how the agent-to-agent communication protocol solves the discovery problem without a centralized directory: any client agent can fetch the card, parse the capability manifest, and, before sending a single task message, determine whether the target agent can actually handle the work.

Capability declarations inside an Agent Card aren't freeform strings. They follow a structured schema that enables programmatic matching, allowing an orchestrator agent to evaluate multiple candidate agents against a task requirement and select the most appropriate peer at runtime.

The Task Model and Message Threading

A2A structures all agent work around a Task object. When a client agent sends a task, the server agent immediately returns a task ID, decoupling submission from execution. The task progresses through a defined state machine: submitted, working, input-required, completed, failed, canceled, rejected, and auth-required. Each state transition can carry an accompanying Message object containing structured Parts, each of which holds typed content: text, files, or structured data blobs.

Message threading in A2A flows through a turn-based exchange within a single task context. The client and server agent exchange turns, and the server agent can request additional input mid-task by moving the task into the input-required state. The input-required state lets a server agent pause a task and request a specific piece of missing information, but it stops short of a sustained, multi-turn exchange. A2A's threading model is still built around delegation and a returned result, not an open conversation where either side can ask follow-up questions at will.

Streaming and Long-Running Task Execution

For long-running tasks, A2A uses Server-Sent Events to stream incremental updates to the client agent without requiring the client to maintain an open bidirectional connection. The client subscribes to a task's event stream and receives status updates, partial artifact delivery, and completion signals as the server agent works. Artifacts, A2A's term for task outputs, get streamed in chunks, which matters when the output is a large document, a generated codebase, or a multimodal composite.

Push notifications via webhook are also part of the spec, allowing the client agent to register a callback URL and receive task state transitions asynchronously, even across network interruptions.

What A2A Deliberately Leaves Open

A2A specifies the communication contract between agents. It doesn't specify what agents do with the tasks they receive, how they store intermediate state, how they log execution history, or how human operators get visibility into what's happening across a delegation chain.

The protocol also leaves governance entirely out of scope. Agent Cards support OAuth 2.0 scopes for authentication, but A2A has no native mechanism to enforce approval gates, audit cross-agent decisions, or escalate to a human when an agent encounters a task that exceeds its delegated authority.

That threading limitation compounds the governance gap. An agent that can't ask a clarifying question mid-task also can't easily surface a partial result for review, flag an ambiguous instruction, or negotiate scope with the agent that delegated the work. Each of those requires a sustained, two-way exchange that the task and state-machine model doesn't provide.

For enterprise deployments, those omissions aren't edge cases. A procurement agent delegating a purchase order to a fulfillment agent across an org boundary needs more than a completed task object returned over SSE. It needs a traceable record of who authorized the delegation, what constraints applied, and whether a human approved the scope before execution began. That's the layer the protocol deliberately hands off to infrastructure above it, which is precisely where the agent interaction control plane operates, providing governance, auditability, and human-in-the-loop coordination across A2A-connected agent networks.

The ACP agent communication protocol was built to solve a problem that A2A's peer-to-peer model leaves largely unaddressed: how do agents running inside heterogeneous enterprise environments, where frameworks differ, modalities vary, and infrastructure teams control the network perimeter, exchange structured messages without requiring every participant to adopt a shared runtime? IBM Research designed ACP around the constraints of enterprise IT, not the assumptions of cloud-native agent platforms. In August 2025, ACP's development converged with A2A under the Linux Foundation.

REST-Native Design and the Three-Role Architecture

ACP operates through three defined roles:

1. The Agent Client, which initiates requests

2. The ACP Server, which functions as a registry and message broker

3. The ACP Agent, which receives and processes tasks.

Every interaction flows through the ACP Server, giving the architecture a brokered topology rather than the direct peer-to-peer model A2A uses.

All communication happens over standard HTTP. ACP has no proprietary transport, no persistent connection requirement, and no binary protocol layer. For enterprise environments where firewall rules, reverse proxies, and API gateways already govern service-to-service traffic, dropping ACP into existing infrastructure requires minimal network reconfiguration.

Multipart MIME Messaging for Multimodal Agents

Where A2A structures task content through typed Part objects, ACP uses multipart MIME messages, the same format underlying HTTP file uploads and email attachments. Each message can carry multiple content parts in a single request: text, structured JSON, binary files, images, and audio, all within one envelope.

The practical advantage is that an ACP-compliant agent doesn't need to negotiate content type before receiving a message. The receiving agent parses the multipart body and handles each part according to its declared MIME type. For enterprise use cases where agents process documents, images, and structured data simultaneously, such as a contract review agent receiving a PDF alongside metadata and a routing directive, the multipart model reflects how real enterprise payloads actually look.

Synchronous and Asynchronous Execution Modes

ACP supports both synchronous and asynchronous execution within the same protocol. For short-lived tasks, the client sends a request and receives the response in a single HTTP exchange. For long-running tasks, ACP returns a run ID immediately and allows the client to poll for status or to register for streaming updates via Server-Sent Events. This pattern is structurally similar to A2A's streaming model.

The ACP agent communication protocol also defines an explicit agent registration mechanism. Agents advertise their capabilities to the ACP Server on startup, and the server maintains a live registry that clients query before dispatching tasks. Compared to A2A's Agent Card model, where discovery is decentralized and card-fetching is the client's responsibility, ACP's centralized registry is well-suited to organizations that already operate internal service catalogs and want agent discovery to integrate with existing governance tooling.

That registry-centric design reflects a broader architectural philosophy: in enterprise environments, centralized visibility matters as much as distributed execution. An AI governance standardization approach aligns directly with this, extending registry-level visibility into a full interaction control plane where agent authority, approval chains, and audit trails are managed alongside the communication layer itself.

MCP operates at a different layer than A2A or the ACP agent communication protocol. While those two govern how agents communicate horizontally across a network, MCP governs the vertical connection between a single LLM-powered agent and the external systems it needs to act on. Before MCP, every tool integration was bespoke: developers connecting an LLM to a database, a code execution environment, or an internal API wrote custom glue code for each connection, with no shared contract for how the model would discover available tools, invoke them, or receive structured results. MCP replaces that fragmentation with a typed, auditable interface.

The Client-Host-Server Architecture

MCP organizes its participants into three roles.

1. The Host is the application containing the LLM, whether that's an IDE, a chat interface, or an agent runtime.

2. The Client is a component within the Host that manages connections to one or more MCP Servers.

3. The Server is a lightweight process that exposes tools, resources, and prompt templates to the Client.

A single Host can maintain connections to multiple MCP Servers simultaneously, each providing a distinct capability surface. One server might expose file system access, another a SQL query interface, and a third a set of REST API wrappers. The LLM running inside the Host sees all of these as a unified, queryable tool registry, with the MCP Client handling connection management, capability aggregation, and result routing.

Tool Registration, Resources, and Prompt Primitives

MCP defines three primitive types that servers expose to clients. Tools are executable functions that the LLM can invoke, with JSON Schema definitions specifying input parameters and return types. Resources are read-only data objects that the server makes available to the LLM for reference without invoking a function, such as file contents, database records, or configuration state. Prompt templates are reusable instruction structures that standardize how the LLM formulates requests for specific task types.

All communication between Client and Server flows over JSON-RPC 2.0. For local servers, MCP uses stdio as the transport. For remote servers, it uses Streamable HTTP, introduced in the protocol's 2025 revision. The typed schema system means every tool invocation carries verifiable input and output contracts, making MCP interactions substantially more auditable than prompt-based tool calls embedded in free-form LLM output.

Where MCP Sits in a Multi-Agent Architecture

In a production multi-agent system, MCP and A2A typically operate at different layers within the same agent. The agent uses A2A externally to receive delegated tasks from peer agents and return results. Internally, it uses MCP to access the tools and data sources it needs to complete those tasks.

MCP's scope is intentionally narrow: tool access and context injection for a single agent instance. It doesn't address how multiple agents coordinate, how task authority gets delegated across an org boundary, or how a human operator gets visibility into what an agent decided to do with the tools it accessed.

MCP's request-response pattern also assumes a single host pulling information on demand. It has no native mechanism for a server to push a live update to a client mid-task, which becomes a real constraint once an agent needs to stay synchronized with peers or systems that change state independently of its own requests.

For organizations running agent networks at scale, that visibility gap compounds quickly when agents access sensitive systems or chain tool calls across multiple MCP servers in a single execution. Look for a platform that sits above the protocol stack, providing the interaction layer where tool access decisions become observable and governable. Teams coordinating coding agents that rely on MCP-connected development tools can see how that governance layer integrates in practice through this coordinating coding agents use case.

Most production architectures end up combining protocols rather than selecting one, so the real question is which combination fits your system and where each protocol's responsibility boundary sits.

Map Your Agent Topology First

Start with the shape of your system. If your agents run inside a single application boundary and need structured access to tools, databases, and APIs, MCP is the foundational layer. It's the right agent communication protocol for the vertical connection between an LLM and its capability surface, and it's mature enough to deploy today across local and remote servers.

If your system involves multiple independent agents coordinating across vendor or team boundaries, delegating tasks to one another, and returning structured results asynchronously, A2A addresses the horizontal coordination layer. With support from more than 100 organizations and Linux Foundation stewardship, A2A is the agent-to-agent communication protocol with the broadest ecosystem commitment for cross-boundary work.

If your organization runs heterogeneous agent frameworks inside an enterprise perimeter, where teams operate different stacks, and central IT governs the network, ACP's REST-native brokered architecture fits naturally into existing API gateway infrastructure. Given ACP's convergence with A2A, new implementations should track A2A's roadmap and adopt ACP concepts through A2A's evolving spec rather than building on ACP as a standalone standard.

Match Protocol to Environment

Cloud-native environments with flexible networking and modern identity infrastructure align well with A2A's decentralized Agent Card discovery and OAuth 2.0 trust model. Enterprise environments with centralized service registries, strict network segmentation, and existing API management tooling align better with ACP's brokered topology, or with A2A deployments that add a centralized discovery layer on top.

Latency-sensitive workflows, where a synchronous response is required within a bounded time window, fit MCP's stdio transport for local tool calls or ACP's synchronous execution mode for short-lived agent tasks. Long-running delegation chains, where tasks take minutes to hours and require incremental status updates, fit A2A's SSE-based streaming and push-notification model.

The Composability Decision

The most practical guidance for selecting an agent communication protocol in a real architecture is to treat MCP and A2A as complementary defaults. An agent uses A2A to receive and delegate tasks across its peer network and, internally, to access the tools it needs to complete those tasks. ACP-derived concepts, particularly stateful workflow management and multimodal messaging, will increasingly appear in A2A's specification as the convergence progresses.

Use the following checklist to confirm your protocol stack before committing to an implementation:

• Agent needs tool/API/data access within a single runtime: MCP

• Agents coordinate across vendor or team boundaries: A2A

• Enterprise perimeter with centralized API governance: ACP or A2A with brokered discovery

• Long-running async tasks with incremental output: A2A with SSE streaming

• Multimodal payloads across heterogeneous frameworks: ACP multipart messaging, converging into A2A

• Short-lived synchronous task execution: ACP sync mode or MCP tool call

• Cross-org delegation with audit requirements: A2A plus a governance layer above the protocol

That last point is where the checklist ends and the infrastructure gap begins. No protocol in the current landscape natively enforces approval gates, maintains delegation audit trails, or surfaces agent decisions to human operators in real time. That's why our agent interaction control plane sits above the protocol stack and precisely handles those requirements, whether your architecture runs on A2A, MCP, both, or includes agents that predate any formal protocol adoption. For enterprise teams standardizing agent governance across multiple frameworks, this AI governance standardization use case shows how that layer integrates with existing protocol deployments.

A2A, ACP, and MCP collectively cover a lot of ground: capability discovery, task delegation, tool access, multimodal messaging, and asynchronous execution. What they don't cover is a coherent set of structural gaps that every serious multi-agent deployment eventually runs into. The gaps aren't oversights. They reflect a deliberate division of responsibility: protocols define communication contracts, and the infrastructure above them handles everything that requires judgment, authority, and accountability.

Cross-Agent Trust Has No Shared Standard

Every agent communication protocol handles authentication differently. A2A uses OAuth 2.0 scopes declared in Agent Cards. ACP uses bearer tokens managed through its central registry. MCP delegates trust entirely to the Host application. None of the three protocols defines a shared trust model that carries across all three layers simultaneously.

In a production system where an agent uses A2A to receive a delegated task, MCP to execute tool calls, and returns results through an ACP-compatible broker, trust is re-established at every boundary. The receiving agent has no native way to verify that the original delegation came from an authorized human, that the scope of the task matches what was actually approved, or that the chain of custody from the initiating user to the executing agent remains intact.

For organizations operating agents across business units or external partners, trust fragmentation is a governance liability, not a configuration detail. Securing the communication channel itself, so that messages between agents can't be intercepted, spoofed, or rerouted, is a separate problem from deciding what any given agent is authorized to do once it's in the conversation. Protocols leave both questions open.

Auditability Stops at the Protocol Boundary

A2A produces task state transitions. MCP produces tool invocation records. ACP produces run IDs and message logs. Each protocol generates artifacts that record what happened within its own scope. None of them produces a unified audit trail that spans the full execution path from human intent to agent action to system outcome.

Regulated industries require exactly that kind of end-to-end traceability. When an agent makes a consequential decision, such as approving a vendor, modifying a production configuration, or routing a customer case, the audit record needs to capture the full context: who initiated the task, which agent received it, what tools it accessed, what it decided, and whether a human reviewed any step in that chain. Protocol-level logs don't assemble that record. Something above the protocol layer has to.

Human-in-the-Loop Coordination Has No Protocol Home

A2A's input-required task state signals that an agent needs more information to continue. It doesn't specify what kind of input, from whom, through what interface, or with what authority. MCP has no equivalent primitive at all. The ACP agent communication protocol's synchronous execution mode supports immediate responses but lacks a structured mechanism to escalate a decision to a human approver mid-execution.

Human-in-the-loop coordination, where an agent pauses a delegation chain, surfaces a decision to a human operator, waits for an explicit approval, and resumes with that approval recorded, requires an orchestration layer that sits above all three protocols and understands the semantics of authority, not just message passing.

The Agentic Mesh as the Missing Layer

Our Agentic Mesh addresses these gaps as infrastructure, not as application logic bolted onto individual agents. The Agentic Mesh makes long-running agent work visible across the full execution lifecycle, while the Agent Interaction Control Plane enforces delegation authority, manages approval workflows, and maintains the audit record that spans protocol boundaries. That's distinct from acting as a security layer. The Agentic Mesh makes agent communication observable, and the Control Plane makes delegation accountable, but enforcing what any individual agent is permitted to access still belongs to identity and access management systems built for that purpose.

For enterprise teams building on top of A2A and MCP today, the practical implication is that protocol compliance gets you interoperability, and interoperability is necessary. Governance, auditability, and human coordination require a shared interaction layer that treats those concerns as first-class infrastructure requirements, not afterthoughts. That's the architectural gap we were built to close, and it's where the Band ecosystem connects with the frameworks, protocols, and platforms teams are already running.