Agent-to-Agent Communication Protocols: What Actually Ships in Production

Multi-agent systems are no longer a research curiosity. Browser-Use hit 79,000+ GitHub stars 1, MCP implementations crossed 16,400 2, and Google shipped an entirely new protocol called A2A in April 2025 3. Yet the most common question in the NiteAgent community remains deceptively simple: how do agents actually talk to each other?

The answer is messier than the framework marketing suggests. There is no single “agent communication protocol.” There are three distinct layers — tool invocation, task delegation, and message passing — and production systems are converging on different solutions for each.

This post breaks down what ships, where each protocol fits, and how to combine them without over-engineering.

The Three Layers Nobody Tells You About

Most multi-agent architectures fail not because of model quality, but because teams conflate three fundamentally different communication needs:

Tool calling — an agent needs to invoke a capability (search, code execution, API call)
Task delegation — an agent needs to hand off a complete unit of work to another agent
Message passing — agents need to exchange state, context, or negotiate outcomes

MCP handles the first layer. Google A2A targets the second. The third is where things get interesting — and where most teams end up building custom JSON-RPC.

Understanding this layering is the difference between a clean architecture and a tangled dependency graph where your planner agent is simultaneously a tool server and a task consumer.

MCP: The Tool-Calling Substrate

Anthropic’s Model Context Protocol, open-sourced in November 2024 4, provides a standardized way for LLM agents to discover and invoke external tools. It’s JSON-RPC 2.0 over stdio or HTTP/SSE, and it has achieved remarkable adoption — 55% of the 16,400+ tracked implementations are in JavaScript, with 38% in Python 2.

What MCP Does Well

MCP excels at capability exposure. An MCP server advertises a set of tools with JSON Schema descriptions, and the client (your agent’s LLM runtime) selects tools based on semantic fit. The protocol handles:

Tool discovery and schema negotiation
Structured input/output with validation
Streaming responses via SSE transport
Resource management (files, database connections, context windows)

The 2025-03-26 spec revision added structured tool output types and OAuth 2.1 authentication, making it genuinely production-ready 5.

Where MCP Falls Short for Multi-Agent

MCP is fundamentally client-server. The LLM runtime is the client; everything else is a server. This means MCP is perfect for “agent uses a tool” but awkward for “agent delegates to another agent.” There’s no concept of:

Bidirectional communication between peers
Long-running task lifecycle (submitted → working → done)
Agent discovery beyond static tool registration
Artifact exchange (files, documents, intermediate outputs)

If you’re building a multi-agent system where Agent A needs Agent B to independently run a 10-minute research task and return structured results, MCP alone will feel like fitting a square peg into a round hole. You can do it — we covered MCP server patterns in our custom MCP server guide — but you’re fighting the abstraction 6.

Google A2A: The Task Delegation Layer

In April 2025, Google announced the Agent-to-Agent (A2A) protocol, explicitly designed as a complement to MCP rather than a replacement 3. The framing is deliberate: MCP connects agents to tools, A2A connects agents to agents.

Core Architecture

A2A introduces several primitives that MCP lacks:

Agent Cards — JSON metadata files (served at /.well-known/agent.json) that describe an agent’s capabilities, endpoint URL, and authentication requirements 7. This is agent discovery as a first-class concept.

Task lifecycle — A2A models work as tasks with explicit states: submitted, working, input-required, completed, failed, canceled. A client can send a task and poll for completion, or subscribe to server-sent events for streaming updates 7.

Artifacts — Tasks produce artifacts: structured outputs, files, or data objects with MIME types and optional streaming parts. This solves the “agent A needs agent B’s file output” pattern cleanly 7.

Transport and Wire Format

A2A uses JSON-RPC 2.0 over HTTP (with SSE for streaming), which means it speaks the same wire format as MCP but with different method namespaces. A tasks/send request looks like this:

{
  "jsonrpc": "2.0",
  "id": "task-001",
  "method": "tasks/send",
  "params": {
    "id": "research-task-42",
    "message": {
      "role": "user",
      "parts": [
        {"type": "text", "text": "Analyze the competitive landscape for MCP hosting providers"}
      ]
    }
  }
}

The server responds with a task object containing status, artifacts, and any messages. If the task is long-running, the client polls via tasks/get or subscribes to SSE 7.

Production Status

A2A launched with contributions from over 50 technology partners including Salesforce, SAP, and LangChain 3. The reference implementation is on GitHub at google/A2A, with SDKs in Python and JavaScript 8. However, as of mid-2025, A2A is still in its early specification phase. The GitHub repository has active development but the ecosystem of production A2A servers is orders of magnitude smaller than MCP’s 16,400+ implementations 2.

Custom JSON-RPC: The Pragmatic Middle Ground

Here’s what many teams actually ship: a simple JSON-RPC server with a handful of methods tailored to their domain.

When Custom Makes Sense

Custom JSON-RPC patterns dominate when:

Your agents are tightly coupled (same codebase, same deployment)
You need domain-specific semantics (e.g., a “negotiate” method, a “vote” method)
You want zero protocol overhead — no discovery, no capability negotiation, just direct calls
You’re operating in a controlled environment where all agents are trusted

The pattern is straightforward:

# Minimal agent-to-agent JSON-RPC handler
async def handle_agent_request(method: str, params: dict) -> dict:
    if method == "agent/delegate":
        task = await spawn_subagent(
            prompt=params["prompt"],
            tools=params.get("allowed_tools", []),
            timeout=params.get("timeout", 300)
        )
        return {"task_id": task.id, "status": task.status}

    elif method == "agent/query":
        result = await get_agent_result(params["task_id"])
        return {"status": result.status, "artifacts": result.outputs}

    elif method == "agent/cancel":
        await cancel_task(params["task_id"])
        return {"status": "canceled"}

This is essentially a stripped-down A2A without the discovery layer. Teams at Cognition (Devin) and similar agentic coding tools have described architectures in this vein, where agent communication is purpose-built for the coding task domain 9.

The Downside

Custom protocols create integration debt. Every new agent type means new methods, new schemas, and new error handling. If you need agents from different teams or organizations to collaborate, custom JSON-RPC becomes a coordination bottleneck rather than a technical one.

Protocol Decision Matrix

Criterion	MCP	A2A	Custom JSON-RPC
Primary use	Tool invocation	Task delegation	Domain-specific messaging
Discovery	Static tool registry	Agent Cards	None (hardcoded)
Task lifecycle	None	Full state machine	Build your own
Ecosystem maturity	High (16K+ impls)	Early (2025 launch)	N/A
Cross-org interop	Good (standardized)	Designed for it	Poor
Complexity overhead	Low	Medium	Lowest

The pragmatic recommendation: use MCP for tool access, evaluate A2A for cross-agent task delegation, and use custom JSON-RPC for intra-system coordination where the complexity of protocol negotiation isn’t justified.

A Working Production Stack

For teams building multi-agent systems today, here’s a layered architecture that leverages the strengths of each protocol without premature abstraction:

Layer 1 — MCP Servers expose tools: web search, database access, code execution, file systems. Your agents connect to these as MCP clients. This layer has the strongest ecosystem and the most battle-tested implementations.

Layer 2 — Agent Orchestration uses a custom coordinator (your “planner” or “router” agent) that delegates tasks to specialized agents via direct function calls or lightweight JSON-RPC. This is your internal bus. Don’t overthink it.

Layer 3 — A2A (when ready) replaces Layer 2’s custom protocol when you need cross-team or cross-organization agent collaboration. Agent Cards provide discovery; task lifecycle provides reliability; artifacts provide structured data exchange.

The key insight is that these layers are composable, not competitive. MCP doesn’t compete with A2A any more than HTTP competes with SQL. They solve different problems at different layers of the stack 3.

What to Watch

The agent communication landscape is moving fast. Three developments worth monitoring:

A2A-MCP bridge patterns — early examples of A2A agents that internally use MCP servers, creating a clean delegation-to-tool chain 8
Agent registries — centralized catalogs of Agent Cards, similar to how API gateways aggregate OpenAPI specs
Protocol convergence — the A2A specification explicitly references MCP compatibility, suggesting these may become a unified stack rather than separate ecosystems 3

The worst choice is waiting for a single winner. The protocols address different layers, and production systems need all three layers today.

Key Takeaways

Multi-agent communication operates on three distinct layers: tool calling (MCP), task delegation (A2A), and message passing (custom JSON-RPC). Conflating them creates architectural debt.
MCP is production-ready with 16,400+ implementations, but it’s a client-server tool protocol — not an agent-to-agent communication layer 2.
Google A2A introduces agent discovery, task lifecycle management, and artifact exchange, but remains early-stage as of mid-2025 3.
Custom JSON-RPC is the pragmatic choice for tightly-coupled, single-team multi-agent systems where protocol overhead isn’t justified.
The recommended production stack layers MCP for tools, custom orchestration for internal coordination, and A2A for cross-organizational agent collaboration.
Don’t wait for protocol convergence — the layers are composable, and the best architectures use them together 3.

References

ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
Hermes Tutorials — Hermes Agent setup, configuration, and advanced workflows

Cross-links automatically generated from NiteAgent.

← Back to all posts

Agent-to-Agent Communication Protocols: What Actually Ships in Production