Hi everyone! 👋

Nowadays, protocols are everywhere, and so are confusions. There are simply so many things that a protocol can do, even for tools as well as multi agents, that it is very hard to pinpoint finger on which one to use and when.

This issue breaks down everything you need to know: what agent protocols are, why they exist, the three major categories, and how to choose the right one.

An AI agent protocol is a formal set of rules defining how AI agents interact with tools, coordinate with each other, and exchange information across systems. It's the shared language that makes collaboration possible between agents built by different vendors, running on different infrastructure, and designed for different purposes.

Without it, every connection requires custom code, and that compounds fast.

When every agent needs a custom integration for every tool, the math breaks you: 100 agents × 50 data sources = 5,000 integrations to build, maintain, and update every time something changes on either side.

Protocols collapse that complexity. When agents implement one standard client and tools implement one standard server, 100 + 50 = 150 total implementations. Add a new tool, update one server, not a hundred codebases.

This shift has happened before. HTTP standardised browsers and servers. SMTP standardised email. Those protocols became the invisible infrastructure on which everything else was built. AI agent protocols are doing the same for autonomous systems, turning a fragmented ecosystem into a composable infrastructure.

The organisations implementing these standards now are the ones building on solid ground.

Without standards, AI agents are expensive, siloed, and brittle. Three structural problems explain why protocols matter:

Agents that can't connect and coordinate don't automate anything. Protocols are what turn AI from an interesting capability into operational infrastructure.

The agentic AI stack has organised itself into three complementary layers. Each solves a different problem. Each is necessary. And they work best when combined.

MCP is now governed by the Linux Foundation

MCP is the foundational standard for connecting AI agents to the outside world. Before MCP, every agent needed a bespoke bridge to every external system: databases, APIs, file systems, search engines. MCP eliminates that. Both sides implement one open spec, and interoperability comes built in.

The architecture runs on three components: an MCP Client lives inside your AI application (Claude, ChatGPT, Cursor, VS Code), an MCP Host manages the LLMs processing requests, and an MCP Server exposes capabilities from external systems like Slack, Brave Search, or internal databases. Communication runs over JSON-RPC 2.0 via stdio or HTTP, powered by three primitives: Tools (functions agents invoke), Resources (data agents read), and Prompts (reusable workflow templates).

A user asks their assistant to find a Q3 sales presentation. The agent sends a request through its MCP client to a Google Drive MCP server. The server searches, returns the document, and the agent summarizes it. No custom integration. No bespoke connector. Just the protocol doing its job.

It is now governed by the Linux Foundation.

A2A enables AI agents to communicate and collaborate directly, regardless of who built them or what framework they run on. A Client Agent built on Google ADK can delegate tasks to a Server Agent built on LangChain, with no shared codebase and no knowledge of each other's internals.

The core mechanism is Agent Cards, structured JSON files published at .well-known/agent.json that describe what an agent can do, what modalities it supports (text, files, streaming, audio), and how to reach it. Think of it as a standardized business card for AI agents. From there, agents dynamically discover each other, delegate tasks to specialists, negotiate communication formats, and manage long-running workflows with human-in-the-loop checkpoints, all without exposing internal architecture.

A hiring agent delegates background checks to a specialist agent without knowing how that agent works internally, only what it accepts and what it returns. The entire handoff is protocol-mediated, auditable, and vendor-agnostic.

Cisco · Enterprise-Focused

SLIM is a lightweight multi-agent communication protocol built specifically for enterprise environments where latency and network overhead are hard constraints. Where most protocols optimize for capability and flexibility, SLIM optimizes for speed and efficiency within controlled infrastructure.

Messages from local agents flow through an Orchestrator Gateway to an IOA Agent Gateway running on a runtime gRPC host server, which routes work to remote agents on the other side. The protocol is designed to minimize round-trip overhead and operate efficiently within existing on-premises and hybrid enterprise architectures, with no cloud dependency required.

An enterprise infrastructure team running agentic workflows across internal systems, ERP, HR platforms, and internal APIs can orchestrate agents without routing traffic through external cloud services. SLIM keeps coordination fast, local, and within the network perimeter.

IBM & BeeAI · Local-First

ACP is built for environments where cloud-first coordination isn't viable. Air-gapped systems, edge computing deployments, privacy-critical workloads, and real-time industrial applications all share a common problem: round-tripping to the cloud introduces unacceptable latency or violates data residency requirements. ACP was purpose-built to solve exactly that.

Unlike A2A's peer-to-peer model, ACP uses a client-server architecture: an ACP Client routes requests to AI agents equipped with frameworks and MCP servers. The ACP Protocol layer handles discovery, agent details, and message structure, then delivers to the receiving agent on the other side. Everything can run entirely within a local or air-gapped environment.

A manufacturing plant running real-time quality inspection agents, a hospital system with strict data residency requirements, or a government deployment in an air-gapped network can all run sophisticated multi-agent workflows without any external cloud dependency.

University of Oxford · Research-Origin

Agora takes a fundamentally different approach to agent coordination. Instead of a fixed protocol that all agents must implement, Agora uses natural language processing to dynamically generate task-specific coordination protocols on the fly. Agents don't follow a pre-defined standard; they create their own rules for each task they encounter.

A request enters Agora's three-stage pipeline: Natural Language Processing interprets the task, Protocol Generation creates a custom coordination protocol suited to that specific task, and Protocol Distribution delivers the generated protocol to the relevant specialist agents. Originally built for travel domain orchestration, it's designed for highly dynamic scenarios where no single static protocol covers all cases.

A travel agent receives a complex trip request. Agora generates a Flight Protocol for the flight booking agent, a Booking Protocol for the hotel agent, and a Weather Protocol for the weather agent, all dynamically, all tailored to the specific task at hand. No pre-built integrations required.

TeamANP · Distributed Networks

ANP is designed for a specific and important problem: distributed knowledge sharing across networks of specialized agents where no single agent holds all the relevant context. In complex multi-agent systems, the information needed to complete a task is often scattered across many specialized agents. ANP provides the protocol layer for those agents to share what they know with each other efficiently.

Agents in an ANP network can request information from and share information through a standardized protocol layer. In the travel planning example, a Travel Agent receives a user request, then uses ANP protocols to coordinate with Hotel, Weather, and Booking agents, each sharing and receiving relevant information across the network, with the final travel plan returned to the user.

A research assistant agent that needs to synthesize information from agents specializing in different knowledge domains, literature, data analysis, and current events, uses ANP to pull distributed knowledge into a coherent output without any single agent needing to hold all the context.

CopilotKit · Frontend Bridge

AG-UI solves a problem the other protocols don't address: how do agent capabilities surface cleanly in user-facing applications? Most protocols handle backend coordination invisibly. AG-UI bridges that gap, connecting backend agent workflows to frontend interfaces so users can actually see and interact with what agents are doing.

AG-UI connects frontend applications (built in React, Vue, or similar) to backend agent systems via the AG-UI Protocol. The backend runs on Google ADK, which connects to available Tools, Models, and Remote Agents. The AG-UI layer translates agent activity into UI events that frontend applications can render progress updates, results, interactive prompts, and more, all in real time.

A user opens a web application and asks an agent to analyze their sales data. Instead of a spinner and a final result, AG-UI streams the agent's intermediate steps into the UI, showing which data sources it accessed, what it found, and where it's uncertain, giving users visibility and control over the process, not just the output.

These protocols aren't competing for the same job. Each occupies a distinct layer of the agentic stack. A production system might use all of them simultaneously.

Thanks for reading

— Rakesh’s Newsletter