Most industrial AI systems on the factory floor are limited to monitoring: they read sensor data, populate dashboards, and trigger alerts without ever sending an instruction back to the machine. Coreflux, a company based in Porto, Portugal, co-founded by CEO Hugo Vaz and CTO Paulo Mota, has embedded an AI agent directly inside its MQTT broker, giving it the ability to read machine data, generate prescriptive responses from equipment documentation, and write changes back to the devices themselves.
1. Why Is Factory AI Still Read-Only?
Factory AI remains read-only because the intelligence sits outside the control loop, analyzing trends and surfacing patterns while leaving the interpretation, documentation lookup, and manual correction to human operators.
The limitation starts with how alarms work today. An integrator looks at the signal that triggers an alarm, defines the text that needs to be displayed, and that message stays the same regardless of what is actually happening on the line. Whether the issue is a minor calibration drift or a critical fault, the operator sees the same pre-written message every time.
AI tools can analyze trends, predict failures, and surface patterns in production data, but when it comes time to act, a human still has to interpret the alert, look up the documentation, figure out the right response, and manually make the change on the machine.
2. What Does an AI Agent Inside the Broker Do Differently?
The MQTT broker sits at the centre of the Coreflux platform, connected directly to the factory systems it integrates. The broker is what reads from and writes to equipment. Alongside it, Coreflux runs an MCP server that any AI agent can connect to, giving the agent precise, expert-level knowledge of how the Coreflux ecosystem works and a set of tools for acting on it. The agent uses the MCP server to understand and configure the platform; the broker carries the actual machine traffic.
The MCP server exposes the platform’s architecture, the LoT framework, and the connector library as both context and callable tools. The agent can query the connector catalog, generate a LoT rule from a natural-language description, or wire up a new integration without the user touching configuration files. That same knowledge lets it pull information from machines through the broker, cross-reference it with equipment documentation, and generate responses specific to the situation at hand. When an alarm triggers, it reads the context, consults the relevant documentation, and tells the operator what is happening and what to change, rather than displaying the same static message an integrator wrote months ago.
The approach mirrors what tools like Cursor and Lovable brought to software development, where a developer describes an outcome and the AI writes the code. On the factory floor, an engineer or plant manager describes a capability they need and the agent builds the industrial IoT integration.
3. How Do New Capabilities Get Added Without Engineering Projects?
A plant manager or executive describes what they need in plain language, and the AI agent builds the data route and connects the devices.
In a traditional setup, requesting a new report or a new data cross-check means scoping a project with the engineering team and waiting weeks for deployment. With an AI agent inside the broker, a COO can ask directly: cross-check production data every day, generate a new report, flag when a specific condition is met. The agent defines the route and connects the devices using the Coreflux LoT (Language of Things) framework, provided the infrastructure is already in place, turning a request that used to require weeks of engineering work into something the system can build on the spot.
The result is a system that morphs and evolves daily rather than sitting static after deployment. Engineers shift from spending their time on the mechanics of building integrations to thinking strategically about which capabilities the manufacturing floor needs next.
“They can start thinking in a more strategic way. They can now think more about why and not how,” said Hugo Vaz, CEO of Coreflux.
4. What Keeps the AI Agent in Check?
The AI agent operates within defined rules and scope boundaries, with human oversight controlling what the system can and cannot change.
The system needs rules to operate, and those rules are set by the organization. A product owner controls the scope of what the agent can access and modify, and cost considerations determine how far it extends. Adding a new capability requires deliberate authorization rather than the AI deciding on its own what to change, keeping the system’s power proportional to the trust the organization has built in it over time.
Traditional Factory AI vs. AI Agent Inside the Broker
| Dimension | Traditional Factory AI | AI Agent Inside the Broker |
| Data access | Read-only monitoring | Read and write to devices |
| Alarms | Static text defined by integrator | Prescriptive, generated from documentation |
| New capabilities | Engineering project, weeks to deploy | Described in plain language, built by the agent |
| Engineer focus | How to build integrations | Why to build them |
| System evolution | Static after deployment | Morphs and evolves daily |
This article is based on an interview with Hugo Vaz, CEO of Coreflux, and Lucian Fogoros of IIoT World, recorded as part of the CxO Series. AI tools were used to help summarize and organize the content. Reviewed and edited by the IIoT World editorial team.
Sponsored by Coreflux.
Frequently Asked Questions
1. What is an MCP server in the context of factory automation?
An MCP server is a protocol interface that allows AI models to interact with external tools and systems. In Coreflux’s architecture, the MCP server runs inside the MQTT broker, giving the AI agent direct access to factory equipment for both reading data and writing changes back to devices.
2. How do prescriptive alarms differ from traditional factory alarms?
Traditional alarms display a fixed message written by a systems integrator, regardless of the specific conditions that triggered them. Prescriptive alarms are generated in real time by an AI agent that cross-references the alarm signal with equipment documentation to produce a diagnosis and a recommended action for the operator.
3. Can non-technical staff request new factory AI capabilities?
With an AI agent inside the MQTT broker, a plant manager or executive can describe what they need, such as a daily cross-reference of production and quality data, and the agent builds the required data routes and device connections, provided the physical infrastructure is already in place.
4. What guardrails prevent the AI from making unauthorized changes?
The AI agent operates within a rules framework defined by the organization. A product owner controls the scope of what the agent can access and modify, and cost boundaries determine how far the system extends, ensuring that every new capability requires deliberate human authorization.
5. How is AI being used in manufacturing operations?
AI agents embedded inside industrial MQTT brokers can read machine data, cross-reference equipment documentation, generate prescriptive alarms, and write changes back to devices on the factory floor. This shifts engineers from building integrations manually to describing capabilities in plain language while the agent handles the data routing and device connections.
6. What is an AI agent in industrial automation?
An AI agent in industrial automation is software that interacts directly with factory equipment through protocols like MQTT, reading sensor data, interpreting it against equipment documentation, and executing actions such as generating prescriptive alarms or modifying device parameters, with human-defined rules controlling the scope of what the agent can change.