# Agent Communication Protocols

Standards for agents to exchange messages, delegate tasks and share results across systems and vendors.

**Rests on:** Agent Loop, Subagents

**Leads to:** Agent Cards, Business Workflow Integration, Escalation Workflows

*AI Agents · AI Agents*


## Why learn this

This lets you build AI systems where independent programs work together reliably, even if they were created by different people or companies. You already see this in complex agentic workflows—the step-by-step processes your library uses—where agents must coordinate to finish a task. Understanding protocols helps you spot the security trade-offs: every time you add a new way for agents to talk, you add a 'trust boundary,' which is simply the point where you can no longer fully verify who sent a message or whether it has been tampered with. This knowledge lets you see why some systems are fragile and how to design them so they remain secure as they grow.


## The intuition

Imagine you are in a busy office. People need to share information and ask each other to do things. If everyone just shouted whatever they wanted, in whatever order, with no rules about how to phrase a request or how to confirm it was understood, chaos would result: messages would be lost, requests would be misinterpreted, and nobody would know who was responsible for what. So the office adopts a set of rules: 'When you want something, write it on a form, hand it to the correct person, and they will write back either done or why not.' That set of rules—what a message looks like, how it's addressed, what responses are possible, and in what order—is a communication protocol. It doesn't tell anyone what to say, only the shape of the conversation. In the world of AI agents, the same problem appears. An agent (a program that uses a large language model to plan and act) needs to ask another agent for information, or ask it to perform a task, and then receive the result. Without a shared protocol, each agent would have to be custom-built to talk to each other specific agent—the same as if every person in the office had to learn a separate language for every colleague. A protocol is the shared language and etiquette that lets any agent talk to any other agent, as long as they both follow the rules.


## An analogy

The best analogy is a postal system. When you send a letter, you don't need to know the exact person who will carry it, nor do you need to arrange for them to meet you. You write your message on paper, put it in an envelope, write the address in a standard format (street, city, postal code), and drop it in a mailbox. The postal service guarantees that if the address is right and you've paid the postage, the letter will arrive at the destination. The recipient reads it, and if they choose to reply, they do the same in reverse. The protocol here is the set of rules: the envelope size, the address format, the postage, the delivery guarantee. It doesn't matter what language the letter is written in, or what the content is—the protocol is about the wrapping and the routing. Now, AI agents work similarly. An agent sends a message (like a letter) to another agent (the address). The message is wrapped in a standard format (the protocol's envelope), which includes things like 'who is the sender', 'who is the receiver', 'what type of message this is' (a request, a response, an error), and the payload (the actual content). The receiving agent can unwrap it because it also understands the protocol. The analogy has one caveat: AI agents are much more literal than humans; if a message is missing a field or has a wrong type, the agent will often reject it outright.


## Definition

An agent communication protocol is a set of rules that defines how two or more AI agents exchange messages—the structure of a message, the allowed message types, the order in which they can be sent, and the expected responses—so that the agents can cooperate without being custom-built for each other.


## How it connects

You already have notes on AI Agents, and you know that beneath every framework lies a message loop. This concept is about the rules that govern those messages. It connects directly to Agent Cards—directory entries that describe an agent's capabilities so another agent knows who to send a message to and what that agent can do—and Agent Executors, which are the runtime environments that actually send and receive the messages. A protocol is simply what those executors use to format and parse the data they carry.


## The mathematics

This concept has no real mathematical content in the sense of equations—it is about structure and rules, not quantities. The only 'math' is the logic of finite state machines: a protocol can be thought of as a set of states (waiting for a message, processing, sending a response) and transitions (what triggers a change from one state to another). This is a branch of mathematics called discrete mathematics, which deals with structures that are countable and have discrete steps—like the branches of a decision tree—rather than continuous quantities like speed or temperature. In this context, 'math' is about specifying the exact conditions under which a message is valid. For example, a rule might say: 'If a request message is received, the agent must respond with either a success or a failure message, and never with a third type.' That's a logical rule, not a numerical formula. But it's still mathematics in the sense that it's precise, unambiguous, and can be reasoned about rigorously.

Because the content of a message is arbitrary, the protocol is purely about structure. A formal way to express it is as a grammar, but that's beyond this level. The key idea is: a valid conversation is a sequence of messages that follows the rules. In pseudo-mathematical terms: a conversation is valid if it can be generated by the protocol's rules. No numbers are involved.


## A worked example

```
Let's model a simple protocol as a state machine. We have two agents, A and B. The protocol allows only two message types: REQUEST and RESPONSE. The state machine has two states: IDLE (waiting for a message) and BUSY (processing a request). We'll track the state transitions for a sample conversation.

Step 1: Step 1: A sends REQUEST to B. B transitions from IDLE to BUSY.   # The protocol says a REQUEST is only valid when B is IDLE. If B were BUSY, the protocol would specify an error (say, a BUSY_RESPONSE).
Step 2: Step 2: B processes, then sends RESPONSE to A. B transitions from BUSY back to IDLE.   # The RESPONSE is only valid when B is BUSY; sending it while IDLE would be a protocol violation.
Step 3: Step 3: A receives RESPONSE. A's state doesn't change (A has no state in this simple model).   # The protocol only constrains B's states, but it could also constrain A's if we wanted.
Step 4: Step 4: If B had been BUSY when A sent REQUEST, the protocol might specify that B sends a BUSY_RESPONSE, and A retries after a timeout.   # This is a retry logic—a key part of real protocols.

Result: This simple state machine shows that a protocol is a set of allowed sequences. The 'mathematics' is in precisely defining which sequences are legal, which is a logical, not numerical, exercise.
```


## Common misconceptions

**A protocol is a programming language** — A protocol is like a programming language, with variables and loops.

Protocols are about message structure and allowed sequences, not computation. They don't have loops or conditionals in the way a language does; they're more like a template for a conversation. In fact: A protocol is a set of rules for how messages are formatted and exchanged. It's a contract, not a language.

**Agents must use the same protocol to communicate** — For two agents to talk, they must both implement the very same protocol specification.

This is true in the sense that they must both follow the same rules, but they don't need to be written in the same programming language or run on the same platform. The protocol is a shared specification; the agents can be in different frameworks as long as they speak the same 'wire format'. In fact: The protocol defines the format and semantics of messages; as long as both sides adhere to that specification, they can be built with completely different technologies.

**Protocols are only for multi-agent systems** — Protocols only matter when you have multiple agents talking to each other.

Even a single agent interacting with a REST API is using a protocol (HTTP). The concept is broader than multi-agent systems. In fact: Protocols are used whenever one system communicates with another, whether that's an agent-to-agent, agent-to-tool, or client-to-server.

**A protocol guarantees the message will be understood** — If I follow the protocol, the other side will definitely understand my message.

The protocol only ensures the message is well-formed; the semantic content still needs to be interpreted correctly. A message can be well-formed but ambiguous, leading to misunderstandings. In fact: Protocols handle the format and sequencing; the actual meaning of the content is up to the agents. A well-formed message can still be semantically wrong.

**More protocols is always better** — If I use more protocols, I'll have more flexibility and better interoperability.

Each protocol adds complexity and a new trust boundary. More protocols mean more places for errors and attacks. Simplicity and a single, well-designed protocol often work better. In fact: The best protocol is the simplest one that meets your needs. Adding more protocols increases the surface area for bugs and security issues.


## In short

An agent communication protocol is a set of rules for exchanging messages between agents. It defines the message format, the allowed message types, the order they can be sent, and the expected responses. It's the shared language that lets independent agents work together. Every agent system depends on protocols, and every protocol is a trust boundary. Remember: protocols are about structure, not content; they are not programming languages; and simplicity is a virtue.


## Where this is used

Agent communication protocols are the plumbing that makes every multi-agent system possible, but they're also used in single-agent systems that need to call external tools over a network. In large language models, protocols aren't usually in the model's weights—they're in the scaffolding around it. When you use a model like GPT-4 through an API, the request/response format (JSON in, JSON out) is a de facto protocol. More specifically, when an LLM is used as an agent, it often communicates with other agents via a message protocol like the Anthropic Message Protocol (MCP) or a custom JSON-RPC. The model itself doesn't 'know' the protocol; it's the wrapper that formats the model's output into a protocol-compliant message. In small language models running on devices (like your phone's keyboard or a smart speaker), protocols are even more constrained: the messages are shorter, the bandwidth is limited, and the protocol must be lightweight to save battery. A common pattern is to use a binary protocol (like Protocol Buffers) that encodes the message efficiently. In retrieval-augmented generation (RAG), the agent must query a knowledge base. The communication between the agent and the retrieval system is often via a REST API, which is a communication protocol: the agent sends an HTTP request with a query, the retrieval system responds with a set of documents. The agent's protocol is not just the HTTP layer—it's also the schema of the request (what fields are included, like 'query', 'top_k', etc.). In agentic systems that plan and call tools, the protocol is the backbone. The agent loop—think of your Agent Loop notes—is essentially a sequence of protocol messages: the agent sends a 'tool call' request to an executor, the executor sends back a 'tool result' message, and the agent uses that to decide the next step. Frameworks like LangGraph and AutoGen implement protocols internally; the developer often writes code that interacts with the protocol's API. For everyday applied machine learning, protocols come into play when you deploy a model as a service. A typical setup is to wrap the model in a Flask or FastAPI server that accepts a JSON request (a protocol) and returns a JSON response. If the service is called by another service, both must agree on the protocol. In practice, a developer reaches for a protocol library: REST (using JSON) for simple cases, gRPC for high-performance internal communication, and MCP (Model Context Protocol) for agent-to-agent and agent-to-tool communication. What breaks when it's done badly? If the protocol is overly rigid (e.g., it requires an exact schema), a small mistake in a field name causes the message to be rejected. If it's too loose (e.g., it sends free-form text), the agent may misinterpret the intent. In multi-agent systems, a failure in one message can cascade: a malformed response can cause the caller to make a wrong decision, leading to a chain of errors. Security is another major concern: a protocol that doesn't validate the sender or the content is vulnerable to injection attacks. Your library notes on Prompt Injection are relevant here: an attacker can craft a message that, while protocol-valid, carries a hidden instruction that changes the agent's behavior.


---

Read this on the web: https://basavapurushottam.com/learn-ai/agent-communication-protocols
