Connect MQTT to Copilot
You're building a Copilot agent that should answer questions about live equipment — and your sensors, PLCs, and edge devices publish data over MQTT. MQTT is the messaging protocol of choice across modern OT environments: lightweight, reliable, and ubiquitous. But it's a push-based pub/sub protocol with no query interface and no history store. Copilot Studio agents work by pulling data over HTTP when a user asks a question — a fundamentally different model. Bridging the two requires solving problems that neither Copilot documentation nor MQTT documentation addresses directly.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting a Copilot agent to MQTT data is harder than expected.
Copilot agents pull HTTP — MQTT is a push-based pub/sub protocol with no REST interface
Copilot Studio agents retrieve data by making HTTP calls through Custom Connectors. MQTT is a publish/subscribe messaging protocol — devices push payloads to a broker, and consumers subscribe to topics. There is no HTTP endpoint to call, no query mechanism, and no way to ask the broker for a current value on demand. Bridging MQTT to a Copilot agent requires an intermediary that subscribes to MQTT topics, caches current values, and exposes them over HTTP for the agent to poll.
MQTT brokers sit on OT networks — Microsoft's cloud can't subscribe to them
Industrial MQTT brokers run on OT or plant floor networks, isolated from the internet. Microsoft's Power Platform makes outbound HTTP calls from cloud infrastructure — it can't subscribe to a broker on a restricted OT network, and it doesn't speak MQTT. Even if the broker were internet-accessible, subscribing to it from Microsoft's cloud would require persistent connections that Custom Connectors don't maintain.
MQTT has no history store — the agent can't answer questions about the past
MQTT brokers deliver messages in real time and retain only the last published value per topic (if retain is enabled). There is no built-in historian. If a user asks the Copilot agent what a sensor read two hours ago, or how a value trended through a shift, MQTT has no answer. The agent would need a separate storage layer that accumulates MQTT payloads over time — which has to be built and maintained.
MQTT payloads are raw encoded data — the agent receives binary or unstructured JSON
MQTT payloads are application-defined. In industrial environments they're often compact JSON objects, Sparkplug B encoded messages, or raw binary. Topic names follow device-specific hierarchies — plant/line1/motor1/speed — that are meaningful inside the OT environment but opaque to an agent. Without payload parsing and topic-to-description mapping, the agent receives data it can't interpret or present to a user.
Exposing the broker to the internet is a security risk most OT teams won't accept
Even if you could get Microsoft's cloud to subscribe to an MQTT broker, opening the broker to inbound internet connections — or tunnelling it through a VPN — puts OT infrastructure in contact with external networks. MQTT brokers connected to sensors and controllers are part of production infrastructure. Any internet-facing path to them increases the attack surface in ways most OT security policies prohibit.
Topic hierarchies are device-specific — the agent doesn't know what any topic means
Topic naming in industrial MQTT deployments varies by device type, vendor, and site convention. A topic path like factory/area2/press3/outputs/torque tells an operator exactly what it is — but presented raw in an action response, the agent has no context for which equipment it refers to, what units the value is in, or what a normal range looks like. A semantic mapping layer is required to make raw MQTT data useful in agent responses.
Power Platform Custom Connectors require admin approval
Any Copilot Studio agent accessing external data needs a Custom Connector with an approved OpenAPI spec. In enterprise Microsoft 365 environments, connectors that touch OT-adjacent endpoints go through Power Platform admin review, security assessment, and sometimes change management. The approval timeline regularly runs to weeks before a connector reaches production use.
What teams usually try
MQTT subscriber service that caches values and exposes a REST API
Build a service that subscribes to the broker, parses payloads, caches the latest value per topic, and exposes an HTTP endpoint the Custom Connector can call. Deploy it on a machine with broker access and an internet-facing path.
The catch: The service needs an internet-accessible path for Microsoft's cloud to call it — a security change on the OT network. It has to handle payload parsing, topic mapping, and cache management. Historical queries still aren't possible. The service adds ongoing infrastructure overhead.
Cloud MQTT broker with bridge from OT broker
Bridge the on-premise MQTT broker to a cloud MQTT broker (AWS IoT, Azure IoT Hub, HiveMQ Cloud). Build a cloud-side subscriber that exposes HTTP. The Custom Connector calls the cloud service — no plant floor network path from Microsoft's side.
The catch: Bridging requires an outbound MQTT connection from the OT network — a network change that still needs OT approval. The cloud broker adds licensing cost. Payload parsing and topic semantics still have to be handled. Historical query capability still doesn't exist unless you also add a time-series store.
Export MQTT data to SharePoint or files
Log MQTT data to files periodically and upload to SharePoint. Configure the Copilot agent to read these files as its knowledge source for equipment questions.
The catch: High-frequency MQTT data produces very large log files. The agent answers questions about past snapshots — not current equipment state. SharePoint-based file search handles high-frequency numerical logs poorly for operational queries. Real-time monitoring use cases are entirely unsupported.
How TrendOps solves it
TrendOps Edge runs on-premise alongside your MQTT broker — subscribing to topics, parsing payloads, mapping topic hierarchies to named data points, and accumulating history — then forwards structured data to TrendOps Platform in the cloud over its own outbound MQTT connection. Your Copilot Studio agent calls TrendOps Web API through a single Custom Connector. No broker exposed to the internet, no cloud-side MQTT subscription, no raw payload parsing in the action layer.
The agent calls TrendOps Web API — a cloud-accessible HTTPS endpoint. No MQTT subscription from Microsoft's cloud, no broker port open to the internet, no inbound path to OT network infrastructure.
TrendOps Edge decodes MQTT payloads and maps topic paths to human-readable data point descriptions. Action responses include labelled values and context — not raw topic paths and binary payloads the agent can't interpret.
TrendOps accumulates MQTT data over time. The agent can answer time-range questions — what a sensor read over the last shift, how a value trended — not just the last published value on a retained topic.
TrendOps Edge maintains continuous MQTT subscriptions. The agent returns the most recently published values for any topic — not stale data from a periodic export or file snapshot.
TrendOps Edge forwards data out over its own outbound MQTT connection to TrendOps Platform. No inbound path from Microsoft's cloud to the OT broker. The Copilot agent's calls never reach the plant floor network.
TrendOps normalises MQTT data alongside AVEVA PI, FactoryTalk, DeltaV, and SQL sources. One connector gives the agent a unified view across real-time and historian data sources.
What you end up with
OT MQTT broker stays closed — the agent never connects to it directly.
Current values and historical trends — not just the last retained message.
Payloads decoded, topics mapped — the agent receives readable, labelled data.
One connector, every OT source — MQTT alongside historian and SQL data.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your MQTT-connected equipment in plain language and get answers instantly, deployed directly in Microsoft Teams. No Custom Connector to configure, no payload parsing to build, no Power Platform admin approval to wait for.
Learn about TrendGuru →Your Copilot agent shouldn't need to subscribe to an OT broker to answer a question about equipment data
TrendOps gives your Copilot agent a clean, cloud-accessible API for MQTT data — decoded, mapped, and queryable — without exposing the broker to the internet.
Book a Demo