Agent Communication Protocols: How Autonomous AI Systems Exchange Information

Over the last few years, artificial intelligence has developed quickly from a research-driven field into a technology used in practical, real-world systems. This shift is changing technical environments from mostly separate applications into networks of autonomous agents that interact with one another. An autonomous agent is a software-based system or AI entity that can observe its surroundings, reason about them, and take action with a high level of independence. These agents can negotiate, create shared plans, exchange resources and information, and communicate during execution. Agent communication protocols define how this interaction works.

Agent communication protocols are standardized rules, languages, and message structures that determine how agents exchange information. Agents rely on these protocols to share knowledge, align decisions, and coordinate plans. The underlying ideas behind agent communication languages have existed for many years through classic multi-agent systems and academic work around FIPA ACL and KQML. However, this field is evolving quickly with the rise of large language models, JSON-based APIs, and agent orchestration frameworks such as MCP, LangGraph, AutoGen, and Swarm.

This article explains the fundamentals of agent communication languages and the structure of an agent message. It also explores practical use cases where agents communicate through both established concepts and newer protocols connected to modern developer tools.

Key Takeaways

• From monolithic systems to multi-agent ecosystems: AI systems are increasingly moving away from single, centralized applications toward ecosystems made up of many autonomous agents. These agents can reason, act, and communicate with each other through defined protocols.
• Communication needs structure and meaning: Agent communication languages such as FIPA ACL and KQML introduced performatives, content formats, and ontologies to make the purpose and meaning of messages explicit. These ideas still influence modern agent communication.
• Modern protocols rely on JSON and APIs: Current frameworks use JSON contracts, schemas, and standards such as the Model Context Protocol to define how LLM-based agents interact with tools and systems. This supports clearer communication, better interoperability, and stronger security.
• Security, trust, and observability are essential: Modern agent systems include permission controls, sandboxing, and logging to manage misaligned, faulty, or malicious agents. Message IDs, tracing, and replay capabilities are important for debugging and transparency.
• Standardization supports scalable collaboration: The principles of multi-agent systems and agent communication languages continue in ecosystems such as LangGraph, AutoGen, and Swarm, where well-defined message structures enable safer and more interoperable collaboration.

What Is Agent Communication?

Agent communication in multi-agent systems describes the exchange of messages between agents so they can collaborate. Similar to human communication, artificial agents use a shared language or protocol to interact with other agents and with their environment. These messages are not just raw data. They are structured units of information. For example, one agent may send a message to another agent to share a fact or to ask it to perform a specific action.

Why Agent Communication Protocols Are Necessary

If messages do not follow an agreed format, other agents may ignore them, reject them, or interpret them incorrectly. Protocols are important for several reasons:

• Interoperability: A common protocol allows agents created by different developers or built with different frameworks to communicate. It acts like a shared translation layer for agent interaction.
• Clear intent: Protocols define message types, often called performatives or speech acts, such as request, inform, or propose. These message types provide metadata that explains what the sender intends.
• Coordination and sequencing: Protocols often manage the flow of conversations. A defined communication protocol ensures that agents follow the same interaction pattern. For example, after sending a CFP, or call for proposal, an agent can expect either a proposal or a refusal in response.
• Reliability and error handling: Strong protocols include ways to handle invalid or unexpected messages. For example, an agent that receives a corrupted or unknown message may respond with a not-understood performative in FIPA ACL or a sorry message in KQML.
• Security and trust: In open agent environments, protocols can enforce constraints such as authentication fields or formal steps that must be completed before an action is allowed.

Classic Agent Communication Models

Early multi-agent system research introduced specialized languages for messaging between agents. Two of the most influential agent communication languages are KQML and FIPA ACL. Both introduced structured message formats and semantics based on speech-act theory, and both continue to influence modern protocols.

KQML: Knowledge Query and Manipulation Language

KQML, or Knowledge Query and Manipulation Language, was developed in the early 1990s as part of DARPA’s Knowledge Sharing initiative. KQML defines a set of message performatives, or verbs, that describe the purpose of a message. These performatives work like a formal code of conduct for agent conversations.

Typical performatives include actions such as ask, which queries information; tell, which provides information; achieve, which asks another agent to accomplish a goal; and reply, which answers a query.

In KQML, the message content is separated from the communication wrapper. A KQML message is written as a list using Lisp-like parentheses. The first element is the performative, followed by parameters such as content, sender, and receiver. Conceptually, a KQML message can look like this:

(ask-one
  :sender Agent1
  :receiver Agent2
  :content "(temperature ?x)"
  :language LPROLOG
  :ontology weather)

In this example, ask-one is the performative, meaning Agent1 asks Agent2 a question. The content could represent a query such as temperature ?x in a logical language, while the ontology and language fields explain how that content should be interpreted.

KQML was also one of the first approaches to introduce communication facilitator agents. A facilitator acts as a broker or mediator that routes messages and helps agents discover one another. For example, one agent can register its services with a facilitator. When another agent sends a query using a performative such as ask, the facilitator can forward the request to the registered agent capable of answering it.

KQML also included performatives for networking-related actions such as register, forward, and broadcast. It supported early asynchronous messaging patterns as well, including subscribe, which allows an agent to request ongoing updates when a condition changes.

FIPA ACL: Foundation for Intelligent Physical Agents ACL

After KQML, FIPA ACL became the next major standard. It was widely used in the late 1990s and early 2000s. FIPA is an IEEE standards organization focused on creating specifications for interoperable distributed multi-agent systems. FIPA ACL refined the list of performatives and defined more formal semantics based on agent mental states such as beliefs, desires, and intentions.

FIPA ACL defines around 20 standard performatives, also called communicative acts. Many of them are based on KQML, while others were added later. Common FIPA performatives include:

• inform: informs another agent about information the sender believes to be true. This is one of the most frequently used performatives and acts as a factual statement.
• request: asks another agent to perform an action.
• confirm / disconfirm: confirms that something is true or false when the sender believes the receiver was uncertain about it.
• cfp: stands for call for proposal and is used to request proposals for an action, often in contract-net interactions.
• propose: sends a proposal in response to a CFP.
• accept-proposal / reject-proposal: accepts or rejects a received proposal.
• agree: indicates that the agent agrees to attempt the requested action.
• refuse: indicates that the agent refuses to perform the requested action and may include a reason.
• failure: shows that a requested action could not be completed.
• query-if / query-ref: sends a yes/no query or asks for a specific piece of information.
• subscribe: requests continuous notifications when information changes.
• not-understood: signals that the received message could not be understood.
• Additional performatives: include cancel, proxy, and other message types that support more advanced communication behavior.

A FIPA ACL message uses a fixed set of fields. The only required field is the performative, but most messages also include fields such as sender, receiver, content, ontology, language, and conversation-id. A FIPA-style message can be represented like this:

(performative INFORM
:sender Agent1
:receiver Agent2
:ontology WeatherOntology
:language JSON
:content "{ 'forecast': 'sunny' }"
:conversation-id conv123)

This format is similar to a structured business email or formal letter. It includes the sender, recipient, message type, content, and optional references such as a thread ID. The ontology field defines the vocabulary or context used by the message content, while the language field defines the content format, such as a logic syntax, plain text, or JSON.

Agent Message Structure

The message structure developed through classic agent communication languages is still important because the same pattern appears in many modern protocols, even when the format changes to JSON fields or API schemas. The main elements of an agent communication message are:

• Performative: The performative defines the communicative act being performed. It explains why the message is being sent and tells the receiver how to process it. The message could be a request for an action, a factual announcement, or a contract proposal. In FIPA ACL, the performative is required and appears first.
• Content: The content is the actual payload of the message. It may contain a proposal, a question, a command, or domain-specific data. For example, it could state that the temperature is 20°C, ask whether the temperature is greater than 30, or request that a thermostat be increased to 25.
• Ontology: In agent communication, an ontology is the vocabulary or knowledge schema that defines how the content should be understood. For example, agents discussing travel may use a travel ontology that defines terms such as flights, prices, and booking objects.
• Language or encoding: The language field defines the syntax or encoding used for the content. The content could be natural language, JSON, a Prolog clause, XML, or another representation. By specifying the content language, the sender tells the receiver how to parse the message.
• Participants: Each message includes information about who sends it and who should receive it. In one-to-one communication, there is one sender and one receiver. In broadcast or multicast communication, the protocol may support multiple receivers or a group identifier.
• Protocol: Some messages belong to a predefined interaction protocol, such as a contract-net negotiation or an auction. A protocol field identifies the context of the message so the receiver can interpret it correctly.
• Conversation tracking: Multi-step conversations need identifiers that connect messages into threads. Fields such as conversation-id and reply-to help agents match responses to the correct request, especially when several conversations happen at the same time.

Modern Evolution: LLM Agents and JSON Contracts

Large language models such as GPT-4 and Claude have brought natural-language-based agents into mainstream software development. Modern agent frameworks place LLMs inside multi-step workflows and need a reliable way to represent and execute tasks based on natural language requests. Tool or function calling provides this bridge. Instead of returning plain text only, the LLM can produce structured JSON that describes a function call. When the model chooses a tool, it creates a JSON object containing the function name and its arguments.

The workflow is straightforward. A user request is processed by an LLM agent. The agent can either generate a text response or call an external tool. A function call is emitted as a JSON document that identifies a specific tool and provides a dictionary of key-value arguments, such as a get_weather tool with a city value like Paris. The tool runtime authorizes the call, forwards it to the registered function, and receives a structured result, such as a JSON object containing the temperature and weather conditions. That result is passed back to the agent, which then uses it to continue planning or generate a response.

JSON contracts separate LLM reasoning from the execution environment. The LLM decides when a tool should be called, while external code handles execution with authentication, error handling, and logging. The structured format can reduce injection risks and makes messages easier to parse. Compared with the abstract syntax of FIPA, JSON is widely supported across programming languages and fits naturally with web APIs.

However, this model often leaves performative semantics implicit. In other words, the intent or message type is not always declared as clearly as it is in agent communication languages like KQML or FIPA ACL. JSON contract patterns are therefore highly useful for modern LLM workflows, but they trade explicit communicative acts for natural-language-driven control.

How MCP, the Model Context Protocol, Fits In

MCP, or Model Context Protocol, can be understood as an open standard proposal for connecting AI agents, especially LLM-based agents, with tools, external data sources, and other agents in a structured way. OpenAI, Anthropic, and other organizations are supporting similar standardization efforts to create a shared interoperability layer for AI systems.

Technically, MCP is built on JSON-RPC 2.0, a lightweight remote procedure call protocol that uses JSON. In simple terms, MCP defines agreed message formats that allow an AI model to send a request such as “call tool X with these parameters” and receive a predictable JSON response, regardless of the specific tool or the organization that created it.

For example, imagine an AI agent needs weather information. Without a standardized protocol, a developer might write a custom prompt such as: “Call the weather API with key=ABC to retrieve the weather for London” and then rely on custom code to parse the result.

With MCP, the agent could instead send a JSON-RPC request to a weather tool endpoint exposed by an MCP server. The request could look like this:

{“jsonrpc”: “2.0”, “method”: “getWeather”, “params”: {“city”: “London”}, “id”: 1}

The MCP server would know how to handle the request, most likely by calling an actual weather API in the background, and would then return a JSON result. The agent receives that result in a predictable structure.

MCP plays an important role in modern agent communication because it brings many benefits of traditional agent communication languages, such as standardization and defined behavior, into the current environment of AI tools and LLM workflows. Although MCP focuses mainly on communication between agents and tools, it standardizes a large part of practical agent interaction.

Where Agent Communication Protocols Are Used

Agent communication protocols may sound abstract, but they are used in many advanced AI and automation systems today. The following examples show common scenarios where structured communication between agents is useful or necessary:

Challenges of Agent Communication Protocols

Agent communication protocols create structure, but they also introduce challenges. The following table connects typical issues with practical design practices:

Example of an Agent Message Exchange

To combine the concepts discussed so far, consider a simple scenario involving two agents. Agent A acts as a client, while Agent B can provide information. Agent A wants to know the current temperature in Paris, and Agent B is capable of supplying that information.

Using a traditional communication protocol, Agent A could send a message with the performative set to request and content similar to “Provide temperature for Paris.” After receiving the message, Agent B would determine whether it can satisfy the request. If it can, it might respond with a performative of inform and content such as “Temperature in Paris is 18°C.”

In a FIPA ACL representation, the message exchange could look like this:

Agent A → B: (request :sender A :receiver B :content “query-temperature(Paris)” :ontology Weather)

Agent B → A: (inform :sender B :receiver A :content “temperature(Paris,18)” :ontology Weather)

This example demonstrates the structured nature of agent communication. Agent A sends a request, making it clear that an action is expected. Agent B responds with an inform message, clearly indicating that the message contains information rather than a rejection, question, or alternative response.

Using JSON-RPC and MCP

In a modern JSON-RPC-based workflow using MCP, Agent A could invoke a tool rather than sending a traditional ACL message. The interaction could appear as follows:

{“method”: “get_temperature”, “params”: {“city”: “Paris”}, “id”: 123}

The MCP server, effectively taking the role of Agent B, would process the request and respond with:

{“id”: 123, “result”: 18}

Agent A can then incorporate the returned value into its own reasoning process or user-facing response. Although the communication mechanism differs from ACL-based messaging, the conceptual pattern remains the same: a request is made and information is returned. The difference is that the information arrives as a structured RPC result rather than an explicit inform performative.

Using Plain Language Between LLM Agents

Communication can also occur without a formal protocol. Two LLM-based agents may interact using natural language alone. For example:

Agent A: “Do you know the current temperature in Paris?”

Agent B: “The temperature in Paris is approximately 18°C.”

This exchange is easy for humans to understand and works because both models have been trained on natural language. However, unlike formal communication protocols, there are no explicit indicators of message intent. The interpretation depends entirely on implicit semantics.

In structured communication systems, nothing is left to implication. Message types, expectations, and interaction rules are explicitly declared. This clarity becomes increasingly important as systems grow in complexity.

Although these examples are intentionally simple, they illustrate the different ways agents can exchange information. As systems expand to include dozens of collaborating agents, complex workflows, and sophisticated tool integrations, communication protocols become significantly more valuable for maintaining reliability, predictability, and interoperability.

Conclusion

Agent communication has become a fundamental component of modern AI ecosystems. It enables autonomous systems to exchange information, coordinate actions, and collaborate effectively. A successful approach typically combines structured message formats such as JSON contracts or MCP with clearly defined intent fields that fulfill a role similar to traditional FIPA performatives.

Security and access control should be considered from the beginning of any agent architecture. Equally important is observability, including message identifiers, tracing capabilities, replay mechanisms, and detailed logging. These features help developers understand how agents interact and make it easier to diagnose failures.

Although the original concepts introduced by multi-agent systems, KQML, and FIPA ACL continue to influence communication semantics, modern frameworks such as LangGraph, AutoGen, and Swarm provide practical methods for implementing those concepts at scale.

For teams building agent-based systems today, a practical approach is to start with a minimal structure that defines inputs, outputs, identifiers, and timeouts. From there, communication can gradually evolve toward more structured tool calls and standardized semantics that support interoperability between autonomous components.

It is also important to measure communication overhead, including token consumption and latency, while implementing safeguards such as sandboxing and access restrictions for potentially unsafe actions. Over time, systems can be refined to handle edge cases, failure scenarios, and growing complexity.

A communication protocol does not need to be perfect from the beginning. What matters most is that it consistently enables autonomous components to collaborate reliably, exchange information effectively, and coordinate their actions in a predictable manner.