A2A + MCP: two protocols, one interoperability layer

The agentic AI world has been quietly converging on two protocols. MCP (Model Context Protocol), originally from Anthropic, now under the Linux Foundation's Agentic AI Foundation, handles how agents connect to tools and data. A2A (Agent-to-Agent), launched by Google in April 2025 with over 50 technology partners, also Linux Foundation, handles how agents talk to each other.

Different problems. But they'll eventually need to work as one system. If you're building multi-agent architectures today, you need to understand where each protocol ends and the other begins.

What each protocol actually does

MCP is a client-server protocol for agent-to-tool communication. An MCP server exposes tools (executable functions), resources (read-only data), and prompts (reusable templates). An MCP client, whether that's Claude Desktop, an IDE, or your custom application, connects to the server and makes these capabilities available to an LLM. Wire protocol is JSON-RPC 2.0 over stdio or HTTP.

The key design choice: the LLM decides when to use a tool, but the server defines what the tool does. The agent owns the decision-making; the server owns the execution. (If you're connecting to community MCP servers, the security implications of this trust model are worth reading about in MCP security: every unvetted server is an attack surface.)

A2A is peer-to-peer. Where MCP connects an agent to a tool, A2A connects an agent to another agent. The interaction model is different in kind. Instead of calling a function and getting a result, an agent submits a Task to another agent, and that task moves through a lifecycle: SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED, FAILED. The protocol is built on HTTP, SSE, and JSON-RPC, so it fits into existing enterprise infrastructure.

A2A also introduces two ideas MCP doesn't have. Agent Cards are machine-readable JSON descriptions of what an agent can do, used for dynamic discovery. Multi-turn negotiation means an agent can request additional input mid-task, so the interaction is collaborative rather than purely request-response. Version 0.3, released in July 2025, added gRPC support and signed security cards.

They're complementary, not competing

People keep framing A2A and MCP as competing standards. They're not. They operate at different layers.

A refund-processing agent might use MCP to connect to the payment API, the inventory system, and the customer notification service. That same agent might use A2A to delegate a compliance check to a specialized Compliance Agent with its own tools and reasoning.

MCP is vertical: agent reaches down to tools. A2A is horizontal: agent reaches across to peers. In production, you need both.

Where they converge

The convergence happens at what we'd call the "workflow boundary." Take a complex enterprise operation: onboarding a new enterprise customer. That involves:

1. Provision infrastructure (DevOps)
2. Configure billing (Finance)
3. Set up user accounts (Identity)
4. Run compliance checks (Legal)
5. Send welcome communications (Marketing)

With a single agent and MCP, one agent connects to all the tools across all five domains and orchestrates everything. This works for simple cases. It falls apart when each domain has dozens of APIs, domain-specific logic, and its own failure modes. The agent's context window fills up with tool schemas before it even starts doing useful work.

With multiple agents and A2A, a coordinator delegates domain-specific tasks to specialists. The DevOps Agent knows infrastructure provisioning. The Finance Agent knows billing. Each specialist uses MCP for its domain's tools. The coordinator uses A2A to orchestrate across agents.

The tricky part is what sits between them. Something needs to know that infrastructure provisioning must finish before billing starts, that the compliance check can run in parallel with account setup, and that if any step fails, the entire operation needs coordinated rollback across all agents.

The missing orchestration layer

Neither protocol solves orchestration. MCP gives agents access to tools. A2A gives agents access to each other. But the knowledge of which tools to call in what order and which agents to coordinate for which tasks lives outside both protocols.

This is the same gap that already exists in MCP-only architectures, just amplified by the multi-agent dimension. Today's MCP servers expose individual API endpoints as individual tools. An agent connecting to a payment platform's MCP server might see 200 tools, every endpoint as a separate function. The agent still has to figure out which 7 of those 200 it needs for a refund, in what order, with what parameter mappings between steps.

Add A2A and the problem multiplies. The coordinator needs to know which specialist handles which domain, what information to pass between agents, how to handle partial failures across agent boundaries, and how to maintain transactional integrity when three different agents have each completed part of a workflow. As we covered in agent memory as a first-class primitive, this structural knowledge — which tools depend on which, what parameters flow where — is exactly what knowledge graphs encode and vector stores can't.

Workflow knowledge — how multi-step processes actually work, encoded as validated execution paths with real dependency ordering — is what makes both MCP and A2A useful in production. Without it, MCP is a toolbox without instructions. A2A is a phone system where nobody knows who to call. (We keep coming back to this analogy because it's unfortunately accurate.)

Building for the convergence

If you're designing agent architectures today, here's what I'd prioritize:

Separate workflow knowledge from protocol implementation. Your understanding of "how to process a refund" shouldn't be embedded in MCP tool definitions or A2A agent configs. It should exist as its own layer, protocol-agnostic. When A2A adoption matures, the same workflow knowledge powering your MCP-based execution should power your A2A-based coordination without a rewrite.

Design around domain boundaries. Find the natural seams in your business processes, the points where one team's expertise ends and another's begins. Those seams will become agent boundaries in a multi-agent architecture. Each domain agent uses MCP for its tools, A2A for coordination with peers.

Invest in transactional guarantees now. Multi-agent coordination makes the transactional integrity problem harder, not easier. The Saga pattern, where each forward action has a defined compensation action, works across both single-agent and multi-agent setups. Building this into your workflow execution layer now saves you from retrofitting it when A2A coordination introduces cross-agent failure modes.

Both protocols are going to matter. The teams that handle the convergence well will be the ones who built the workflow knowledge layer that sits between them, the layer that knows what needs to happen regardless of which protocol carries the messages.

Hintas's workflow knowledge layer is protocol-agnostic by design. Today it deploys as a single MCP server. A2A support for multi-agent orchestration is on our roadmap, powered by the same validated knowledge graph. More at hintas.ai.

Photo by GuerrillaBuzz on Unsplash