Agentic AI Protocols

In the early days of the internet, every computer manufacturer had its own proprietary networking protocol. IBM had SNA. Digital had DECnet. Xerox had XNS. Each worked well within its own ecosystem, but connecting systems across organisational boundaries was an exercise in frustration. It took TCP/IP - a single, open, universal protocol - to transform a collection of isolated networks into the internet.

Agentic AI faces the same inflection point. Today, autonomous agents are being built on dozens of different frameworks - LangChain, CrewAI, AutoGen, BeeAI, Google ADK, Amazon Bedrock Agents, and many more. Each framework has its own conventions for how agents access tools, communicate with each other, and report their actions. The result is a landscape of capable but isolated agents, each speaking its own dialect. The AXD Institute's Protocol Tracker monitors the evolving landscape of eight active agentic commerce and communication protocols.

Three protocols have emerged to solve this problem. MCP (Model Context Protocol), created by Anthropic, standardises how agents access external tools and data. A2A (Agent-to-Agent Protocol), created by Google, standardises how agents delegate tasks to other agents. ACP (Agent Communication Protocol), created by IBM Research, standardises how agents exchange rich, multimodal content across frameworks. Together, they form the emerging communication infrastructure of the agentic age.

For practitioners of Agentic Experience Design, these protocols are not merely technical specifications. They are the structural grammar through which trust architecture, delegation design, and observability are implemented at scale. Understanding them is essential for anyone designing human-agent relationships in production systems.

A single agent operating within a single application can communicate however it likes. The moment that agent needs to access an external tool, collaborate with another agent, or operate across an organisational boundary, it needs a shared language. Protocols provide that language.

The need is acute for three reasons. First, specialisation. No single agent can do everything well. Complex workflows require specialist agents - one for research, one for code generation, one for financial analysis - that must coordinate their efforts. Without a protocol, each integration is a bespoke engineering project. Second, trust verification. When an agent delegates a task to another agent it has never encountered before, it needs a standardised way to verify that agent's capabilities, authenticate its identity, and audit its actions. Third, scale. Enterprise agentic systems will involve hundreds or thousands of agents operating across departments, vendors, and geographies. Manual integration does not scale. Protocols do.

The three protocols that have gained the most traction - MCP, A2A, and ACP - each address a different layer of this communication challenge. They are not competitors. They are complementary, each solving a distinct problem in the agentic communication stack.

The Model Context Protocol was created by Anthropic in November 2024 and donated to the Linux Foundation in December 2025. It has been described as "USB-C for AI" - a universal connector that standardises how AI models access external tools, data sources, and services. MCP operates on the vertical axis of the agentic stack: it connects agents downward to the capabilities they need to function.

Architecture

MCP follows a client-server architecture built on JSON-RPC 2.0. The host application (such as Claude, ChatGPT, or Cursor) acts as the MCP client. External systems - databases, APIs, file systems, web services - expose their capabilities through MCP servers. The protocol defines three core primitives: tools (functions the agent can call), resources (data the agent can read), and prompts (templated instructions the agent can use). Communication flows over HTTP with Server-Sent Events (SSE) for streaming responses.

What MCP Solves

Before MCP, every tool integration required custom code. If you wanted an AI agent to query a database, you wrote a database adapter. If you wanted it to search the web, you wrote a search adapter. If you wanted it to read files, you wrote a file adapter. Each adapter was framework-specific, meaning work done for one AI platform could not be reused on another.

MCP eliminates this duplication. A tool exposed as an MCP server can be consumed by any MCP-compatible client - regardless of whether the underlying model is Claude, GPT, Gemini, or an open-source alternative. This creates a growing ecosystem of reusable tool integrations that any agent can access. As of early 2026, MCP is supported by Claude, ChatGPT, GitHub Copilot, Cursor, Windsurf, and dozens of other platforms.

Design Implications

From an AXD perspective, MCP is the protocol layer where intent architecture meets implementation. When a user specifies a goal - "book the cheapest flight to Tokyo next Thursday" - the agent must decompose that intent into tool calls: search flights, compare prices, check calendar, process payment. MCP standardises how those tool calls are structured, making the intelligence layer portable across platforms. For designers, this means the tools available to an agent are no longer constrained by the platform it runs on. The design space expands dramatically.

The Agent-to-Agent Protocol was launched by Google in April 2025 and donated to the Linux Foundation in June 2025. Where MCP connects agents to tools, A2A connects agents to each other. It operates on the horizontal axis of the agentic stack: enabling peer-to-peer collaboration between autonomous agents that may be built on entirely different frameworks, by different organisations, with different internal architectures.

Architecture

A2A is built on JSON-RPC 2.0 over HTTP, with support for Server-Sent Events and webhooks for real-time communication. Its defining innovation is the Agent Card - a standardised metadata document (typically hosted at /.well-known/agent.json) that describes an agent's capabilities, supported input/output formats, authentication requirements, and service endpoints. Agent Cards enable discovery: a client agent can find and evaluate a remote agent's capabilities before deciding whether to delegate a task.

The protocol defines a structured task lifecycle with explicit states: submitted, working, input-required, completed, failed, and cancelled. This state machine provides both agents and human observers with clear visibility into the progress of delegated work. Tasks contain messages (with roles like "user" and "agent") and produce artifacts - the tangible outputs of the agent's work.

What A2A Solves

Consider a scenario in agentic commerce: a user's personal shopping agent needs to coordinate with a retailer's inventory agent, a logistics agent, and a payment processing agent. Each of these agents is built by a different organisation, on a different framework, with different security requirements. Without A2A, this coordination requires custom API integrations for every agent pair - an approach that becomes combinatorially explosive as the number of agents grows.

A2A provides the standard through which these agents discover each other (via Agent Cards), negotiate capabilities, delegate tasks, stream progress updates, and return results. Crucially, agents collaborate without exposing their internal logic or proprietary reasoning - they communicate through opaque task interfaces, preserving intellectual property and security boundaries.

Design Implications

A2A maps directly to several AXD frameworks. The task lifecycle (submitted, working, completed) is a protocol-level implementation of delegation design - giving designers a structural vocabulary for how authority flows between agents. The Agent Card is a trust artifact: it is the mechanism through which trust calibration happens at the protocol level. And the explicit task states provide the foundation for multi-agent orchestration visibility, making it possible to design interfaces that show humans what their agents are doing across a network of collaborating systems.

The Agent Communication Protocol was developed by IBM Research through the BeeAI project, first announced in March 2025 and contributed to the Linux Foundation AI & Data initiative. ACP shares A2A's goal of enabling agent-to-agent communication, but takes a different architectural approach - one that prioritises simplicity, multimodal content exchange, and developer accessibility.

Architecture

ACP is built on RESTful HTTP APIs rather than JSON-RPC. Agents register themselves with a discovery service, exposing their name, description, and supported content types. Communication happens through a straightforward message-passing interface: a client sends an input (containing one or more "parts" with typed content), and the agent returns an output with its own parts. Each interaction is tracked through a run ID and session ID, enabling stateful conversations.

The protocol's distinguishing feature is its emphasis on rich content exchange. Where MCP focuses on tool invocation and A2A on task delegation, ACP treats communication as content transfer. Agents can exchange text, images, JSON data, audio, and other media types within a single message. This makes ACP particularly well-suited for workflows that involve multimodal reasoning - an agent that analyses images, generates reports, and produces visualisations can communicate all of these artifacts through a single protocol.

What ACP Solves

ACP addresses the practical challenge of building multi-agent systems quickly. Its REST-based design means any developer who has built a web API can build an ACP-compliant agent. There is no need to learn JSON-RPC conventions or implement complex state machines. The BeeAI platform, which serves as ACP's reference implementation, provides a production-grade framework for building, testing, and deploying ACP agents in both Python and TypeScript.

The protocol is particularly strong in scenarios where agents need to share rich, structured outputs. A research agent can pass a complete analysis - with text, data tables, and charts - to a reporting agent, which can then format and deliver it to a human user. The content fidelity is preserved throughout the chain because ACP treats multimodal content as a first-class citizen.

Design Implications

For AXD practitioners, ACP's multimodal emphasis has direct implications for explainability design. When agents can exchange rich content - not just text strings but images, structured data, and annotated outputs - the raw material for observability interfaces becomes dramatically richer. Designers can build audit trails that show not just what an agent decided, but the visual evidence, data analysis, and reasoning artifacts that informed that decision.

The most important thing to understand about MCP, A2A, and ACP is that they are complementary, not competing. Each operates at a different layer of the agentic communication stack, and a production system will likely use more than one.

Think of it this way: MCP is the protocol through which an agent reaches for a tool. A2A is the protocol through which an agent asks another agent for help. ACP is the protocol through which agents share rich, multimodal work products. In a typical agentic commerce workflow, all three might be active simultaneously: a shopping agent uses MCP to access a product database, A2A to delegate price comparison to a specialist agent, and ACP to receive a rich comparison report with images and structured data.

All three protocols have been donated to the Linux Foundation, signalling a shared commitment to open governance. This convergence under a single governance umbrella suggests that interoperability between the protocols themselves - not just between agents - will be a priority in the coming years.

Every protocol boundary is a trust boundary. When an agent invokes a tool via MCP, it trusts that the tool will behave as advertised. When an agent delegates a task via A2A, it trusts that the remote agent will complete the task competently and honestly. When an agent receives content via ACP, it trusts that the content is accurate and unmanipulated. Each of these trust assumptions must be designed for, not assumed.

The protocols provide some trust infrastructure natively. A2A's Agent Cards include authentication requirements and capability declarations, enabling a form of trust calibration at the protocol level. MCP servers declare their available tools and resources, allowing clients to verify capabilities before invocation. ACP's session tracking enables audit trails that support post-hoc trust verification.

But protocol-level trust is necessary, not sufficient. The four layers of trust architecture - competence, integrity, benevolence, and predictability - must be designed into the systems that sit above the protocols. An Agent Card can declare that an agent is capable of financial analysis, but it cannot guarantee that the analysis will be accurate. A task lifecycle can show that a delegated task was completed, but it cannot guarantee that the result serves the user's interests. These higher-order trust properties require the design frameworks that AXD provides.

Agentic commerce is perhaps the domain where these protocols will have their most immediate and visible impact. Consider a complete agentic shopping workflow - one that applies equally to consumer and B2B agentic commerce contexts:

A user tells their personal agent: "I need a new winter coat, waterproof, under 200 pounds, delivered by Friday." The agent uses MCP to access the user's preferences database, calendar, and budget tracker. It then uses A2A to delegate product search to a retail agent, delivery estimation to a logistics agent, and payment processing to a financial agent. Each of these agents returns results - the retail agent via ACP sends back a rich comparison with product images, reviews, and price histories. The personal agent synthesises these results and presents a recommendation to the user.

At every step, the protocols provide the structural foundation for the AXD frameworks. Intent architecture governs how the user's goal is decomposed into protocol-level actions. Delegation design governs the A2A task delegation - what authority the personal agent grants to each specialist, and under what constraints. The interrupt pattern library determines when the agent pauses to ask the user for input (A2A's "input-required" state maps directly to this). And absent-state audit provides the framework for reviewing what happened after the transaction is complete.

Google has already extended the protocol ecosystem with AP2 (Agent Payments Protocol), announced in September 2025, which builds on A2A to standardise payment flows between agents. And in January 2026, Google announced the Universal Commerce Protocol (UCP) - the first open standard that gives autonomous agents a common language for commerce itself. Where MCP, A2A, and ACP provide the communication infrastructure, UCP provides the commerce-specific vocabulary: merchant manifests, product discovery, checkout orchestration, and post-purchase lifecycle management. UCP is the commerce layer built on top of the protocol layer - a direct acknowledgment that agentic commerce requires not just communication standards but transaction standards. The practical implications for businesses are explored in the AXD Institute's guide to machine-readable commerce.

Designers working in the agentic space need to understand these protocols not at the implementation level - that is engineering work - but at the structural level. Protocols shape what is possible in the design space. They determine what information is available for observability interfaces, what trust signals can be surfaced to users, and what delegation patterns are structurally supported.

Protocol boundaries are design boundaries. Every time data crosses a protocol boundary - from agent to tool (MCP), from agent to agent (A2A/ACP) - there is an opportunity for information loss, trust degradation, or latency. Designers must account for these boundaries in their interaction models. A shopping interface that shows "searching for products..." is designing around the A2A task lifecycle. A transaction review screen that shows "your agent consulted 3 specialist agents" is designing around multi-agent orchestration visibility.

Discovery is a design problem. A2A's Agent Cards and ACP's agent registry create a new design challenge: how do users understand and control which agents their personal agent collaborates with? This is not a technical question - it is a trust and transparency question. The consent horizon extends to protocol-level agent discovery: when a user's agent finds and delegates to a new specialist agent, the user should understand that this has happened and have the ability to constrain it.

Multimodal content changes the observability surface. ACP's support for rich content exchange means that audit trails can include images, structured data, and annotated outputs - not just text logs. This dramatically expands the design space for observability interfaces. Designers can create review experiences that show users the actual artifacts their agents produced and consumed, making autonomous action legible in ways that text-only logs cannot achieve.

Failure modes are protocol-specific. MCP failures look different from A2A failures, which look different from ACP failures. A tool that times out (MCP) requires a different recovery pattern than a delegated task that fails (A2A) or a content exchange that delivers corrupted data (ACP). The failure architecture blueprint must account for protocol-specific failure modes and design appropriate recovery experiences for each.

MCP, A2A, and ACP are the connective tissue of the agentic age. They are to autonomous agents what TCP/IP was to networked computers: the shared language that transforms isolated capabilities into a connected ecosystem. Without them, every agent is an island. With them, agents can discover each other, verify capabilities, delegate tasks, exchange rich content, and coordinate complex workflows across organisational boundaries.

For practitioners of Agentic Experience Design, these protocols are not background infrastructure to be ignored. They are the structural grammar through which trust, delegation, observability, and failure recovery are implemented at scale. Every AXD framework - from intent architecture to ethical constraint - must be designed with awareness of the protocol layer that will carry it into production.

The protocols are young. MCP is barely two years old. A2A and ACP are younger still. They will evolve, converge, and spawn new standards - as Google's Universal Commerce Protocol already demonstrates, building a commerce-specific layer on top of the communication infrastructure that MCP, A2A, and ACP provide. But the design principles they embody - standardised discovery, structured delegation, rich content exchange, and open governance - are durable. They are the foundation on which the next generation of human-agent relationships will be built.

Protocols are not plumbing. They are the structural decisions that determine what trust, delegation, and observability are possible at scale. Design accordingly.