Agent-to-Agent: The Protocol Wars, and the One Question Buyers Keep Getting Wrong

ANCI · Agentic AI

---

“Protocol wars” makes for a great headline. MCP versus A2A versus function calling — three standards locked in combat, and a buyer somewhere trying to guess which one survives so the budget does not get stranded on the losing side. It is a tidy story. It is also wrong. There is no war. There is a stack. The protocols that let AI agents talk to tools and to each other are not competing for the same job. They sit at different layers of an architecture, the way TCP and HTTP do. Once you can see the layers, the buying question changes completely, and it gets far more useful.

There is no war. There is a stack.

If you think in components, this space resolves quickly. Strip away the branding and you are looking at three layers, each solving a different problem.

At the bottom sits function calling, the primitive. A language model produces a structured request that says, in effect, “call this function with these arguments.” It is the raw mechanism by which a model reaches outside its own text and triggers an action. Function calling is powerful and it is also unglamorous plumbing. On its own it has no standard shape, which is exactly the problem the layers above it were built to solve.

The next layer up is the Model Context Protocol (MCP), originally from Anthropic. MCP is the vertical connector. It standardizes how a single agent reaches down into tools, APIs, and data sources. Think of MCP as a universal adapter: instead of writing bespoke function-calling glue for every database, calendar, and CRM your agent touches, you expose each one through an MCP server, and any MCP-aware agent can use it. The agent-to-tool problem, solved once, reused everywhere.

The third layer is Agent-to-Agent (A2A), originally from Google and now an open standard. A2A is the horizontal connector. It governs how autonomous agents — potentially built by different vendors on different stacks — discover each other, delegate tasks, and return results. Where MCP reaches down to tools, A2A reaches across to peers.

This is the move most buyers miss. MCP and A2A are not rivals. They are complementary layers, and the most resilient production systems run both. An orchestrator agent uses A2A to hand a subtask to a specialist agent, and that specialist uses MCP internally to call the tools it needs to finish the job. HTTP did not kill TCP — it runs on top of it. A2A does not kill MCP. It runs beside it, one layer up. The “war” framing collapses the moment you draw the diagram.

How agents actually talk, in plain language

Here is what happens under the hood, with the jargon translated.

Start with discovery. Every A2A-compliant agent publishes a small public file — by convention at an address like /.well-known/agent.json. The industry nickname is the Agent Card, and the simplest way to understand it is as a digital resume. The card lists what the agent can do, where to reach it, which inputs it accepts, and which authentication method it expects. A client agent that needs work done fetches the card, reads the resume, and decides whether this agent is the right peer for the task. No human integration meeting required.

Once a client picks a partner, it sends a request. A2A uses JSON-RPC 2.0 over ordinary HTTPS — a deliberately boring choice and a smart one. It means every agent-to-agent interaction is, mechanically, just an API call. Your existing API gateways, identity systems, and monitoring tools all still apply. The request creates a task, each task gets a unique ID, and because real agent work is rarely instant, the protocol supports streaming updates so a long-running job can report progress instead of leaving the caller staring at a frozen request.

Security rides on standards the enterprise already trusts. The Agent Card declares which schemes it supports — OAuth 2.0, OpenID Connect, API keys, or mutual TLS — and the calling agent completes that flow separately to obtain a short-lived token, often valid for only minutes. Credentials are never baked into the card itself. A2A deliberately refuses to invent its own identity system, which keeps it lightweight but pushes the real security burden onto whoever implements it.

The plain-language summary: MCP is how an agent uses things. A2A is how an agent works with other agents. Function calling is the spark underneath both.

The landscape is consolidating, not fragmenting

The “wars” narrative implies fragmentation and a coming bloodbath. The data points the other way. The story of 2026 is consolidation under shared governance.

Adoption tells the first part. By March 2026, MCP had crossed roughly 97 million monthly SDK downloads — a scale comparable to mainstream developer tooling but reached in a fraction of the time. Community registries index well over 18,000 MCP servers. Every major provider — Anthropic, OpenAI, Google, Microsoft, AWS — now supports it natively. On the cost side, one widely cited figure puts the time to wire a new SaaS tool into an agent at roughly 18 hours of custom function-calling code before MCP, falling to about 4 hours with it. That is not a marginal efficiency. That is the difference between integration as a project and integration as a configuration step.

Governance tells the second part. In December 2025, MCP was donated to the Linux Foundation’s Agentic AI Foundation, with OpenAI and Google joining as co-founders. Read that sentence again: the three companies most often cast as combatants put the core protocol under neutral, shared stewardship. Around the same time, IBM’s Agent Communication Protocol (ACP) — one of the supposed third combatants — merged into A2A rather than competing with it. The “three-horse race” quietly became a two-layer stack under one foundation.

Demand sits underneath all of it. Gartner has projected that by 2026 nearly every business application will ship with an AI assistant. When agents are everywhere, the cost of every pair of them speaking a different dialect becomes intolerable. Standards do not win because they are elegant. They win because the alternative — custom integration for every connection — does not scale. That economic gravity is what is pulling the ecosystem together.

The question buyers keep getting wrong

So here is the opinion this whole piece has been building toward. The wrong question is “which protocol should we bet on?” That question assumes a winner, assumes a loser, and assumes your investment is a wager on the outcome. None of that is true. Betting on a protocol in 2026 is like betting on HTTP in 2005. You are not placing a wager. You are describing table stakes.

First, can your agents be discovered? An agent your other systems cannot find and introspect is a silo with a chatbot bolted on. If a vendor cannot tell you how their agent advertises its capabilities, or whether it speaks the discovery layer at all, that is a fragmentation risk wearing a modern coat.

Second, can your agents be governed? A2A deliberately leaves identity and credentialing to the implementer. That is a feature, because it reuses your existing controls — but only if those controls exist. The hard questions are not protocol questions. They are governance questions. Who issues the tokens. Who scopes them. How short-lived are they. What stops a compromised or simply confused agent from delegating a task it should never have been allowed to delegate.

Third, can your agents be replaced? This is the new lock-in, and it is the inverse of the old one. For thirty years, lock-in meant proprietary formats and switching costs. In the agent era, lock-in is the agent that cannot interoperate — the one that only works inside one vendor’s walled garden. Standards-compliance is not a technical nicety here. It is your exit option, and your exit option is your negotiating leverage.

Put those three together and the strategic posture inverts. Treat the protocols themselves as commodity plumbing, because that is what shared governance is rapidly making them. Spend your scrutiny one layer up — on governed shared context, real identity for agents, and the policy layer that decides who may do what. That is where the durable advantage lives, and also where the durable risk lives.

A scheduling agent is the whole stack in miniature

Abstract layers are easier to trust when you can see one carry real weight. Consider the most deceptively simple agent task: getting a meeting on the calendar across two companies.

At ANCI, our agent Zara does exactly this, and a single cross-company scheduling request lights up every layer of the stack at once. To find an open slot, Zara reaches down through the tool layer to read calendars, check working hours, and respect time zones — that is MCP, the vertical connector. But the person Zara is trying to meet sits at a different company, behind a different system. To get anything done, Zara’s agent and their agent have to find each other, confirm what each is authorized to negotiate, exchange proposed times, and converge on an answer — that is A2A, the horizontal connector. And every concrete step resolves down to a structured function call at the bottom.

Notice too that the buyer questions are not academic in this example. Discovery decides whether the two agents can find each other at all. Governance decides whether Zara is permitted to book on someone’s behalf and within what limits. Interoperability decides whether this works only between two companies using the same vendor, or across any two companies whose agents speak the stack. Scheduling looks trivial. It is actually a complete, honest test of whether an agent architecture holds together.