Multi-Agent Communication Protocols: How Agents Talk to Each Other

• A multi-agent communication protocol defines addressing, capability discovery, message format, task state, delivery acknowledgment, and authority between independent agents.

• A2A specifies agent cards and a task state machine, then leaves routing, durability, and cross-organization identity to the implementer.

• ACP defines a REST interface with agent manifests, runs, and multimodal message parts, and was merged into A2A in August 2025.

• MCP is designed primarily for connecting agents or host applications to tools, resources, and prompts rather than for peer-to-peer agent delegation.

• A2A can escalate an authorization request up a task chain, but it acquires the credential out of band.

• BAND adds an agent registry, mention-based routing, delivery tracking, and governance above A2A and ACP, rather than replacing either.

Communication is the hard part because every agent can be locally correct while the workflow is globally wrong. Nothing throws. The container just never gets booked.

Across three companies, there is no shared runtime, no guaranteed ordering, and no team that can read all the logs. Agents also get redeployed, renamed, and swapped mid-quarter, and callers find out late.

The failures I keep running into are not routing bugs. They are missing agreements. Two teams agreed on a message shape and never agreed on what happens when the receiver crashes halfway through, or whether the shipper's agent could commit money on a customer's behalf. So agent-to-agent communication design should start from requirements.

A production multi-agent communication protocol AI architecture has to cover eight things, whether they come from the protocol itself or the runtime around it.

1. Addressing. A stable peer identity that survives redeployment.

2. Capability discovery. A machine-readable statement of what a peer accepts and returns, fetched before work is sent.

3. Message semantics. Typed content with declared formats, so a PDF, a JSON payload, and an instruction stay distinct.

4. Task state. A shared vocabulary for work in progress, so both sides mean the same thing by "waiting on input".

5. Delivery acknowledgment. Evidence the receiver processed the work, not just that a transport call succeeded.

6. Error and retry semantics. Rules for idempotency and duplicates when a first attempt may have partially run.

7. Authority propagation. The scope the caller was granted, carried with the message so the receiver can check it.

8. Identity across organizations. Verifiable identity when agents operate behind different identity providers.

The first four are message-design problems, and the specs handle them well. The last four are runtime and trust problems.

Three specifications get named in almost every architecture review, and agent communication protocols cover them in depth. Short version of each.

A2A. Google's Agent2Agent protocol gives every agent a JSON agent card at a well-known URL declaring identity, skills, input modes, and auth requirements. Work is a task moving through named states, with streaming updates over Server-Sent Events. It moved to the Linux Foundation in June 2025.

ACP. The Agent Communication Protocol emerged from the BeeAI project as a REST-native standard: agent manifests, runs, sessions, an await primitive for pausing mid-run, and MIME-typed parts for multimodal payloads. Its repository was archived in August 2025, and ACP now continues inside A2A, so treat it as a design source rather than a build target. BAND's ACP integration notes cover where those semantics land at runtime.

MCP. Search "MCP multi-agent communication protocol," and you get pages filing it alongside the other two. But MCP serves a different architectural role. The Model Context Protocol connects agents or host applications to tools, resources, and prompts; it is not designed as a peer-oriented agent delegation protocol.

Heterogeneous means two things at once: mixed frameworks and mixed organizational ownership. Scored against the eight requirements, with partial credit where earned:

The last two rows are not my opinion. ACP's own roadmap page lists identity federation, access delegation, multi-registry discovery, and governance as open questions rather than settled parts of the spec. A2A does better: an agent needing approval moves its task to auth-required, and a client that is itself an agent passes the request further up, forming a chain. What travels is the request, not the grant. Credentials still arrive out of band, and each server writes its own authorization logic.

Read the table by column, and each protocol looks reasonable. Read it by row and the pattern shows: the industry standardized what agents say and left what happens next to the implementer. The customs agent can parse a message perfectly and still not know whether the shipper could commit that budget.

Pick the interoperability protocol, then design the runtime separately. Multi-agent communication protocol tools sit in three layers, and confusing them is where architectures go wrong:

• Specs define the contract. A2A and ACP live here.

• SDKs and adapters implement it for one framework, such as the ACP Python client or a LangGraph adapter.

• Runtimes carry what no spec covers: registry, routing, persistence, recovery, and policy.

• Evaluating multi-agent communication protocol tools therefore means identifying which of these three layers each tool actually covers.

Four rules follow: use a durable agent registry, track delivery per recipient, define idempotency before enabling retries, and record approvals independently of the protocol exchange.

None of that argues against A2A. It argues that a contract needs somebody to enforce it.

BAND fills that runtime layer above the protocols, providing shared discovery, routing, delivery state, and governance across agent stacks.

Agent cards are tied to endpoints, so BAND's Agentic Mesh gives every agent an owner, a discoverable handle, and a visibility scope in a framework-agnostic registry, and callers address the handle instead of a URL. When every agent in a shared room reacts to every message, duplicate work follows, so mention-based routing has an agent act only when addressed.

A sent message is not a completed handoff, so BAND tracks a per-recipient status for every message, from delivered through processing to processed or failed, with an attempt history behind it. Delegation across an org boundary runs on bilateral consent: agents in different organizations become reachable only through an approved contact request, and either side can revoke instantly. For A2A agents you cannot modify, an adapter connects them without a rewrite.

BAND is not a protocol, does not replace A2A or MCP, and is not an LLM eval suite. It runs and governs the agents that speak those protocols. If your agents already talk and you still cannot answer who authorized what, that is what the BAND platform is built for. Book a demo and bring your worst cross-org handoff.