Connected products produce a constant stream of telemetry, events, and alarms, but the value is in the decision underneath each one: which alarm signals a real failure, which customer is heading toward a problem, why a machine stopped, and what action will resolve it. AI and IoT integration is the work that connects the two, moving device data to a trusted decision and a decision to action.
Most businesses already have the necessary data and infrastructure. Years of investment have gone into collecting telemetry and gaining visibility into their fleets, and many have layered analytics and machine learning on top to try to identify problems and notify users. What is still missing is the “last mile“: the layer that scales expert judgment across the fleet. The expertise a subject matter expert applies to a noisy alarm is itself a workflow, and an AI agent can run that same workflow across every asset. This post walks through how that integration actually works: the data an agent needs, how to prepare it, where the analytics run, and how the resulting decisions get written back into the ERP, CRM, and field-service systems where work happens.
The data sources an agent needs
An AI agent is only as good as the evidence it can reach, and two kinds of data matter. The first is the underlying IoT data itself: telemetry history, device events, and alarm patterns. The second is the operational context that surrounds the device, the breadcrumbs a good technician or account manager already relies on, including installation metadata, service records, work orders, prior repairs, and notes from customers and technicians. This context usually lives in CRM, ERP, and field-service systems rather than the telemetry database, and an agent that sees how a device is behaving but not how it was installed or last serviced hits the same dead ends a person would. So the first integration question is about evidence rather than hosting: what do your SMEs use to make this decision, and where does that data live today?
Curate the data before the agent reasons over it
Access alone is not enough. Agents do not reason reliably when you hand them every raw telemetry reading and every operational record and expect them to sort it out. The data has to be curated and contextualized into a focused evidence package first: reduce the noise, compute the meaningful signals, slice the relevant time windows, compare recent behavior against the asset’s own baseline, and attach the operational records that ground it. The agent then weighs prepared evidence and returns a constrained, structured result such as a classification, a confidence score, and a recommended action.
Where that curation happens is flexible, and this is where the replatforming worry usually dissolves. The transformation can run inside the systems that already hold the data, in a batch pipeline on top of them, or in the same compute environment as the agent, such as a Python container that queries the source systems, shapes the evidence, and hands it to the model. None of these options require a new IoT platform. They require access to the data and a clear definition of the evidence a decision needs.
Background agents with batch processing
The agents we have seen succeed most often are background agents, triggered by an event or run on a periodic sweep of the fleet rather than waiting on a prompt. That design fits the nature of connected-product decisions, because most depend on historical telemetry and carry no real-time requirement. Interpreting equipment degradation, temperature anomalies, or battery wear can take weeks or months of behavior, since a single datapoint or a fixed threshold produces too many false positives and false negatives.
Most of this value is delivered today through human-in-the-loop workflows, where an expert eventually gets to the data, so a background agent is already far faster than the status quo. The bottleneck was never latency on an individual device; it is scaling analysis and decision-making across an entire fleet. Batch processing fits this perfectly, which is one more reason replatforming is often unnecessary. You can query the systems you already run, process the data on the fly, combine it with context such as prompts and supporting documentation, and let the agent automate the decision.
Operationalizing insights into business processes
An insight only creates value when it lands where the work happens, and another dashboard to monitor adds analysis without removing the bottleneck. Operationalized integration closes that gap by writing decisions directly into operational systems: a high-confidence decision creates a service ticket in a field-service tool, a low-confidence case reaches an expert with the evidence already assembled, and a probable false alarm is suppressed before it reaches a customer. The same engine can power different agent roles, from early-warning agents that catch degradation before downtime to service-resolution agents that turn an alert into a recommended fix, dispatch, or part.
A practical picture
Alarm triage shows the pattern clearly. Many monitoring solutions rely on rule-based engines that fire alarms from low-cost sensors. Those engines make good triggers, but they produce a high share of alarms that need expert review because the signals are noisy and depend on real-world context. An agent can take each alarm as a trigger, retrieve a long window of historical telemetry, compare current behavior to the asset’s own baseline, check the operational context, and notify a technician with the likely cause.
Integration is the value layer
AI and IoT integration is the movement from telemetry to evidence, from evidence to a trusted decision, and from decision to action. The best place to start is a valuable workflow where the data you already have is good enough for an expert to reach a high-quality conclusion, not a platform migration. If that is true, you are closer to useful AI agents than you may think. Define the outcome, the decision, and the evidence required, then fill only the gaps that block it. Once that workflow is benchmarked and operationalized, background agents can reduce expert bottlenecks, cut false alarms, improve service resolution, and make connected-product investments visible in business outcomes.
Where To Start
You do not need a new platform to find out if this works for your fleet. You need one workflow, one decision, and a way to prove the agent gets it right before it touches a customer.
That is exactly how Mesh Systems approaches it with manufacturers today. We start with a single high value use case, often alarm triage or service resolution, and benchmark the agent against your own experts before it goes live. Once that decision is proven, expanding to the next workflow is fast, because the evidence pipeline and the trust are already built.
If you are sitting on years of telemetry and a backlog of alarms nobody has time to chase down, let’s talk about what a benchmarked pilot looks like for your fleet.
This post was authored by Kurt Neuens, VP of AI Solutions at Mesh Systems.