Data interoperability: The foundation for AI agents in manufacturing

The factory floor has a communication problem and it is not about bandwidth. Dozens of PLCs, SCADA systems, MES platforms, and ERP layers generate torrents of operational data, but that data arrives in incompatible formats, siloed by vendor, protocol, and organizational boundary. For the IT/OT solutions architect tasked with bridging these worlds, the interoperability challenge is familiar. What is changing is the stakes: the next consumer of this data is not just a dashboard or a historian. It is an AI agent expected to make real-time decisions about production quality, maintenance scheduling, and energy optimization.

Interoperable operational data is data that carries consistent meaning, structure, and context regardless of which system produced it, enabling any authorized consumer (human or machine) to interpret and act on it without custom translation logic.

This article examines why data interoperability is the critical foundation for agentic automation in manufacturing, how standardized semantics and cross-vendor context make autonomous action possible, and what architects should prioritize now to make their environments agent-ready.

Why do AI Agents need interoperable data to function in manufacturing?

AI agents in industrial settings are fundamentally different from the chatbots and workflow automators common in enterprise IT. A manufacturing agent tasked with reducing unplanned downtime on a packaging line needs to correlate vibration data from a Siemens drive, temperature readings from a Rockwell PLC, production counts from an SAP MES, and maintenance history from an IBM Maximo instance. If each of those sources uses a different naming convention, a different unit of measure, and a different data format, the agent cannot reason across them without extensive, brittle custom integration.

This is the core problem: point-to-point integrations that took human engineers weeks to build and maintain are exactly what agents cannot tolerate. Agents need to discover what data exists, understand what it means, and trust that the same term refers to the same thing across every system. Without interoperability, an agent is either blind (it cannot access the data it needs) or confused (it misinterprets what the data means).

Research from Mulesoft’s Connectivity Benchmark Report (an annual survey of 1,050 IT leaders) IT teams spend around 39% of their time designing, building and testing new custom integrations between systems and data rather than value-generating logic. That cost is a human cost today. For agents, it becomes an architectural impossibility. You cannot hand-wire every data mapping an autonomous agent might need before deployment, because the whole point of an agent is that it adapts to situations you did not fully anticipate.

The implication for architects is clear: interoperability is not a nice-to-have that simplifies integration projects. It is the substrate on which any meaningful agentic automation depends.

How do standardized semantics make agent-ready automation possible in manufacturing?

Semantic standardization means that every data point in the operational environment carries not just a value, but a meaning that any consumer can interpret without prior arrangement. This is the difference between receiving a payload of {"t": 74.3} and receiving a self-describing message that identifies the source as a motor bearing temperature sensor on Line 3, Cell 2, measured in degrees Celsius, with a defined normal operating range.

The critical insight for agentic readiness is this: when data is semantically standardized, agents can be general-purpose rather than custom-built for each data source. An agent designed to detect anomalous vibration patterns can operate across any motor in any facility, provided the data follows a consistent semantic model. Without that standardization, you need a separate integration layer (and potentially a separate agent configuration) for every vendor and every site. To learn more about how semantic models capture hierarchical relationships between different Manufacturing elements, read our whitepaper Building Ontology-Driven Intelligence for Industrial AI Agents. 

What does cross-vendor context mean for autonomous decision-making?

Manufacturing environments are inherently multi-vendor. A single production line might include Siemens PLCs communicating via OPC UA, Allen-Bradley controllers on EtherNet/IP, Mitsubishi robots using their proprietary protocol, and edge sensors streaming over Modbus TCP. Each vendor's ecosystem carries its own data model, naming conventions, and communication patterns.

Cross-vendor context means that an agent (or any data consumer) can understand the operational state of the entire line without knowing which vendor built each component. This requires two capabilities:

1. Protocol translation at the edge. HiveMQ Edge translates OPC UA, Modbus, Siemens S7, BACnet, and other industrial protocols into MQTT, normalizing data at the point of ingestion. This eliminates the protocol diversity problem before data reaches the broker.

2. Semantic unification at the platform level. Once data is flowing as MQTT messages, HiveMQ's discovery and cataloging capabilities identify what data exists across the namespace, while the Semantic Graph maps relationships and enforces consistent meaning. The result is a unified operational view that spans vendor boundaries.

Consider a practical scenario: an AI agent monitoring overall equipment effectiveness (OEE) across three production lines, each built by a different system integrator using different PLC vendors. Without cross-vendor context, you need three separate data pipelines, three sets of mapping rules, and three agent configurations. With cross-vendor context provided by a well-architected UNS and semantic layer, the agent sees "Line 1, Station 3, Cycle Time" in the same format and with the same meaning regardless of the underlying hardware. 

For the solutions architect, the design principle is: push heterogeneity to the edges and enforce homogeneity at the core. HiveMQ Edge handles the former; HiveMQ platform handles the latter.

How should architects design for agent-ready automation today?

You do not need to deploy AI agents tomorrow to benefit from making your data environment agent-ready today. The same architectural investments that enable agentic automation also deliver immediate value: reduced integration costs, faster time-to-insight, and more resilient data infrastructure.

Here is a practical prioritization framework for IT/OT solutions architects:

1. Establish MQTT as the operational data backbone. Deploy the HiveMQ Broker as the central nervous system for operational data. MQTT's publish/subscribe, event-driven architecture naturally decouples producers from consumers, which is essential for adding new consumers (including agents) without disrupting existing systems.

2. Normalize protocols at the edge. Deploy HiveMQ Edge at each site to translate legacy and proprietary protocols into MQTT. This eliminates the protocol fragmentation that makes cross-vendor reasoning impossible.

3. Define and enforce a semantic model. Establish consistent naming conventions, unit standards, and topic structures across your UNS. Use the HiveMQ to enforce payload schemas at the broker, catching malformed or ambiguous data before it propagates. This is the step most organizations underinvest in, and it is the step that most determines agent readiness.

4. Build the Semantic Graph. Use HiveMQ to discover, catalog, and model the relationships between your operational entities. This gives future agents (and current analytics tools) the contextual understanding they need to reason about operational state.

5. Design for trusted delegation. As HiveMQ's agentic layer matures, the goal is enabling domain experts (operators, maintenance engineers, process engineers) to delegate tasks to AI agents with confidence. The architectural foundation you build now, with governed, semantically rich, interoperable data, is what makes that trust possible. Agents can only be as reliable as the data they consume.

Each of these steps delivers standalone value. Together, they create a compounding advantage: every deployment teaches your organization (and the platform) what works, making each subsequent step faster and more reliable.

What happens when you skip data interoperability and go straight to AI?

The temptation is real. Vendors promising AI-powered manufacturing optimization are everywhere. But deploying agents on top of fragmented, ungoverned data produces one of two outcomes: either the agents fail silently (making decisions based on incomplete or misinterpreted data) or they fail loudly (triggering false alarms, incorrect adjustments, or safety incidents that destroy organizational trust in automation).

A 2024 Gartner survey found that 65% of industrial AI pilot projects fail to move to production, with data quality and integration cited as the primary barrier in the majority of cases. The pattern is consistent: organizations that skip the interoperability foundation spend more on AI pilots that deliver less.

The organizations that will lead in agentic manufacturing automation are the ones investing in interoperability, semantic standardization, and cross-vendor context today. These investments are not speculative. They pay for themselves in reduced integration costs and faster analytics. And they position the organization to adopt agentic automation when the technology and organizational readiness converge.

The path from interoperable data to agentic automation is not a leap. It is a series of architectural decisions, each delivering value independently, that compound into a foundation capable of supporting autonomous decision-making at industrial scale. The work starts with the data layer, and the best time to start is before you need agents to consume it.

Schedule a consultation with a HiveMQ solutions architect to assess your current interoperability posture and map a path toward agent-ready manufacturing infrastructure.