Written By: Ashley Samuels
Last Updated: June 11, 2026 09:19 PM
Connected-device programs rarely live inside one system.
A fleet may start with SIMs, devices, data plans, and a management portal, but the day-to-day work spreads across support queues, operations dashboards, customer systems, monitoring tools, field teams, and reporting workflows.
With the number of connected IoT devices expected to exceed 20 billion in the coming years, the operational complexity of managing those fleets is growing faster than most portal-based workflows can keep up with.
When connectivity data stays locked in a portal, the cost is predictable. Support agents manually look up device status before every ticket. Operations teams run the same report export every week. IT teams investigating an offline device bounce between systems to reconstruct what happened. Field teams wait on answers that should take seconds.
The data exists. The problem is that it does not travel.
For most of the history of IoT connectivity management, the portal was the product. Want to check a device? Log in. Need a report? Export one. Customer calls with an issue? Open a browser tab.
That model worked when connected-device programs were smaller. It works less well when a program spans thousands of devices, multiple teams, and a growing set of operational expectations.
Connectivity management is increasingly an operational layer, one that needs to feed information into the systems where work happens rather than waiting for someone to come looking for it.
The implications are practical. A support team should not have to leave their ticketing system to understand why a device went offline. An operations leader should not manually compile the same fleet report every Monday. An IT team should not need a separate login to see whether a connectivity issue is isolated or part of a broader pattern. An MSP managing multiple accounts should not rebuild the same workflow for each one.
These are not technology problems — they are operational design problems. And the tools to address them, like APIs, automation, and governed AI-assisted workflows, are now practical enough to use.
APIs, or application programming interfaces, are the connections that let different software systems securely share and use data in real time. Serving as the foundation for connectivity management systems, they allow device status, SIM information, usage data, account details, and policy settings to move into the systems where teams already work — not as a one-time export, but as live structured data other systems can use.
Consider a support team handling a ticket about a field device that stopped reporting. Traditionally, a support engineer opens a portal, searches for the device, checks recent activity, reviews usage, and manually summarizes findings back into the ticket. Ten minutes, repeated dozens of times a day.
With an API-connected workflow, that context surfaces automatically. Before the ticket reaches an agent, the workflow has already retrieved information on device status, recent usage, and whether other devices on the same account show similar behavior. The agent opens the ticket with a note already attached: "This device was online yesterday, shows no unusual data spike, and two other devices on the same account are behaving similarly. Recommend checking site-level network conditions before replacing hardware." The agent still decides. They just do not have to earn the context from scratch every time.
The same principle applies broadly. An operations leader does not need to pull a manual export if the workflow already knows which devices are offline and where exceptions are increasing. An IT team does not need portal access for every query if the data is available through an API their existing tools can call. An MSP can run the same workflow across every customer environment rather than recreating it each time.
APIs make connectivity data accessible. AI-assisted workflows make it easier to act on.
Access and usability are not the same thing. While a developer can pull raw device and usage data through an API, turning that data into an operational summary, identifying the exceptions that matter, or preparing a briefing for a non-technical stakeholder still takes time.
AI agents can help close that gap when they have structured, governed access to trusted data. That last part matters. AI tools operating on vague context or stale exports are not operationally useful. They need live, structured access to real systems. That is where Model Context Protocol becomes relevant.
MCP is an open standard that gives AI tools a consistent way to connect with approved data sources. Rather than building a custom integration for every AI tool, teams define what resources are available, and how approved workflows can use them. AI tools can then interact with connectivity data in a controlled, auditable way, pulling out what they need, staying within defined permissions, and surfacing findings for human review.
In practice:
A support engineer asks an AI tool to investigate directly: "check the status of this device, summarize its recent connectivity activity, and tell me whether this looks like a device, usage, or account-level issue." The workflow returns a summary with the suggested next steps. The first round of investigation takes seconds instead of ten minutes.
Instead of compiling a weekly briefing manually, a governed AI workflow collects the relevant data, identifies notable changes, and prepares a draft for the operations manager to review. The review becomes a five-minute edit rather than a forty-minute exercise.
Before a support ticket reaches an agent, an AI workflow retrieves device status, recent usage, and relevant signals from similar devices. The agent opens the ticket with a plain-language summary already attached. A developer can also use an AI coding tool to generate a starter automation: check for devices with no recent activity, flag devices above expected usage, and output a summary for operations review. The developer reviews and hardens the output. The gap between "we should automate this" and "we have a working first version" shrinks considerably.
In each case, the human remains responsible for review and action. The AI handles retrieval, summarization, and preparation. That division is what makes these workflows trustworthy enough for production environments.
This shift is not about replacing the people who manage connected-device programs. It is about changing what they spend their time on.
Support teams that spend less time reconstructing device context can spend more time solving problems. Operations leaders with automated fleet summaries make faster decisions. IT teams with live connectivity data inside existing tools respond without context-switching. MSPs with standardized workflows scale without proportionally scaling headcount.
The teams moving in this direction are not necessarily the largest or most technically sophisticated. They are the ones who have identified where connectivity data needs to be that it currently is not, and started closing that gap.
The most useful question is not "how do we adopt AI for IoT?" — it is simpler:
Where does your team need connectivity data today, but cannot get it without a manual step?
That answer, whether it is a support workflow, a dashboard, a monitoring process, or a recurring report, is the right place to start. The path typically moves from API integration to automation to governed AI-assisted workflows, each step building on the last.
Kajeet SentinelOS supports that progression. Built on the Sentinel IoT management platform, SentinelOS gives technical teams access to Sentinel capabilities through APIs, MCP resources, command-line tools, and developer documentation at kajeet.dev, including a Trial SIM Kit for teams that want to evaluate connectivity under real-world conditions.
.png)
