What is agent-to-agent communication? Protocols, gaps, and runtime

• Protocols define contracts. They do not run delivery, recovery, routing, or policy.

• A2A covers interop. It gives agents cards, tasks, messages, and streaming.

• MCP covers tools. It is useful, but not peer-agent communication.

• Handoffs lose more than text. Context, authority, and ownership all need to be explicitly carried.

• Production needs a runtime layer. Registry, routing, delivery state, and recovery sit underneath the agent framework.

Existing protocols give agents a way to speak. They do not decide who should listen, whether the message arrived, or who may act on the result.

That distinction sounds pedantic until the first incident. A2A can describe the task. MCP can expose a tool. Neither gives your SRE a durable answer to "where did the work stop?"

I think of this less as chat and more as service communication. HTTP did not remove the need for gateways, retries, queues, identity, or observability. Agent-to-agent communication protocols fall within the same family. They are useful because they reduce the need for custom contracts. They are insufficient because contracts do not operate systems.

What "communication" actually requires in production

A demo needs a request and a response. Production needs the surrounding record:

• Routing. Which agent, or which replica of an agent, should receive the message?

• Delivery tracking. A per-message lifecycle so the caller knows whether a message arrived, is still in progress, or failed.

• Durability. State that survives a crash, a redeploy, or a dropped streaming connection mid-task.

• Policy. A record of which agent may invoke which peer, with evidence after the fact.

If those pieces are part of the prompt instructions, you do not have a communication infrastructure. You have a convention.

The protocol-vs-runtime gap

One clean exchange becomes a different system once it turns into a chain. The second handoff may lose context. The third may blur status. By the fourth, an agent may be acting with authority that nobody meant to pass along.

The protocol can still be correct. The system can still fail.

Retries, backpressure, idempotency, state restoration, and audit all live outside the message format. The same issue appears in multi-agent orchestration, but agent communication is the narrower surface on which the failure first becomes visible.

Discovery is where the fantasy of "agents just call each other" meets the reality of deployment.

An agent cannot delegate to a peer it cannot find. It also cannot safely delegate to a stale endpoint that previously pointed to the right peer last week. Current systems usually handle discovery through capability descriptions, registries, or a mix of both.

Agent cards and capability discovery

An agent card is a machine-readable description of an agent, including its name, capabilities, endpoint, and authentication requirements. A2A standardizes that shape.

This is real progress. It gives a calling agent something better than tribal memory or a teammate's README.

The card still has a shelf life. If the agent scales, moves regions, changes owners, or is promoted from staging, the card does not magically become a runtime directory. A static endpoint inside a nice schema is still a static endpoint.

Registry-based discovery (@handle)

A registry provides agents with stable identities that persist across deployment moves. Instead of wiring Agent A to a fixed URL, the caller addresses @fraud-checker or asks for a capability. The registry resolves the current participant.

That sounds mundane because it is infrastructure. Mundane is good here. Production systems need fewer clever prompts and more boring names that keep working after a redeploy.

The A2A protocol is a serious attempt to standardize interoperability among peer agents. Google announced A2A in April 2025 with support from more than 50 technology partners. The Linux Foundation later took stewardship, and by April 2026 the protocol had support from more than 150 organizations.

For platform teams, the specific adoption figures matter less than the direction of travel. Agent vendors are converging on a neutral task contract because custom pairwise contracts do not scale across product and company boundaries.

The buyer's mistake is reading "standard" as "platform." A2A does the contract work. It leaves the operating model to the surrounding system. Miss that boundary and the standard becomes a backlog generator.

What A2A standardizes

Per the A2A specification, the protocol defines four things:

• Agent cards for capability discovery.

• Task lifecycle for create, update, and complete.

• Message format with parts and artifacts.

• Streaming over Server-Sent Events (SSE).

Those primitives solve a real interoperability problem. A LangGraph agent, a custom service, and a vendor agent should not all require different private contracts for the same kind of delegation.

What A2A leaves to the implementer

A2A is point-to-point by design. Agent A sends a task to Agent B, and the protocol defines the shape of that exchange.

The operating questions remain outside the spec. Who chooses the receiving agent when there are replicas? Which policy allows the call? What survives if the receiver crashes after accepting the task? How does the caller learn whether the work is processing, has failed, or is safe to retry?

A2A also does not give you multi-agent coordination, context segmentation, operational dashboards, or audit trails. Adopt it anyway if you need cross-vendor contracts. Just do not treat the protocol as the runtime.

MCP belongs in this article because people keep putting it in the wrong box.

The Model Context Protocol provides one agent with a standard way to access tools, data, and context: file systems, APIs, databases, and internal services. It is useful. It is also agent-to-tool infrastructure, not peer agent communication.

What MCP solves (tool/context access)

MCP standardizes how one agent pulls in external capabilities. The agent acts as the MCP client. Tools and data sources expose MCP servers. The session starts on the client side.

The MCP documentation frames the protocol as a means of connecting models to context. That framing is precise. It gives an agent controlled access to the resources it needs while working.

Why MCP is not agent-to-agent

The structure does not match peer communication:

• It is client-initiated. An MCP server answers when called. It does not behave like a peer capable of starting its own delegation.

• It can bloat context. Anthropic's Code execution with MCP article reported that presenting MCP tools through code execution reduced token usage from 150,000 to 2,000, a 98.7% reduction. The practical lesson is plain: even tool metadata can swamp a context window, so using MCP as an agent conversation layer makes the wrong problem bigger.

You can wrap MCP with state, identity, callbacks, and routing. Teams do that kind of thing when the deadline is close. At that point, you are building agent-to-agent semantics around a tool protocol, and you should call the extra layer what it is.

Context loss rarely looks dramatic. The receiving agent just sounds a little too confident about the wrong version of the task.

Inside one agent, context is whatever sits in the running conversation, memory, tool output, and local state. Across a boundary, somebody has to decide which parts travel. If that decision is implicit, the system will make it badly.

The handoff-as-transition problem

A handoff changes ownership. Agent B does not inherit Agent A's working memory because the prompt said: "continue."

The receiving agent needs the task, the relevant decisions, the current constraints, and the reason the work moved. Without that, it can execute the literal request and still miss the point. This is how you get a locally correct answer inside a globally broken workflow.

Per-agent context segmentation

Sending everything to every agent feels safe until the agents start reading each other's noise.

Segmentation works better. Each agent gets the slice it needs for its role, plus the prior result it must honor. Mention-based routing makes that boundary visible: an agent processes a message when it is addressed and stays quiet when it is not. That keeps shared context from turning into a broadcast channel where every agent has to read every message.

Delegation moves permission with the work.

When Agent A asks Agent B to act, the system has to know which authority is associated with the task. Otherwise, every downstream call becomes an assumption, and assumptions make terrible security models.

Explicit vs. implicit authority

Implicit authority starts with convenience. Agent B can do what Agent A could do. Then Agent C inherits the same reach because no one had reason to stop the chain during the demo.

Explicit delegation forces the scope into the handoff: this agent may invoke that one for this task within these limits. The same discipline keeps a human in the loop for decisions that deserve review, rather than approving only the first hop and hoping the later ones behave.

Identity and audit across delegation

Explicit authority needs agent identity. Shared credentials erase the actor, which makes the audit trail almost decorative.

A useful record captures the full chain: who delegated, who accepted, what context moved, which tools ran, what failed, and which result came back. If the post-incident question is "who told this agent to wire the funds," a prompt trace is not enough.

BAND is the product section, so read it as product fit rather than neutral protocol analysis. It sits in the layer this article keeps circling back to: the runtime around the protocol.

The agentic mesh provides agents with a shared interaction layer beneath frameworks. Agents register once, are routed by handle or capability, and communicate through a control plane that records delivery, recovery, and governance events. A2A and MCP still keep their jobs. BAND handles the operating surface around them.

Registry, routing, and delivery tracking

BAND focuses on the parts that usually become scattered glue code:

• Agent registry. Framework-agnostic registration with ownership and discoverable @handle routing.

• Mention-based routing in [ChatRooms](https://docs.band.ai/core-concepts/chat-rooms). Agents share context but process only messages addressed to them, with per-agent segmentation to hold down token load.

• Delivery lifecycle and recovery. A delivered -> processing -> processed/failed state per message, with WebSocket reconnect, REST backlog sync, deduplication, and state restoration.

That is the difference between seeing "Agent B was called" and knowing whether Agent B accepted, processed, failed, retried, or recovered after a disconnect.

Native A2A support (outbound adapter + inbound gateway)

BAND supports the A2A protocol directly. The outbound A2A adapter lets BAND agents delegate to external A2A endpoints while tracking task state back in the room. The inbound A2A gateway exposes BAND agents as A2A-compliant endpoints, allowing external agents to call in.

Use A2A for the peer contract. Use MCP for tool access. Add an interaction runtime when agents have to route, recover, delegate, and stay governed across frameworks or teams. If your system is still using one local agent-calling tool, this layer is early. If agents already pass work across runtimes, evaluate the runtime before the next missing handoff turns into incident archaeology. The BAND docs cover the adapter setup, and the demo path is useful when you want to test routing and delivery lifecycle against your own agent topology.