Natural-language interface to IoT fleets

The challenge

An industrial IoT operator ran a distributed fleet of devices spread across multiple regions. The people responsible for keeping that fleet healthy were field operators, not engineers. When something looked wrong, the only options were to dispatch a technician for an on-site visit or escalate to a small group of specialists who knew the device bus, the telemetry schemas, and the command syntax.

That meant routine questions like “which devices are offline in region X?” and routine actions like “restart gateway Y” carried the cost of a truck roll or a ticket queue. The fleet generated plenty of data; the people closest to the problem just had no way to ask it anything. The client wanted operators to query and control the fleet in plain language, without giving a language model an unguarded path to physical hardware.

What we built

We built a natural-language control plane that sits between the operator’s console and the fleet API. Every request flows through three stages, and there is no route to a device that bypasses the middle one.

Intent parser

Operator input arrives as free text in a console or chat UI. The parser classifies each request as a query or a command and extracts the entities it refers to: region, device, gateway. A read-only question about offline devices and an instruction to restart a gateway are fundamentally different requests, and separating them early is what makes the rest of the pipeline enforceable.

Safety and permission gate

This is the heart of the system, and the reason the client trusted it in production. A language interface to physical devices fails differently from a chatbot: a misparsed sentence is not a wrong answer, it is a wrong action on real hardware. So every command, without exception, passes through a gate that applies five checks.

An RBAC scope check confirms this operator is allowed to touch these devices in this region. A command allowlist means the system can only ever issue operations we explicitly enumerated; the model cannot improvise a new verb, no matter what the parser produces. A blast-radius limit caps how many devices a single instruction can touch, so an ambiguous phrase like “restart the gateways” can never fan out across the whole fleet. Destructive operations require explicit confirmation from the operator before anything executes. And every decision, allowed or denied, lands in an audit log.

When the gate denies a request, it explains why and never executes. The gate is the only path to devices; there is no direct language-to-device route anywhere in the architecture.

Response synthesizer

Approved queries and commands go to the fleet API over the device bus, and raw telemetry and acknowledgements come back. The synthesizer turns that into a plain answer an operator can act on: “3 offline. Restarted.” No dashboards to interpret, no payloads to decode.

How it was delivered

We delivered this as a focused Lakeshore engagement, starting with the read path: queries first, because answering “what is offline?” safely builds trust before any command touches hardware. The command path shipped behind the safety gate from day one; we designed the allowlist and blast-radius rules with the client’s fleet team before wiring the first write operation. The system ran against the client’s existing fleet API and MQTT device bus rather than replacing any infrastructure, and the engagement is now complete with the system in the client’s hands.

What shipped

• A natural-language console for field operators covering fleet queries and device commands
• An intent parser that separates queries from commands and resolves region and device entities
• A safety and permission gate enforcing RBAC scope, a command allowlist, blast-radius limits, confirmation on destructive operations, and a full audit log
• A response synthesizer that turns raw telemetry and acknowledgements into plain-language answers
• Integration with the client’s existing fleet API and MQTT device bus

The result for the client: a 75% reduction in on-site field-support visits, with every command gated and accounted for.