The core of Agentic IoT is not to let large models connect directly to industrial protocols. It is to separate multi-agent collaboration, tool invocation, asset resolution, field execution, and state readback into independent responsibility layers. This guide defines the correct boundaries for A2A, MCP, OPC UA, and Modbus to solve protocol-layer mixing, overreach, and false closed-loop behavior in industrial control paths. Keywords: A2A, MCP, OPC UA.
Technical Specification Snapshot
| Parameter | Description |
|---|---|
| Domain | Agentic IoT / Industrial Control Plane |
| Primary Languages | Protocol-agnostic, commonly implemented in Python, Go, and Java |
| Key Protocols | A2A, MCP, OPC UA, Modbus TCP/RTU |
| Control Model | Multi-agent collaboration + command service closed loop |
| GitHub Stars | Not provided in the source |
| Core Dependencies | Agent framework, MCP Server, OPC UA Server/Client, Modbus adapter |
Agentic IoT control planes must start with protocol layering
Many teams discuss A2A, MCP, OPC UA, and Modbus as if they were interchangeable components. That assumption is incorrect. They solve collaboration, invocation, semantic modeling, and device execution respectively, so they do not compete at the same architectural layer.
Once you compress multi-agent collaboration, register writes, device identity, and command acknowledgments into the same layer, the system starts to produce duplicate dispatches, incorrect asset control, and false closed-loop signals. The real problem in industrial systems is not whether the AI is smart. It is whether the responsibility boundaries are auditable.
Layering mistakes directly amplify physical risk
In HVAC, PLC, or variable-frequency drive scenarios, a faulty control path can still look like reasonable automation. For example, an analysis agent may overstep its authority and issue control commands, or a platform may mistake a broker ACK for confirmed device execution. Both are classic consequences of incorrect layering.
User goal -> Agent collaboration -> Tool invocation -> Asset resolution -> Field execution -> State readbackThe key to this chain is not that it is longer. The key is that every hop can be independently authorized, traced, and rolled back.
The four protocol categories carry different responsibilities
A2A handles task collaboration between agents
A2A focuses on deciding who should handle a task, not who should write a register. It is well suited for task decomposition, context transfer, approval escalation, and human handoff.
When the system includes a planning agent, execution agent, and audit agent, A2A can define task ownership clearly and prevent multiple agents from issuing duplicate actions to the same device.
# A2A only handles task routing and does not touch devices directly
task = {
"goal": "Set the temperature of Unit 3 to 24°C",
"owner": "planner_agent",
"next": "executor_agent"
}
# Escalate to the approval agent based on task risk
if task["goal"].startswith("Set"):
task["next"] = "approval_agent"This example shows that the A2A layer should focus on task flow rather than industrial protocol details.
MCP should be the only entry point for agent access to platform capabilities
MCP is suitable for exposing structured tools, not for directly exposing Modbus write operations or OPC UA node writes. Agents should see platform capabilities rather than field protocol primitives.
Recommended interfaces include: resolve_asset, request_action, get_command_status, and request_human_approval. This naturally constrains natural-language intent into auditable requests.
{
"tool": "request_action",
"asset_id": "ahu-zone-3",
"action": "set_temperature",
"parameters": {
"target_celsius": 24
}
}This structured request shows that MCP adds value by standardizing action formats and enforcing permission boundaries.
OPC UA or a unified asset layer should express control targets consistently
The biggest fear in industrial systems is that the name looks right while the actual device is wrong. The practical value of OPC UA is that it uses nodes, hierarchies, attributes, and quality bits to abstract device objects into a stable asset view.
It ensures that “Conference Room Air Conditioner Unit 3” is no longer just a drifting alias. It becomes a resolvable combination of asset identity, capability model, and state semantics. Even if the underlying systems are not all based on OPC UA, this unified asset semantic layer must still exist.
Modbus should remain only at the final execution layer
Modbus is strong at register read/write operations and field compatibility. It is not a high-level control interface designed for agents. It fits the final execution hop for PLCs, meters, chillers, and controllers.
If you expose register addresses directly to a model, vendor differences, interlock conditions, and permission governance all leak upward into the application layer. That eventually breaks auditability.
A deployable layered path should include a command service
The following is a more reliable control path:
AI Visual Insight: This diagram shows a top-down Agentic IoT control path. It highlights A2A at the multi-agent collaboration entry point and MCP as the tool invocation boundary. In the middle, a command service and policy engine carry approvals, policy enforcement, and state-machine management. OPC UA or a unified asset layer then resolves device identity, and field protocols such as Modbus finally reach the physical device. Together, they form a four-part architecture of collaboration, governance, semantics, and execution.
The point of this path is not the number of protocols. The point is that each layer performs only its own responsibility: A2A drives collaboration, MCP constrains tools, the command service manages lifecycle, the asset layer defines object semantics, and Modbus executes actions.
The command service is the core hub of closed-loop governance
Without a command service, the system can only prove that a call succeeded. It cannot prove that the action took effect. A production-grade control system should include at least command_id, trace_id, asset_id, policy_decision, timeout_window, and current_state.
A recommended minimal state machine looks like this:
Created -> Approved -> Resolved -> Dispatched -> DeviceAcked -> Applied
Rejected / TimedOut / Failed / Cancelled / RolledBackThe purpose of this state machine is to unify approval, dispatch, acknowledgment, rollback, and audit into one traceable path.
Looking only at broker ACKs creates a false closed loop
The most dangerous misjudgment in industrial environments is treating “the message reached the gateway” as “the device has executed the action.” In reality, asset mapping, interlock validation, register writing, state transition, and local logic override can all fail at different stages.
AI Visual Insight: This diagram emphasizes that a control action must pass through three stages: dispatch, device acknowledgment, and state readback. It specifically highlights the semantic gap between a broker ACK and the real device Applied state, showing that an industrial control system cannot form a trustworthy closed loop without readback verification.
Therefore, the definition of “complete” in industrial control must be based on state readback, not on successful tool invocation. Without readback confirmation, the platform is fundamentally just a message forwarding system.
# Only mark the command as complete when the readback matches the target value
if device_ack and readback.temperature == 24:
command_state = "Applied"
else:
command_state = "Failed"This logic shows that a device ACK is only an intermediate state. Applied must be confirmed by readback facts.
System hardening should follow the current risk layer
If multiple agents repeatedly override the same action, strengthen A2A first. If agent action formats drift or overreach permissions, strengthen MCP first. If cross-site deployments often miscontrol devices because of alias confusion, strengthen OPC UA or the asset layer first. If device protocols are highly fragmented, then strengthen the Modbus adaptation layer.
Many teams default to “adding one more protocol,” but the real high-priority component is often the command service. Whether the system can prove that an action ultimately took effect determines whether it is a true control plane or just a demo pipeline.
Delegation should evolve from advisory systems to closed-loop control
A more realistic rollout path is to open state reads and anomaly explanations first, then allow low-risk parameter adjustments, then introduce approvals and time windows, and only after that consider higher-level action automation.
This progressive delegation model turns growth in model capability into growth in governance capability and prevents teams from mistaking a successful PoC for production readiness.
The conclusion is that these four layers form a responsibility chain, not a substitution set
The real value of A2A, MCP, OPC UA, and Modbus is not which one is more advanced. It is whether each one sits in the correct place. A deployable Agentic IoT control plane should follow this model: A2A manages collaboration, MCP manages tools, the asset layer manages objects, Modbus manages execution, and the command service governs the closed loop.
When a system must handle multiple agents, cross-site assets, heterogeneous device protocols, and high-risk actions at the same time, A2A -> MCP -> Command Service / OPC UA -> Modbus is not unnecessary complexity. It is the most practical architecture for auditability, rollback, and gradual delegation.
FAQ
FAQ 1: What is the biggest difference between A2A and MCP in industrial scenarios?
A2A solves how multiple agents divide work, hand off tasks, and escalate execution. MCP solves how agents access platform tools in a controlled way. The former is about agent collaboration, while the latter is about the boundary of tool invocation.
FAQ 2: Why can OPC UA not be treated as equivalent to Modbus?
Because OPC UA focuses on unified object semantics, hierarchy, and state representation, which makes it suitable for asset modeling. Modbus focuses on register access, which makes it suitable for field execution. One solves “who the object is,” and the other solves “how to write to it at the final step.”
FAQ 3: What must a minimum viable command service include?
At minimum, it should provide a unique command identifier, a state machine, approval results, timeout control, device ACK handling, and state readback. Without these capabilities, the system can only prove that the request was sent, not that the action took effect.
Core Summary
This article reconstructs the core architecture of an Agentic IoT control plane. It clarifies that A2A, MCP, OPC UA, and Modbus map to the collaboration layer, tool layer, asset semantic layer, and field execution layer respectively, and explains why the command service and state readback are essential to closed-loop control for industrial agents.