What do your agents say to each other when you’re not listening? Every handoff — billing to shipping, research to synthesis — is a failure point where context vanishes or messages drop silently.
Pick wrong, and you inherit infinite loops, version mismatches, and silent drops. Pick right, and adding a fifth agent across three frameworks is a configuration change. This guide compares function calling, MCP, Google A2A, and custom message buses — with a decision matrix that fits your topology today and the one you’ll need when simple delegation breaks.
Option 1: Function Calling as Inter-Agent Protocol
The simplest approach. Agent A calls a send_message_to_agent_b tool. The tool is defined in Agent A’s function calling schema. Zero new infrastructure. Every LLM provider supports function calling.
{
"name": "delegate_to_code_reviewer",
"description": "Send code to the review agent for analysis.",
"parameters": {
"code": {"type": "string"},
"review_criteria": {"type": "array", "items": {"type": "string"}}
}
}Pros: works today with existing infrastructure. Every provider. Every model that supports tools. Zero learning curve. Cons: synchronous blocking — each inter-agent message is a full tool-call round-trip. For multi-turn conversations between agents, latency accumulates linearly. No built-in discovery — Agent A must know Agent B exists and what it can do.
Best for: simple delegation patterns where one agent occasionally hands off to another, small agent fleets (2-3 agents), and teams that want to start multi-agent without adopting new protocols. For the broader architectural patterns behind multi-agent systems, see the multi-agent architecture guide.
Option 2: MCP for Multi-Agent Systems
The Model Context Protocol — whose official specification defines how applications provide tools and context to LLMs — extends naturally to multi-agent scenarios. Each agent exposes its capabilities as an MCP server. Other agents — as MCP clients — discover and invoke those capabilities.
Pros: standardized capability discovery. An agent doesn’t need hardcoded knowledge of what other agents can do — it queries the MCP ecosystem and discovers capabilities dynamically. Growing ecosystem of MCP-compatible tools and servers.
Cons: MCP was designed for tool-use, not agent-to-agent communication. Agent negotiation patterns aren’t native. The protocol handles “agent calls tool” cleanly. “Agent negotiates with agent” is stretched.
Best for: heterogeneous agent fleets where agents have different capabilities and need dynamic discovery. Works well when the interaction pattern is “request → response” rather than “negotiate → revise → agree.” For building agents that combine MCP tool access with inter-agent coordination, start with the LLM-powered agent development guide.
Option 3: Google A2A Protocol
Purpose-built for agent-to-agent communication. Three core concepts:
- Agent Card. A JSON document describing what an agent can do, how to reach it, and what input/output formats it accepts. Published to a discovery endpoint.
- Task Lifecycle. Submitted → Working → Completed/Failed. Structured state machine. Agents know where every delegated task stands.
- Streaming Updates. Progress notifications during long-running tasks. The delegating agent doesn’t block — it receives updates asynchronously.
Pros: designed for agents talking to agents — not agents calling tools. Built-in discovery. Structured task lifecycle. Cross-framework — agents built with LangChain, AutoGen, and custom frameworks can interoperate if they speak A2A.
Cons: newer protocol, smaller ecosystem than MCP. More complex setup than function calling. Overkill for simple delegation between two agents.
Best for: cross-framework multi-agent systems. Teams building agents with different frameworks that need to interoperate. Complex multi-step delegation with progress tracking.
Option 4: Custom Message Bus
Redis Pub/Sub or NATS with a structured message schema. Maximum control. Maximum implementation effort.
{
"agent_id": "code_reviewer_v2",
"correlation_id": "req_8f3a2b",
"message_type": "review_request",
"payload": {"code": "...", "criteria": ["security", "performance"]},
"timestamp": "2026-07-27T14:22:00Z"
}Pros: full control over routing, persistence, retry, and observability. Exactly-once or at-least-once delivery semantics. Custom message retention policies. Cons: you build and maintain everything. Message schema evolution. Backwards compatibility. Broker operations. This is infrastructure work, not application work.
Best for: teams that have already exhausted the standard protocols, have unique communication patterns that none of them support, or need guaranteed delivery semantics that higher-level protocols don’t provide. Everyone else: start with function calling via the standard chat completions API or A2A.
Decision Matrix
| Function Calling | MCP | Google A2A | Custom Bus | |
|---|---|---|---|---|
| Setup complexity | Zero | Low | Medium | High |
| Capability discovery | None | Built-in | Built-in (Agent Card) | Manual |
| Task lifecycle | None | None | Structured (submitted→working→done) | Custom |
| Cross-framework | Yes (any model with tools) | Yes (MCP ecosystem) | Yes (by design) | Yes (by design) |
| Multi-turn negotiation | Clunky | Stretched | Native | Custom |
| Best for | Simple delegation, 2-3 agents | Tool-heavy agents with discovery needs | Cross-framework multi-agent fleets | Unique requirements, max control |
Start with function calling. It handles 70% of multi-agent communication needs with zero new infrastructure — a single API key and base URL gets you access to tool-calling models across every major provider. Add MCP when agents need dynamic capability discovery. Add A2A when you need cross-framework interoperability or structured task lifecycle. Build a custom bus only when the three protocols above demonstrably fail your requirements.
Protocol Failures in Production: What Actually Breaks
Protocol documentation describes happy paths. Production systems hit edge cases. Here are three failure modes that have surfaced in real multi-agent deployments — and how teams recovered from them.
The Infinite Message Loop
A customer support system used three agents: a triage agent that classified inbound queries, a product specialist agent that answered product questions, and a billing agent that handled payment issues. They communicated via function calling — each agent had a transfer_to_agent tool.
A customer asked: “My subscription renewed at the wrong tier — I was on the annual plan but you charged me the monthly rate. Can you fix this?” The triage agent classified this as a billing issue and called transfer_to_agent(target="billing", context=...). The billing agent received the context, determined the issue involved plan tier logic (a product concern), and called transfer_to_agent(target="product_specialist", context=...). The product specialist saw a billing-related question about subscription tiers and called transfer_to_agent(target="billing", context=...). The triage agent received it again and the cycle continued.
The customer waited 47 seconds before receiving a response — each loop iteration was a full LLM inference round-trip. The loop was broken by the token limit on the conversation context; the agents had accumulated so much transfer history that the original query was pushed out of the context window.
The fix was two-fold: (1) add a hop_count field to every inter-agent message — if a message has been forwarded more than three times, escalate to a human, and (2) implement a circuit breaker pattern: if the same agent receives the same correlation ID twice within 60 seconds, stop routing and return the task to the originating agent with an “unable to resolve” status. The loop that took 47 seconds to self-terminate now breaks at the third hop — under 12 seconds.
Protocol Version Mismatches
A team adopted A2A across five agent teams, each maintaining their own agent independently. The Agent Card schema was versioned as v1.0.0 at launch. Team B, building a new feature, added a priority field to their Agent Card and bumped their internal version to v1.1.0. The field was optional — backward-compatible in their view.
Team A’s supervisor agent parsed the Agent Card using a strict schema validator. The unknown priority field caused a parse failure — not a graceful “ignore unknown fields” behavior, but an unhandled ValidationError that crashed the discovery loop. The supervisor could no longer discover Team B’s agent. For six hours, requests that should have been routed to Team B’s agent were silently dropped — the supervisor’s error handler treated discovery failures as “agent unavailable, retry later.”
The fix: every Agent Card parser must implement tolerant reading — ignore unknown fields, warn on unexpected values. This is Postel’s Law applied to agent protocols: be conservative in what you send, liberal in what you accept. Team A’s supervisor was being conservative in both directions, and it broke interoperability. Version negotiation is not optional in multi-team agent systems. Each agent card should advertise its schema version, and clients should negotiate the highest mutually supported version — falling back to the baseline if no overlap exists.
Silent Message Drops
A production monitoring system used a custom Redis Pub/Sub message bus for inter-agent communication. The pattern: Agent A publishes a task to agent_b_tasks, Agent B subscribes and processes. Under normal load (50-100 messages/minute), the system was reliable. Message acknowledgment was implicit — if Agent B didn’t crash, the message was “delivered.”
During a production incident, message volume spiked to 800 messages/minute. Redis Pub/Sub is fire-and-forget — messages published while a subscriber is temporarily disconnected (network blip, client buffer overflow) are lost forever. Agent B’s subscriber connection experienced a 400ms interruption. During those 400 milliseconds, 5 messages were published and silently dropped. No error. No retry. The messages simply never arrived.
The dropped messages were alerts about disk utilization on a production database. The disk filled up. The database crashed. The monitoring system — which existed to prevent exactly this scenario — was the component that failed, because its own communication layer had a silent failure mode.
The fix: migrate from Redis Pub/Sub to Redis Streams for any message that matters. Pub/Sub is for ephemeral broadcast data — live status updates, presence notifications. Streams provide persistent storage, consumer groups, and explicit acknowledgment. After migration: zero silently dropped messages across six months of production traffic. The lesson: if a message is worth sending, it’s worth confirming delivery. Fire-and-forget protocols have no place in multi-agent systems where message loss cascades into failure.
FAQ
Are A2A and MCP competing or complementary?
Complementary. MCP handles agent-to-tool communication — “agent, use this API.” A2A handles agent-to-agent communication — “agent, ask that other agent to do something.” They solve different layers of the multi-agent stack. A typical deployment uses both: MCP for tool access, A2A for inter-agent coordination.
What’s the simplest multi-agent communication setup?
Function calling with a send_message_to_agent tool. Two agents. One tool each that lets them send structured messages to each other. No new infrastructure. No new protocols. Works today with any LLM provider that supports function calling. Start here. Add protocol complexity only when this pattern breaks.
Can agents using different protocols interoperate?
Not directly. An A2A agent can’t natively call an MCP server, and vice versa. The solution is a protocol gateway — a translation layer that exposes MCP tools as A2A Agent Cards, or wraps function calling behind an A2A interface. This is infrastructure you build, not something that comes out of the box.
Which protocol will dominate by 2027?
A2A for inter-agent communication — it’s purpose-built and backed by Google’s ecosystem weight. MCP for agent-to-tool communication — the tool ecosystem is the moat. Function calling as the fallback that always works everywhere. The stack converges: A2A between agents, MCP to tools, OpenAI-compatible function calling as the universal baseline.
How do I debug protocol failures in a multi-agent system?
Instrument every inter-agent message with a correlation ID, a source agent ID, a target agent ID, a hop count, and a timestamp. Without this, you cannot trace a message through your agent topology — and when something goes wrong, you will not know which agent dropped, mishandled, or looped the message. Structured logging at protocol boundaries is mandatory: log every message sent and received, including the full payload at DEBUG level and the metadata fields at INFO level. Build a lightweight trace viewer — even a simple table showing correlation ID, agent path, and latency per hop — before you need it during a production incident. Second: implement health checks that exercise the full protocol stack, not just TCP connectivity. An agent that responds to pings but silently drops messages is not healthy. The health check should send a synthetic task through the protocol, verify the response arrives, and measure end-to-end latency. Third: add dead letter queues for messages that exceed maximum retries. A message that can’t be delivered should land somewhere you can inspect it — not silently disappear. The debugging time you save pays for the instrumentation cost within the first two production incidents. For the structured logging schema and audit trail patterns that support multi-agent observability, see our logging and audit guide.
Agent communication protocol choice follows the same rule as every other infrastructure decision: start simple, add complexity only when the simple thing breaks. Function calling handles 70% of use cases with zero new infrastructure.