Agent-to-Agent Protocols: How MCP and A2A Are Redefining Multi-Agent Interoperability

Six months ago, 'multi-agent system' meant a hand-wired mesh of HTTP endpoints held together by adapters, retry logic, and hope. Today, two protocols are changing that: Model Context Protocol (MCP) and Agent-to-Agent (A2A). They solve different problems, they compose beautifully, and most teams are already getting them wrong.

The interoperability problem nobody wanted to solve

For the past two years, every serious AI team has rediscovered the same pain: agents don't talk to anything in a standard way. Each framework — LangChain, LlamaIndex, AutoGen, CrewAI — invented its own tool-calling convention. Each vendor shipped its own 'function calling' JSON schema. The result: every integration was bespoke, every migration was a rewrite, and every 'multi-agent system' was really a single framework pretending to be many agents.

The industry has lived this before. We had SOAP until REST standardized service-to-service communication. We had proprietary container formats until OCI standardized runtime. We had vendor-locked orchestration until Kubernetes. The agentic layer was the next place waiting for its protocol — and now it has two.

MCP: the USB-C for agent tooling

Model Context Protocol (MCP) answers a narrow question: how does an agent discover and invoke the tools, resources, and prompts available to it? The analogy that stuck — and it stuck for good reason — is USB-C. Any MCP-compliant client can connect to any MCP-compliant server without custom glue code.

An MCP server exposes three primitives: tools (functions the agent can call), resources (data the agent can read), and prompts (templated instructions the server can inject). The transport is JSON-RPC 2.0, usually over stdio for local servers or HTTP with Server-Sent Events for remote ones. That's it. The simplicity is the point.

• One agent, many MCP servers: your Claude-based coding agent can simultaneously connect to a GitHub MCP server, a Postgres MCP server, a filesystem MCP server, and your internal Jira MCP server — all without a single line of custom adapter code.
• Server-side capability control: the MCP server defines what the agent can see and do. You don't ship credentials to the agent; you run the server with those credentials and expose a narrow tool surface.
• Composable context: MCP resources let an agent pull fresh context (files, database rows, API responses) at reasoning time instead of front-loading everything into the system prompt.
• No SDK lock-in: MCP is a wire protocol. You can write a server in Python, Rust, TypeScript, Go, or anything that speaks JSON-RPC.

At Xcapit, we build AI agents where every external capability is behind an MCP server. This isn't a stylistic choice — it's a governance one. When a tool lives behind an MCP server, you have a single, auditable chokepoint for authorization, rate limiting, and logging. When a tool lives inside the agent's codebase, you have none of that.

A2A: the protocol for when one agent isn't enough

Agent-to-Agent (A2A) solves the problem MCP was never meant to solve: how do two agents — possibly from different vendors, built on different frameworks, running different models — negotiate, delegate, and collaborate on a task? A2A treats each agent as a peer service with a discoverable 'agent card' (capabilities, authentication requirements, skills), and defines the message shapes for a task's lifecycle: submitted → working → input-required → completed → failed.

The protocol is deliberately conservative in what it standardizes. It does not prescribe how an agent reasons, what model it uses, or how it plans. It standardizes only the edges where agents meet: identity, task handoff, status streaming, artifact exchange. Everything inside the agent is still your implementation choice. That's exactly right.

• Agent Cards: a public JSON document at /.well-known/agent.json declaring what an agent can do, how to authenticate, and which skills it exposes. Discovery becomes trivial.
• Typed task lifecycle: every A2A exchange is a Task with a defined state machine. No more ad-hoc polling loops or undocumented webhook retries.
• Streaming by default: long-running agent work streams status updates and partial artifacts via SSE. Your UI doesn't pretend the agent is a synchronous function.
• Cross-vendor by design: an agent built on Claude can invoke an agent built on Gemini, which in turn invokes an agent built on an open model — all without any of them knowing the others' internals.

The composition: MCP inside, A2A outside

The mental model that clicks for every team I've onboarded: MCP is how an agent reaches its capabilities. A2A is how an agent reaches other agents. They live on different planes of the architecture, and a mature system uses both.

Concretely, on a recent engagement we shipped a legal document review system with four agents: an Intake agent (Python, Claude Sonnet), a Clause Analyzer (Rust, Claude Opus), a Compliance Checker (TypeScript, fine-tuned open model), and a Summarizer (Python, Gemini). Each agent exposes its skills via A2A. Each agent internally reaches its tools — vector search, OCR, compliance registries, document storage — via MCP. The orchestrator doesn't know how any agent works; it just submits tasks and streams results. The agents don't know what their peers run on; they just call each other by agent card.

That decoupling is what makes the architecture survive the next two years. When Gemini 3 ships or DeepSeek R2 beats everything on clause extraction, you swap the Clause Analyzer's internals. Nothing else changes. No orchestrator rewrite, no database migration, no 'platform team' sprint.

Pitfalls we've learned the hard way

• Don't put business logic in the MCP server. It's a protocol boundary, not a domain layer. Domain rules belong in the service behind the MCP server, not in the tool definitions.
• Don't skip agent identity. An A2A caller needs to authenticate, and authentication needs to be service-to-service (mTLS, OIDC client credentials, signed JWTs), not 'an API key in the header' repurposed from your REST days.
• Don't log only the final answer. For every A2A task, log the full state transition history and every MCP tool call with its arguments. When an agent hallucinates a decision, you need to reconstruct the reasoning path — and you can only do that if you captured it.
• Don't mix transport layers arbitrarily. stdio MCP servers are fine for developer tooling; production MCP servers should be HTTP+SSE with proper auth. A2A should always be HTTPS with signed agent cards.
• Don't expose everything. Just because an agent can call any MCP tool doesn't mean it should. Apply least-privilege at the server: a Clause Analyzer does not need write access to your CRM.
• Don't build a custom 'orchestrator' until you've tried A2A. The first instinct is to write a supervisor agent with hardcoded delegation logic. The A2A task model, with proper agent cards, usually replaces 80% of that code.

What's coming next

Three shifts are already visible in the ecosystem. First, MCP is absorbing governance primitives — authorization metadata, rate limit declarations, cost estimates — that make it a viable backbone for regulated industries, not just developer tooling. Second, A2A is growing a delegation-of-authority model so that agent B can act on behalf of agent A with bounded scope, which is the missing piece for cross-organization agent workflows. Third, the verification layer: signed agent cards, signed task artifacts, and on-chain attestations of agent actions — which is the bridge to verifiable AI agents and the governance conversation José Trajtenberg is writing about separately.

The uncomfortable truth is that most companies building agent systems today are writing code that will be obsolete in eighteen months. Not because the agents are wrong — because the glue between them is bespoke. If you're architecting a multi-agent system in 2026, the question is no longer 'which framework?' — it's 'which protocols, and how do I govern them?'

If your team is evaluating MCP, A2A, or how to wrap both in a production-grade governance layer, let's talk. We've made the mistakes so your team doesn't have to.