Multi-agent AI systems are moving from demos to production, and with that shift comes a practical question: how do agents talk to each other, to tools, and to the infrastructure around them? Three protocols have emerged with distinct answers. Anthropic's Model Context Protocol (MCP) addresses how a model connects to external tools and data sources. Google's Agent-to-Agent protocol (A2A) tackles discovery and task delegation between agents. IBM's Agent Communication Protocol (ACP), developed through the BeeAI project, focuses on structured inter-agent messaging.

Each protocol encodes assumptions about what agents are, what they need, and where the coordination boundaries lie. For anyone working on multi-agent architectures or thinking about the formal properties of protocols, understanding these differences is essential. The protocols are not competing to solve the same problem. They occupy adjacent regions of the design space, and the gaps between them tell you as much as the protocols themselves.

The sections below cover the problem space these protocols address, the design and mechanics of each protocol, a comparison of their assumptions, and an analysis of what formal methods can offer for verification and interoperability.

The problem space

A single LLM behind an API endpoint is simple to integrate. It accepts a prompt and returns a completion. But the moment you introduce tool use, multi-step reasoning, or multiple agents collaborating on a task, the interaction model becomes substantially more complex. An agent needs to discover tools and invoke them. Multiple agents need to find each other, agree on sub-tasks, exchange intermediate results, and handle failures. Across organisational boundaries, questions of identity, capability advertisement, and trust arise.

No single protocol covers all of these layers. Traditional distributed systems solved analogous problems with separate protocols for service discovery, RPC, messaging, and orchestration. The agent ecosystem is recapitulating this pattern, but with the added complication that the participants are non-deterministic and their execution plans are constructed at runtime. The three protocols discussed here each address a slice of this stack.

Model Context Protocol (MCP)

MCP, released by Anthropic in late 2024 and refined through 2025, defines a standard interface between a language model (the client) and external tools or data sources (the servers). Its core abstraction is the tool: a typed function that the model can invoke during a conversation.

An MCP server exposes a set of tools, each described by a JSON Schema specifying its inputs and outputs. The model's runtime discovers available servers, reads their tool descriptions, and presents them to the model as part of its context. When the model decides to use a tool, the runtime issues a structured request to the server, receives a response, and feeds it back into the model's context for the next reasoning step.

The transport layer is deliberately simple. MCP uses JSON-RPC over stdio for local servers and HTTP with Server-Sent Events for remote ones. There is no complex service mesh or message broker. This simplicity is a design choice: MCP is meant to be easy to implement on the server side, lowering the barrier for tool providers.

  • Scope MCP is about tool integration, not agent-to-agent communication. It assumes a single model (or agent) as the client and one or more tool servers. The protocol does not define how multiple agents coordinate.
  • Session model An MCP session is stateful but linear. The client connects, discovers tools, makes calls, and disconnects. There is no branching protocol, no concurrent sub-sessions, and no negotiation between peers. This is closer to a client-server RPC pattern than to a conversation between equals.
  • Typing Tool inputs and outputs are typed via JSON Schema. This provides structural type checking at the interface but does not capture behavioural properties like ordering constraints or resource protocols. In the language of [session types](/notes/formal-methods/session-types-protocols/), MCP describes the payload types but not the session structure.

MCP's strength is its adoption. Because it is simple and well-documented, dozens of tool providers have implemented MCP servers. This creates a practical ecosystem even though the protocol itself is narrow.

Agent-to-Agent protocol (A2A)

A2A, introduced by Google in early 2025, addresses a different problem: how do agents find each other, describe their capabilities, and delegate tasks? Where MCP connects an agent to tools, A2A connects agents to other agents.

The protocol defines an Agent Card, a JSON document that an agent publishes to describe itself. The card includes the agent's name, capabilities, supported input and output formats, and an endpoint URL. Other agents or orchestrators discover these cards and use them to decide which agent to delegate a sub-task to.

Task delegation follows a request-response pattern with streaming support. The delegating agent sends a task (with a description and optional input artefacts) to the target agent, which processes it and returns results. A2A supports long-running tasks through a polling or streaming model, and it defines status transitions (submitted, working, completed, failed) that the caller can track.

  • Discovery Agent Cards are the discovery mechanism. They can be hosted at well-known URLs, registered in directories, or exchanged directly. This is analogous to service discovery in microservice architectures but with richer capability descriptions tuned for natural-language task routing.
  • Task lifecycle A2A defines a task as a first-class object with an identifier, a status, and a history of messages. This gives both parties a shared reference for the delegated work, which is important for systems where tasks take minutes or hours rather than milliseconds.
  • Opaque agents A2A treats agents as black boxes. The protocol does not prescribe how an agent processes a task internally. It only defines the external interface. This is a deliberate interoperability choice: any framework (LangChain, CrewAI, AutoGen, custom) can implement the A2A interface.

A2A fills a gap that MCP leaves open. But it inherits the coordination challenges of any asynchronous delegation protocol. Error handling, timeouts, and partial results all require careful treatment at the application level because the protocol itself defines only the message structure, not the recovery semantics.

Agent Communication Protocol (ACP)

ACP, developed by IBM through the BeeAI open-source project and announced in early 2025, takes a messaging-first approach to inter-agent communication. Where A2A models delegation as task assignment, ACP models it as structured message exchange.

ACP defines a message format that includes content (text, files, structured data), metadata (sender, recipient, conversation identifier), and type annotations. Agents communicate through an ACP-compatible runtime that handles routing, delivery, and conversation tracking. The protocol supports both synchronous and asynchronous interaction patterns, with conversations as first-class entities that maintain multi-turn context.

  • Messaging model ACP's core abstraction is the message, not the task. This is a lower-level primitive that can express tasks, queries, notifications, and multi-turn conversations. The tradeoff is flexibility versus convention: ACP is more expressive but requires agents to agree on higher-level interaction patterns themselves.
  • Runtime dependency ACP assumes an ACP-compatible runtime that manages agent lifecycle, message routing, and conversation state. This is different from MCP's lightweight client-server model and A2A's peer-to-peer approach. The runtime provides guarantees (message ordering, delivery tracking) but introduces a platform dependency.
  • Composition ACP is designed with agent composition in mind. Agents can be wired together into pipelines or graphs through the runtime, with the runtime managing the message flow. This aligns with [component-based system design](/notes/component-systems-bip/) where connectors define how components interact.

ACP's messaging model is familiar to anyone who has worked with message-oriented middleware. The agent-specific additions (conversation tracking, content-type awareness, capability descriptions) adapt the pattern for AI workloads.

Comparing design assumptions

The three protocols rest on different assumptions about what an agent system looks like.

MCP assumes a hub-and-spoke topology: one agent at the centre, tools at the edges. It does not model agent-to-agent interaction at all. This makes it clean for single-agent tool use but insufficient for multi-agent coordination.

A2A assumes a network of autonomous agents that discover each other and delegate tasks. It models agents as opaque services with advertised capabilities. This is well-suited to heterogeneous systems where agents from different vendors or frameworks need to interoperate at the task level.

ACP assumes a runtime-managed ensemble of agents that communicate through structured messages. It models agents as components within a managed environment. This is well-suited to systems where the operator controls the full agent topology and wants strong guarantees about message delivery and conversation state.

The protocols are not mutually exclusive. A plausible production architecture uses MCP for tool integration within each agent, A2A for cross-boundary task delegation, and ACP for tightly coupled agent ensembles within a single platform. Interoperability between the three is currently limited. Bridging layers will emerge, but they will introduce translation overhead and potential semantic loss, particularly around error handling and partial results.

Formal properties and verification prospects

From a formal methods perspective, these protocols raise interesting questions about what can be specified and verified.

MCP's tool interface is structurally typed via JSON Schema, enabling basic conformance checking. But MCP does not specify behavioural properties: there is no formal statement of call ordering, preconditions, or invariants. In session types terms, MCP defines the message payloads but not the protocol automaton.

A2A's task lifecycle defines a state machine (submitted, working, completed, failed), which is a step toward formal specification. The transitions between these states could be expressed as a behavioural contract or a session type, allowing verification that both parties follow the expected protocol. However, the content of tasks and results is untyped at the protocol level, so semantic conformance remains outside the protocol's scope.

ACP's messaging model, with conversation identifiers and message ordering, is closest to the kind of structured interaction that session types capture well. A conversation in ACP is essentially a session, and the sequence of message types exchanged during a conversation could be expressed as a session type. The BeeAI runtime's role as a message broker also creates a natural enforcement point for protocol conformance.

None of the three protocols currently includes a formal specification in a machine-checkable language. Their specifications are prose documents with JSON Schema fragments. This is typical for early-stage protocols and it limits what can be verified automatically. A client that sends structurally valid JSON-RPC to an MCP server might still violate implicit ordering assumptions. An A2A agent that transitions tasks through the correct state machine might still send semantically invalid results.

The opportunity is to layer formal specifications onto these protocols as they mature. Specs, invariants, and contracts are a natural fit: preconditions for tool calls, invariants for task state, contracts for message exchange patterns. Whether the protocol communities adopt such specifications will depend on whether the tooling makes verification cheap enough to be practical in production, not just in research.

For teams building multi-agent systems today, the practical takeaway is to treat protocol boundaries as trust boundaries. Validate inputs and outputs at each protocol crossing. Log the full interaction sequence, not just the final result. And recognise that the current protocols define message formats more than they define correct behaviour. The gap between format conformance and behavioural correctness is where most production incidents will live.

Related notes

Back to topic • Back to Notes index