Example of AI Agent-to-Agent (A2A) Communication Over MQTT
AI Agent-to-Agent (A2A) communication holds enormous potential, but to make it practical at scale, it needs more than just semantic standards; it needs the right transport layer. In our previous blogs, we have established two critical insights: First, the A2A protocol provides valuable semantic standards for agent discovery, capability description, and message formatting. Second, its HTTP/gRPC transport layer creates insurmountable scaling challenges.
Here's part 4 of the blog series An MQTT Architecture for Scalable Agentic AI Collaboration, which demonstrates a hybrid approach that preserves A2A's semantic richness while leveraging MQTT's architectural superiority.
A2A shows great promise, though it’s still in the early stages. As such, in this section, we’ll share what we’ve learned so far and illustrate how A2A can be mapped onto MQTT.
Our example is simple yet powerful: Keep A2A's payloads, replace the transport. This maintains interoperability in the AI agents ecosystem while enabling the scalability required for enterprise-wide agent deployments.
MQTT Topic Design for AI Agent Communication
Agentic systems vary widely, from autonomous AI agents that operate independently over long periods to more structured agentic workflows that follow predefined sequences. To design an effective MQTT topic namespace for AI agent communication, it's essential to first make a clear architectural distinction between AI Agents and Agentic Workflows.
MQTT Topic Design for Agentic Workflows
An Agentic Workflow is a sequence of well-defined stages, orchestrated to achieve a specific goal. Each stage may involve an AI model, a traditional software program, or even a human operator. Importantly, the sequence is designed in advance, often in a linear or branching structure, with built-in checkpoints for human oversight.
For example, in a manufacturing assembly line:
A Part Inspection Agent captures an image of each part and analyzes it for visible features or defects.
A Quality Control Agent receives the inspection results and determines whether the part should be marked as Pass, Rework, Reject, or Hold for manual inspection.
A Supply Chain Agent then uses this output to adjust inventory levels, reorder parts, or update delivery schedules accordingly.
This kind of pipeline benefits greatly from an event-driven architecture, where agents communicate by publishing and subscribing to events. Workflows emerge naturally from the flow of these events, and there’s no need for centralized orchestration. Each agent only reacts to relevant events and emits new ones, allowing the system to evolve organically.
In the example above, MQTT topics could be designed as follows:
Inspector Agent:
global-industries/munich-plant/line1/inspection-agent/tasks
global-industries/munich-plant/line1/inspection-agent/status
global-industries/munich-plant/line1/inspection-agent/results
Quality Control Agent:
global-industries/munich-plant/line1/quality-control-agent/tasks
global-industries/munich-plant/line1/quality-control-agent/status
global-industries/munich-plant/line1/quality-control-agent/results
Supply Chain Agent:
global-industries/munich-plant/line1/supply-chain-agent/tasks
global-industries/munich-plant/line1/supply-chain-agent/status
global-industries/munich-plant/line1/supply-chain-agent/results
Each agent knows which events to consume and produce, but it doesn’t need awareness of the full workflow. This separation of concerns enables scalable and flexible automation.
Recommended MQTT Topic Structure for Agentic Workflows
To support such event-driven workflows across a distributed agentic system, below is an example of a base topic structure:
Top-level Namespace
<version>/agents
This prefix identifies the namespace version and isolates agent traffic from other MQTT topics.
It also enables coarse-grained access control (ACLs), making it easier to manage monitoring and permissions.
Discovery Namespace for Agent Cards
The discovery namespace is a well-known location where agents publish their availability by posting A2A-compliant Agent Cards. It is also where agents look to discover other available agents in the MQTT network. These Agent Cards are published with the MQTT retained flag set to true, ensuring they remain available for future subscribers.
discovery/<org>/<agent-id>
discovery/: Separates announcements from operational traffic<org>: Enables organization-level grouping. This can be extended with a semantic hierarchy such as ISA-95<org>/<site>/<area>/work-center>
Agent-Specific Namespace
<org>/<agent-id>
Each agent should have its own namespace containing standard subtopics:
tasks: For task input, coming from sensors, user interfaces, or other agents.status: For broadcasting current state, typically consumed by dashboards or other systems.results: For publishing output, to be consumed by downstream agents or systems.
MQTT Topic Design for AI Agents
Unlike agentic workflows that follow predefined steps, autonomous AI agents are driven by high-level goals rather than fixed sequences. They decide what actions to take, learn from the outcomes, and continuously refine their behavior through an internal loop of planning, acting, reflecting, and re-planning. Depending on what they determine is useful, they may or may not involve human input.
For example, in a manufacturing setting, a plant manager might assign the goal: “Reduce total energy consumption by 15% this quarter.” The AI agent would then determine which other agents or systems to engage to achieve that objective. The agent dynamically coordinates actions across the system without a predefined path.
This goal-driven, dynamic nature makes autonomous agents a perfect fit for MQTT 5’s request-reply pattern. In this model, any agent can request services from another by publishing to a specific "inbox" topic, while also specifying where the response should be sent. Each agent listens to its request topic and handles incoming tasks independently.
This approach offers several benefits:
Asynchronous: Agents don’t require direct connections to communicate.
Scalable: Multiple responders can share the same request topic.
Reliable: MQTT’s Quality of Service (QoS) levels ensure dependable message delivery.
Stateless: The broker doesn’t need to manage or store request-reply relationships.
These features enable flexible, loosely coupled interactions, allowing agents to discover and collaborate on-demand, query one another for specialized tasks, or broadcast operational events as needed.
Example: Request-Reply Communication Between Two Agents
Here’s how two AI agents interact using the MQTT 5 request-reply pattern:
Request Phase:
Agent A (the requester) publishes a task to a topic like:
agents/agent-b/requestsThe message includes:
A Response Topic (e.g.,
responses/agent-a/temp123) so it knows where to receive the replyA Correlation Data field to match the response with the original request
The request payload (task data)
Processing Phase:
Agent B (the responder) subscribes to its own
requeststopicUpon receiving the request, it processes the task and extracts the
Response TopicandCorrelation Datafrom the MQTT message properties
Reply Phase:
Agent B publishes the result to the provided
Response TopicThe message includes the original
Correlation DataAgent A, subscribed to its response topic, receives the reply and matches it to the initial request
Recommended MQTT Topic Structure for AI Agents
To support scalable AI agent interactions across distributed environments, we recommend the following topic conventions:
Top-Level and Discovery Namespace
These remain consistent with those used in agentic workflows:
discovery/<org>/<agent-id>– For publishing retained Agent Cards that announce agent availability
Agent-Specific Topics
Each agent has its own namespace:
<org>/<agent-id>/requests– For receiving direct task requests (the agent MUST subscribe to this topic)<org>/<agent-id>/status– For broadcasting the agent’s current state<org>/<agent-id>/events– For emitting general-purpose events that other systems or agents may consume
This structure enables both direct service calls and broad event dissemination, allowing autonomous AI agents to operate flexibly and cooperatively within an MQTT-based communication infrastructure.
MQTT Payload Design for AI Agent Communication
Now that we’ve defined the topic structure for AI agent communication using MQTT, let’s focus on how to structure the message payloads. As previously mentioned, the A2A specification provides a strong foundation for semantic interoperability, covering agent discovery, capability description, and message formatting.
We provide examples for adopting the A2A payload semantics as a basis for MQTT-based agent communication. Initially, our approach uses simplified structures suitable for MQTT transport, but the long-term goal is to maintain backward compatibility with existing A2A HTTP endpoints, eventually enabling seamless bridging between HTTP/gRPC-based agents and MQTT-based agents.
AI Agent Discovery Using MQTT
Each agent announces its availability by publishing an A2A-compliant Agent Card to the discovery topic namespace. This message is published with:
Retained = true(to persist the agent’s presence for future subscribers)QoS = 1(to ensure reliable delivery)
The payload includes metadata describing the agent, including:
A
urlfield pointing to the agent-specific MQTT topic namespace used for operational communicationA
preferredTransportfield set to "MQTT"An
additionalInterfacesfor optional direct access via HTTP/gRPC
Example Discovery Message
Topic: agents/discovery/global-industries/supply-chain-planner-001
Retained: true
QoS: 1
Payload:
{
"protocolVersion": "1.0",
"name": "Supply Chain Planning Agent",
"description": "Optimizes inventory levels based on demand signals",
"url": "mqtts:v1/agents/globalindustries/supply-chain-planner-001/",
"preferredTransport": "MQTT",
"additionalInterfaces" : [
{"url": "https://globalindustries.com/a2a/v1", "transport": "JSONRPC"}
],
"version": "1.2.0",
"defaultInputModes": ["application/json", "text/plain"],
"defaultOutputModes": ["application/json", "text/plain"],
"skills": [
{
"id": "inventory-optimizer",
"name": "Inventory Level Optimizer",
"description": "Adjusts inventory levels based on demand forecasts, analyzing current stock, lead times, and supplier capacity to prevent stockouts while minimizing excess inventory.",
"tags": ["inventory", "optimization", "forecasting", "supply-chain"],
"examples": [
"Adjust inventory for product WIDGET-A100 based on 15,000 unit Q4 forecast",
"{\"products\": [{\"id\": \"WIDGET-A100\", \"predicted_demand\": 15000, \"confidence\": 0.85}], \"time_period\": \"2024-Q4\"}"
],
}Example: Task Request Payload
Once an agent is discovered, other agents or systems can send it tasks by publishing to its tasks topic.
Topic: agents/global-industries/supply-chain-planner-001/tasks
QoS: 1
Payload:
{
"timestamp": "2024-08-06T10:30:00Z",
"taskId": "task-789-unique",
"operation": "inventory-optimizer",
"params": {
"message": {
"role": "user",
"content": {
"parts": [{
"data": {
"skill": "inventory-optimizer",
"products": [
{
"id": "WIDGET-A100",
"predicted_demand": 15000,
"confidence": 0.85,
"current_inventory": 5000
}
],
"time_period": "2024-Q4"
}
}]
}
}
},
"id": "req-12345"
}Example: Task Result Payload
When the agent completes the task, it publishes the result to its results topic. The payload includes a reference to the original task ID and the output generated.
Topic: agents/global-industries/sales-forecast-002/results
Payload:
{
"timestamp": "2024-08-06T10:30:00Z",
"taskId": "task-789",
"status": "completed",
"result": {
"message": {
"role": "agent",
"content": {
"parts": [{
"data": {
"status": "completed",
"adjustments": [{
"product_id": "WIDGET-A100",
"action": "increase_order",
"quantity": 10000,
"supplier": "ABC Manufacturing",
"delivery_date": "2024-09-15"
}]
}
}]
}
}
},
"id": "req-12345"
}This payload design enables rich, semantically meaningful communication between AI agents over MQTT, while aligning with the broader A2A standard. It ensures discoverability, operational transparency, and task-specific interactions, all while maintaining loose coupling and protocol flexibility.
Conclusion
The proliferation of AI agents presents a defining opportunity for the modern enterprise, but it also stands at a critical juncture. The architectural choices made today will determine whether these intelligent systems evolve into a cohesive, collaborative force or devolve into a brittle and unmanageable collection of isolated silos.
What’s certain is this: The future of enterprise AI will not be defined by the intelligence of individual agents, but by the intelligence of the ecosystem they form. For technology leaders and architects charting this course, the message is clear: the path to a scalable, interoperable, and truly autonomous future is event-driven, and it runs on MQTT.
Download our whitepaper to explore the full details.
Navigate this series:
Kudzai Manditereza
Kudzai is a tech influencer and electronic engineer based in Germany. As a Sr. Industry Solutions Advocate at HiveMQ, he helps developers and architects adopt MQTT, Unified Namespace (UNS), IIoT solutions, and HiveMQ for their IIoT projects. Kudzai runs a popular YouTube channel focused on IIoT and Smart Manufacturing technologies and he has been recognized as one of the Top 100 global influencers talking about Industry 4.0 online.
