Agent-to-Agent Communication: The Protocol Isn't the Point

Agent-to-agent communication is the set of protocols and message formats, most visibly Google's A2A and Anthropic's MCP, that let independently built AI agents exchange tasks, context, and results without sharing internal code. The protocol layer solves discovery and message-passing. It does not solve the harder problem, which is agents that format a message correctly and still misread or ignore what's inside it.

I watched this play out on a coding-agent pipeline I reviewed this year, an illustrative case, not a named client. A planning agent handed a refactor task to an execution agent, complete with a clean spec, file paths, and constraints. The execution agent acknowledged the handoff, ran for six minutes, and returned a "success" status. It had refactored the wrong module. Every message in that exchange was well-formed. The failure wasn't in the wire format. It was in what the second agent did with a correctly delivered instruction.

Key takeaways

• Agent-to-agent communication is a protocol problem and a coordination problem, and only the first one is close to solved. A2A and MCP standardize discovery and message format; neither standardizes whether an agent interprets a message correctly.
• A2A and MCP are not competitors. A2A handles agent-to-agent task handoff; MCP handles agent-to-tool and agent-to-data access. Most production systems need both.
• Both protocols run on JSON-RPC 2.0 instead of a purpose-built format, a deliberate, boring choice that pays off in tooling and debuggability.
• Inter-agent misalignment is a named, recurring failure category, not an edge case. A 2025 study of 1,600+ multi-agent traces found agents ignoring input, withholding relevant context, and resetting conversation state mid-task, independent of framework.
• Protocol compliance is a prerequisite for evaluation, not a substitute for it. Before you trust a handoff in production, you need a harness that checks whether the receiving agent actually used what it was sent.

What Agent-to-Agent Communication Actually Means

Agent-to-agent communication is how one autonomous AI system tells another what to do, gives it the context to do it, and gets a usable result back, all without either agent needing to see the other's internal code, prompts, or model. It's distinct from tool-calling, where a single agent invokes a deterministic function and gets a return value. Agent-to-agent communication assumes both sides are reasoning systems that can accept a goal, work toward it over multiple steps, and report back with judgment, not just output. If you haven't drawn that line clearly in your own system, start with my piece on tool use and function calling, which covers where the tool boundary sits.

This matters because the two problems fail differently. A tool call fails loudly: wrong arguments throw an error, a missing field breaks the schema. An agent-to-agent handoff can fail silently, both agents report success, the messages were valid, and the outcome is still wrong. That gap is the entire reason a protocol layer exists, and also the entire reason it isn't enough on its own. I go deeper on the coordination side of this in my primer on multi-agent systems, which this article assumes as background.

The Two Protocols Doing the Work: A2A and MCP

Two protocols cover almost all production agent-to-agent communication today, and they solve different halves of the problem. A2A (Agent2Agent) handles agent-to-agent traffic: discovery, task handoff, and status across independently built agents. MCP (Model Context Protocol) handles agent-to-tool and agent-to-data traffic: how a single agent reaches external resources, tools, and prompts it doesn't own.

A2A was built by Google and has since been transferred to the Linux Foundation, with a Technical Steering Committee that includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow, released under the Apache License 2.0. MCP, meanwhile, defines how a host application's client talks to a server: servers expose resources, prompts, and tools, and clients can offer sampling, roots, and elicitation back, per the 2025-06-18 specification.

That governance detail is not trivia. A protocol backed by one vendor is a format everyone else reverse-engineers. A protocol with a cross-vendor steering committee and an open license is closer to a real standard, which is what lets you build against it without betting your architecture on one company's roadmap.

The two protocols aren't in competition. A planning agent might use A2A to hand a research task to a specialist agent, which then uses MCP to query a database and call a search tool while doing the work. One protocol governs who's talking to whom. The other governs what each of them can reach.

How Message Passing Works: Agent Cards, Tasks, and Artifacts

A2A's mechanics run on three objects. An Agent Card is a small, published JSON document describing what an agent can do, its name, skills, and how to reach it, so a caller can discover it without hardcoding an integration. A Task is the unit of work handed across the wire, with an ID, a lifecycle (submitted, working, completed, failed), and the message describing what's being asked. An Artifact is what comes back: the actual output, whether that's text, a file reference, or structured data.

Here is the shape of a task handoff, illustrative rather than exact wire syntax:

What that structure buys you is inspectability. Every task has an ID you can trace, a status you can poll, and an artifact you can diff against expectations. That's the value of the protocol layer: it turns an ad hoc API call into something you can log, replay, and audit the same way across every agent pair in your system.

JSON-RPC as the Wire Format

Both protocols lean on JSON-RPC 2.0 instead of inventing a new format, and that choice is more consequential than it looks. JSON-RPC has existed since 2005, has mature tooling in every language, and makes request, notification, and error handling boring and well understood. Boring is the goal. A wire format is not where you want novelty.

The practical payoff: your existing HTTP debugging tools, your logging pipeline, and your schema validators mostly already know how to handle JSON-RPC. You spend engineering budget on the parts that are genuinely new, task lifecycle, agent discovery, capability negotiation, instead of re-teaching your stack how to parse a bespoke envelope.

Where Communication Breaks Down in Production

Here is the finding that should reset expectations for anyone deploying multi-agent systems. A 2025 study analyzing more than 1,600 annotated execution traces across seven multi-agent frameworks, using GPT-4, Claude 3, Qwen2.5, and CodeLlama, identified 14 distinct failure modes across three categories: system design, inter-agent misalignment, and task verification. The taxonomy was validated at kappa = 0.88 inter-annotator agreement, high enough to trust as a real pattern, not noise (Cemri et al., 2025).

The inter-agent misalignment category is the one that matters here, because it names failures that have nothing to do with wire format. Conversation reset is an agent losing track of context mid-task and effectively restarting cold. Information withholding is an agent holding relevant context and not passing it to the agent that needs it to decide correctly. Ignored input is an agent receiving a correctly formatted, correctly delivered message and proceeding as though it hadn't.

None of those three failures show up as a protocol error. The message was valid JSON-RPC, the task ID resolved, the artifact came back with a 200. Your logs say the handoff succeeded. Your product says otherwise.

A Minimal Protocol Pattern You Can Ship This Week

You don't need to adopt A2A wholesale to get most of its discipline. Three pieces cover the bulk of the value: a published agent card, a task object with a real lifecycle, and a timeout-and-retry policy you enforce. Here is a minimal card and the handoff log I'd want to see for every task sent between agents.

Two rules make this pattern hold up. First, every task gets a timeout, and a timeout is a real failure state your caller handles, not a hang. Second, "completed" is not the same as "correct," so log the artifact separately from the status and evaluate it before you trust it downstream. This is a smaller, faster version of the discipline I cover in more depth in my article on agent orchestration patterns, for teams coordinating more than a pair of agents.

The Trade-off: Protocol Compliance Isn't Coordination

Name the limitation plainly: a standardized protocol guarantees agents can format a message to each other. It does nothing to guarantee they understand it, or act on it correctly. The MAST research found inter-agent misalignment, ignoring input, withholding relevant information, resetting context mid-task, persists as a category regardless of which framework or wire protocol sits underneath it.

That has a revenue consequence, not just an engineering one. A multi-agent system that silently mishandles 10% of handoffs doesn't fail with an error your on-call engineer sees. It fails as a wrong answer a customer acts on, discovered days later when the cost of the mistake has already compounded. Treating protocol compliance as if it were correctness is how teams ship multi-agent systems that pass every integration test and still fail their first real customer interaction.

What to Evaluate Before You Trust an Agent Handoff

Before you let one agent's output feed another agent's decision in production, you need answers to four questions, and none of them come from the protocol layer:

• Did the receiving agent use the context it was sent, or did it proceed as though the message were empty?
• Did anything get withheld that would have changed the receiving agent's decision if it had been included?
• Did the agent's understanding stay coherent across the full task, or did it reset partway through?
• Can you verify the artifact mechanically, against a schema, a test, or a known-good answer, rather than reading it and deciding it looks right?

That's an eval problem, not a protocol problem, and it's the harder half of agent-to-agent communication by a wide margin. My book Agents That Actually Work goes deeper on building that evaluation layer alongside the handoff mechanics, because shipping the wire format without it is how a well-formatted failure reaches production.

Frequently asked questions

What's the difference between A2A and MCP? A2A governs agent-to-agent communication: how one autonomous agent discovers, hands a task to, and receives results from another. MCP governs agent-to-tool and agent-to-data access: how a single agent reaches external resources, prompts, and tools. Most production systems need both, layered together rather than chosen between.

How do AI agents actually talk to each other? Through a published Agent Card that advertises what an agent can do, a Task object with an ID and a lifecycle both sides track, and JSON-RPC 2.0 messages carrying the request and the resulting artifact. The mechanics are closer to a well-documented API than anything exotic.

Why do multi-agent systems fail even when each agent works fine alone? Because most failures live in inter-agent misalignment, not in any single agent's competence. Research on 1,600+ multi-agent traces found agents ignoring correctly delivered input, withholding context the other agent needed, and resetting conversation state mid-task, all while every individual message stayed protocol-valid.

Do I need a formal protocol to build a multi-agent system, or can agents just call each other's APIs? You can start with direct API calls for two agents you control. The value of A2A and MCP shows up once you're integrating agents you didn't build, or once you need discovery, retries, and audit trails to work the same way across every pair. Below that scale, the minimal pattern, an agent card, a task lifecycle, and an enforced timeout, gets you most of the benefit without the adoption cost.

Agent-to-agent communication will keep getting easier to wire up. It won't get easier to trust without an evaluation layer built alongside it. If you're past the prototype stage and shipping agent handoffs a customer's outcome depends on, that's the gap ViitorCloud's AI development team closes: instrumented handoffs, evals on every artifact, and a protocol layer that earns the trust you're currently assuming.