/aienm.

Inter-Agent Communication Protocols and Standards

Incompatible agent systems waste 500-1,000 developer hours per incident on custom integration code.

Contributing Editor · · 11 min read
Cover illustration for “Inter-Agent Communication Protocols and Standards”
Multi-Agent Orchestration · July 28, 2026 · 11 min read · 2,565 words

Why agents built in isolation can't coordinate at scale

Walk into any enterprise AI team today and you will find the same mess: a LangChain agent over here, an AutoGen workflow over there, a vendor-specific bot baked into the CRM, and a proprietary model someone's data science team stood up six months ago. Each one was built to solve a specific problem. Each one solved it. None of them can talk to the others without someone writing glue code to bridge them.

That glue code is the real cost center. According to Gartner's 2024 research, 35% of AI project failures are attributable to integration complexity, with estimates of between 500 and 1,000 developer-hours lost per incident. Not because the models were bad. The models were fine. The failure was coordination: agents that couldn't discover each other's capabilities, couldn't share context reliably, and couldn't hand off tasks without a custom adapter built for that exact pair of systems.

The underlying issue is API non-uniformity. Every agent speaks its own dialect for authentication, message formatting, capability declaration, and error handling. Every time you want two agents to collaborate, you rebuild trust, discovery, and message format from scratch. It's the software equivalent of requiring both parties to agree on a new language before every meeting, then forgetting it afterward.

That is what protocols exist to fix: a shared communication contract that agents from different vendors, different frameworks, and different organizations can use without a custom adapter. A converging set of them, MCP, A2A, ANP, and AG-UI, now exists. Understanding what each one actually does means understanding which specific coordination failure it targets, and why no single protocol covers all of them.

What the 1990s agent communication experiments got right and why they stalled

This problem is not new. In the early 1990s, DARPA's Knowledge Sharing Effort produced KQML, a protocol defining message "performatives" borrowed from speech act theory: ask, tell, achieve. The conceptual framing was exactly right. Separate message intent from transport. Let agents negotiate meaning rather than encoding it in rigid schemas.

FIPA-ACL followed. A standards body effort that added semantic rigor to what KQML had sketched. The specification matured through the late 1990s, finalized in 2002, and absorbed into the IEEE Computer Society in 2005. The abstraction held: define what an agent is trying to accomplish at the message level, independent of how it's transmitted.

So why didn't it survive? Adoption stayed almost entirely in academic and research settings. Integration remained labor-intensive even with the protocols in place because the tooling ecosystem never matured around them. Security models assumed closed, trusted environments, which meant they collapsed the moment you needed to operate across organizational boundaries. And then the web won. REST APIs and HTTP became the de facto integration layer for everything, agent middleware included. The field went dormant for roughly 15 years.

What's different now is deployment context. Cloud infrastructure at scale, large language models capable of complex reasoning, genuine enterprise demand for automation: conditions that simply didn't exist in the 1990s. If you look closely at MCP's tool-invocation model and A2A's task lifecycle, you're looking at KQML's performatives and FIPA-ACL's workflow semantics rebuilt on HTTP and JSON-RPC. The field rediscovered the right abstractions. This time the infrastructure and a market that will not wait exist to support them.

How the modern protocol stack maps onto four distinct communication layers

Diagram: Four Protocols, Four Distinct Layers. Visualizes: Visualize the agent communication stack as four discrete, stacked layers — each protocol handling a different communication problem with no overlap.

The most common mistake in explaining these protocols is treating them as competitors. They are not. They are layers, and the distinction matters considerably.

Consider how web infrastructure actually works. HTTP, WebSocket, and gRPC coexist because each handles a different communication pattern. Nobody argues about which one wins. You pick the one that fits the problem. The agent protocol stack works the same way.

Agent-to-Tool communication is what MCP handles. Agent-to-Agent coordination within and between enterprises is A2A's domain. Agent-to-Agent interaction across decentralized, untrusted environments is ANP's ambition. Agent-to-User, the front-end surface layer, is where AG-UI operates.

Gartner's 2025 projection that 40% of enterprise applications will integrate AI agents by 2026 makes the multi-layer reality concrete. At that scale of deployment, no single protocol covers the whole surface area. Any given workflow will have tool invocations, agent coordination, user-facing interfaces, and potentially cross-organizational agent calls happening simultaneously. The protocols compose; each one handles a communication problem the others weren't designed for.

MCP: how Anthropic's tool-connection standard became infrastructure

Anthropic launched MCP in November 2024. It standardizes how AI agents connect to tools, databases, and APIs using JSON-RPC 2.0. The architecture is hub-and-spoke: the LLM host sees all available tools through MCP servers, and tool capabilities are registered in a uniform format the host can query.

What MCP does not do is let two servers communicate with each other. No peer-to-peer delegation, no capability negotiation between agents. That is an intentional boundary. MCP is the tool layer. Keeping it scoped that way keeps it simple and composable.

The adoption arc tells you something about how quickly infrastructure-level standards propagate when the timing is right. From launch through early 2026, MCP accumulated over 10,000 published servers and 110 million monthly downloads. AWS, IBM, Cloudflare, OpenAI, and Google DeepMind all adopted it. That is not a niche developer tool. That is infrastructure.

In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation. Moving a spec from proprietary origin to neutral stewardship is a meaningful commitment: no single company can unilaterally deprecate, fork, or monetize it in ways that break the ecosystem built on top of it.

The protocol also evolved beyond its original scope, adding distributed execution, stateless transport (which addressed early load-balancing constraints), and a formalized security framework. For organizations deploying it, the practical consequence is that permissions granted at the source level propagate through everything downstream. Access control decisions made at the MCP layer have architectural consequences that surface later, sometimes in places nobody anticipated. Build that assumption in early.

A2A: the coordination layer MCP doesn't cover

Google launched A2A in 2025 to address the coordination problem MCP explicitly doesn't solve: how do agents discover each other, delegate tasks to one another, and manage the lifecycle of collaborative work across a multi-agent system?

The core mechanism is each agent publishing an Agent Card, a machine-readable descriptor of its capabilities. Tasks are units of work with a defined lifecycle: submitted, working, input-required, completed, or failed. Agents coordinate by exchanging tasks, and the lifecycle states give both parties a shared vocabulary for what's happening at any moment. That shared vocabulary is the actual coordination infrastructure. Without it, multi-agent systems are just a collection of capable agents with no reliable way to report status to each other.

Five design principles shaped A2A's architecture: supporting natural agentic capabilities, building on HTTP and JSON-RPC, enterprise-grade security as a default, support for long-running tasks, and modality-agnostic operation across text, audio, and video.

Version 0.3.0 in July 2025 introduced streaming-first transport and capability negotiation. Version 1.0.0 in January 2026 added signed Agent Cards for cryptographic verification. That is when A2A became production-ready in any meaningful sense. By April 2026, over 150 organizations were supporting the v1.0 spec, with founding governance partners including AWS, Microsoft, Salesforce, and SAP. Google had donated A2A to the Linux Foundation in June 2025, before the specification had even reached v1.0. That sequencing matters: governance before maturity, not after.

In practice, MCP and A2A pair cleanly. An agent uses A2A to coordinate with peer agents, and uses MCP internally to invoke the tools it needs to complete its portion of the work. Two protocols, one coherent architecture, no overlap.

What happened to ACP and why IBM's merger into A2A matters

In 2025, IBM Research proposed ACP as part of its BeeAI initiative. The goal was standardized communication between agents regardless of framework, with particular emphasis on stateful, long-running workflows. It was solving a real problem, and the design reflected IBM's production experience with complex enterprise automation.

In August 2025, IBM and Google announced that ACP would merge into A2A under the Linux Foundation's LF AI & Data umbrella. ACP development wound down, with its assets contributed to A2A.

ACP's stateful workflow concepts became part of A2A's task lifecycle model. Both organizations contributed to a protocol that was stronger for the collaboration. That outcome is not guaranteed when two well-funded organizations are each building toward the same space; usually you get fragmentation. The fact that it didn't happen here is the more interesting signal.

The broader pattern matters. The protocol landscape is self-organizing toward fewer, better-governed standards rather than fragmenting the way enterprise middleware did in the 1990s. Any documentation referencing ACP from mid-2025 forward should be read as describing what is now A2A.

ANP: what a decentralized agent internet would require

ANP's stated ambition is to become the HTTP of the agentic web: a communication layer across the open internet where agents from entirely different domains interact without any shared trust authority brokering the relationship.

The technical foundation rests on W3C standards: Decentralized Identifiers (DIDs), Verifiable Credentials, and JSON-LD. Agents prove identity cryptographically. No central registry, no API keys exchanged out of band. Identity is self-sovereign, verifiable, and portable.

The architectural contrast with A2A is deliberate. A2A assumes agents operate within or between organizations that have some pre-existing trust relationship. ANP assumes no prior trust at all. Every interaction begins from zero, and identity has to be established through cryptographic proof rather than organizational vouching. The question ANP forces is one the field hasn't fully answered: in a world where any agent can call any other agent across organizational boundaries, how do you establish trust without a centralized broker?

ANP is less mature than MCP or A2A. The use cases it targets—cross-company agent collaboration, autonomous agent marketplaces, agent interactions spanning industries and jurisdictions—are where the long-term trajectory of this technology points. The maturity will follow the need, and the need is real and growing.

AG-UI and the agent-to-user surface that enterprise deployments often overlook

Most multi-agent architecture discussions focus on the back end: how agents coordinate, how they invoke tools, how they delegate tasks. The user-facing surface gets treated as a solved problem, or worse, an afterthought. It isn't, and the gap shows up in production.

CopilotKit released AG-UI in May 2025. It is an open protocol that streams a single JSON event sequence over HTTP between an agent backend and a front-end interface. The event types cover the full scope of what a user interaction requires: messages, tool calls, state patches, and lifecycle signals. One protocol, one event stream, one coherent user experience rather than a patchwork of improvised bridges.

Adoption moved fast. By October 2025, CopilotKit was handling more than 2 million agent-user interactions per week. AG-UI had crossed 9,000 GitHub stars, and the CopilotKit package was seeing 120,000 weekly installs. Those numbers indicate real deployment, not adoption theater.

October 2025 also marked the formal integration between A2A and AG-UI. For the first time, the agent-to-agent and agent-to-user layers were explicitly connected as a designed integration rather than something teams were wiring together on their own.

AG-UI is distinct from Google's A2UI, which operates at a different layer with a different model. A2UI specifies a declarative JSON format for agents to describe component trees that clients render natively; it defines UI components rather than streaming interaction events. A2UI's design explicitly prevents executable code from crossing trust boundaries, which is a different security concern than AG-UI's transport focus. They are not interchangeable, and conflating them will create problems.

For organizations doing complete agent deployments: you need all three layers. A back-end coordination layer (A2A), a tool-connection layer (MCP), and a user-surface layer (AG-UI). Scoping only two of the three will surface in production, usually at the worst possible moment.

Governance infrastructure the Agentic AI Foundation provides across all these protocols

On December 9, 2025, the Linux Foundation announced the Agentic AI Foundation, launched with founding contributions of MCP from Anthropic, goose from Block, and AGENTS.md from OpenAI. Platinum members at launch included AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Over 150 member organizations joined, described by the Linux Foundation as the fastest-growing foundation in its history.

Neutral governance is a structural guarantee, not a formality. When a protocol lives under neutral stewardship, no single company can unilaterally deprecate it, change the licensing terms, or steer it in directions that benefit their products at the ecosystem's expense. The 1990s taught this lesson directly: proprietary middleware fragmented and died when the companies behind it pivoted or lost interest. The AAIF exists to prevent that outcome.

The security working group is doing concrete work in three areas. Agentgateway is a network proxy that enforces TLS, authentication, and rate limits for MCP traffic. AGENTS.md validation tooling provides static analysis for behavioral compliance. A2A trust mechanisms are being standardized to address the authentication and authorization questions that multi-agent coordination raises at enterprise scale.

AGNTCY, a Cisco-led initiative launched in July 2025 under the Linux Foundation, adds a cross-cutting layer across MCP and A2A: discovery, identity, secure messaging, and observability. It doesn't replace those protocols; it operates alongside them, providing infrastructure that benefits the whole stack.

The governance story is the maturity signal organizations should use when evaluating which protocols to build on. A protocol with neutral stewardship and broad vendor commitment is safe foundational infrastructure. A protocol controlled by a single vendor, however technically capable, carries adoption risk that compounds quietly until it doesn't.

How these protocols compose into a working multi-agent architecture

Diagram: One Workflow, Three Protocols in Motion. Visualizes: Illustrate the concrete multi-agent workflow described in the article as a left-to-right stepped flow with five nodes and protocol labels on each edge: (1) User submits request → AG-UI…

A concrete architecture makes this tangible. A user submits a complex request through a front-end interface. AG-UI streams the interaction to an orchestrating agent on the back end. The orchestrating agent, recognizing that the request requires specialized capabilities it doesn't have, delegates subtasks to specialist agents using A2A's Agent Card discovery and task lifecycle. Each specialist agent invokes the tools and data sources it needs through MCP. If any of those interactions involve agents from outside the organization's trust boundary, ANP's cryptographic identity mechanisms handle the cross-domain authentication. Three protocols in one workflow, no overlap, no redundancy, each one doing only what it was designed to do.

Permissions governance intersects with this architecture in ways organizations consistently underestimate until it costs them. In a layered system, access control cannot be quietly redefined at each hop. An agent that inherits a permission from an MCP server cannot silently re-grant that permission to a downstream agent through A2A without that grant being explicit and auditable. The architecture creates the possibility of coherent permission propagation; the security working group's tooling is what enforces it.

The remaining open problems are real. Cross-domain trust at ANP scale is unresolved. Agent identity and authentication across organizational boundaries is still being standardized within the AAIF's security working group. These are not fatal gaps. They are the frontier where active work is concentrated. Organizations building now should track protocol versions carefully and should plan for the specifications to keep evolving because they will.

The fragmentation problem is not fully solved. But the industry has, for the first time, agreed on what solving it looks like and built the governance infrastructure to keep that solution open. The 1990s research got the abstractions right and ran out of road before it could matter. That constraint is gone. What remains is the harder, less glamorous work of actually building production systems on top of these foundations, and most organizations are still figuring out where to start.

Sources

  1. medium.com

More in Multi-Agent Orchestration