The Virtual Service Technician as an Edge Agent

It’s 02:40 in the morning. A plant reports a drop in rotational speed, throughput collapses, and the only person on the floor is an operator who runs the machine but didn’t build it. The nearest service technician is hours away, the phone hotline window is closed, and a ticket means, at best, a reply tomorrow morning. Until then the line is stopped, or it runs on a hunch. This is exactly where a virtual service technician comes in. An agent on the machine that mediates between plant and operator, local, immediate, with no one having to open a ticket first.

The knowledge exists, just not on site

The experiential knowledge about a machine exists, in manuals, wiring diagrams, in the heads of seasoned technicians, and in years of sensor data. It is just rarely where it’s needed at half past two in the morning. Sites with few machines don’t keep a dedicated maintenance engineer on hand. Night and weekend shifts run thin. And every escalation costs, in waiting time, travel, and a technician appointment for something that may have been a loose connector.

An Edge Agent moves the first step of diagnosis to where the machine stands. It doesn’t replace the human. It gives the operator on site the knowledge that would otherwise only arrive via an escalation chain. Augmentation, not replacement, and the decision stays with the operator.

Detect the anomaly first with classical ML

The agent doesn’t have to invoke a language model for every fluctuation. The first stage is classical pattern detection directly on the sensor data, with thresholds and hysteresis, trend monitoring, and anomaly detection on vibration, temperature, current, and rotational speed. This runs deterministically and frugally on the device and reliably decides that something deviates from the normal picture.

This intelligence cascade is deliberately staged. Rules first, then classical ML, then an on-device AI language model, and only as the exception a large cloud model. The point is frugality, and the most expensive stage is drawn only when the cheaper one isn’t enough. For the vast majority of industrial diagnostic tasks, a small, locally running model suffices.

Explain it clearly with a local SLM

Detecting is one thing, interpreting another. Once the anomaly stands, a local small language model (1 to 3B parameters) takes over, running next to the engine via a local, OpenAI-compatible inference server. Its job is not to be creative but to put the measurement situation into words an operator understands at half past two in the morning. What is deviating, which plausible causes are in play, and which step comes next.

The decisive part is grounding. The model doesn’t hallucinate instructions. It backs every statement with a knowledge base of manuals, wiring diagrams, earlier sensor traces, and documented experiential knowledge. Through semantic search (vector search), the agent pulls in the relevant passages and turns them into step-by-step guidance. Where a knowledge-heavy task demands a larger model, a cloud LLM can optionally be brought in, the exception and not the norm.

What matters stays local

The logic that counts runs on the device and keeps working even when the connection drops. Anomaly detection, the local SLM, and the operator guidance need no network. Only the optional building blocks reach outward, namely a cloud model for knowledge-heavy tasks and web research. This separation is intentional, and the virtual service technician is available at night and on weekends precisely when connectivity is thinnest.

Security here doesn’t come from a permission layer but from the architecture itself, namely local execution, container isolation, and a graph-first flow in which the graph is the program and the AI model is just one node within it. Every step is inspectable and bounded, not an agent switching freely across the system, but a clearly defined flow.

A scenario from a thinly staffed night shift

An operator runs a line alone at night at a small site. A pump shows a slightly elevated vibration pattern, throughput drops. Instead of waiting or stopping the line on a hunch, the operator sees a message from the Edge Agent on the terminal. The anomaly is named, with the conspicuous readings, followed by a short, grounded explanation and three check steps derived from the manual and from similar earlier traces. The operator works through the steps, identifies a partially clogged feed line, fixes it, and documents the case. No ticket, no travel, no standstill until morning. If the steps don’t work, the operator escalates, but now with a prepared finding instead of an empty call.

How it works at the edge

Technically this is a directed flow graph on a single binary that runs on the existing hardware on site, from a small embedded board to an industrial computer, the same binary, with no reimplementation.

1. Trigger. A threshold trigger with deadband or an incoming MQTT message starts the flow as soon as the sensors deviate from the normal picture, with no cloud loop, since the trigger sits on the device.
2. Classification. Classical ML nodes assess the pattern and decide whether it’s a real anomaly or noise.
3. Grounding via the knowledge base. A retrieval node uses semantic search to pull in the relevant manual and wiring-diagram passages plus similar earlier traces.
4. Explanation by the local SLM. The on-device model condenses the measurement situation plus the retrieved knowledge into step-by-step, operator-friendly guidance.
5. Output and log. The guidance appears on the terminal, and the case is written to durable on-device memory.

The entire critical path, from trigger and classification through the SLM explanation to the operator guidance, runs offline on the device. The cloud is the optional exception, not the prerequisite.

Key Takeaways

• A virtual service technician as an Edge Agent moves the first diagnostic step onto the machine, valuable especially at night, on weekends, and at sites with few machines.
• The intelligence cascade saves deliberately. Classical ML detects the anomaly, a local SLM explains it step by step, and a cloud LLM joins only for knowledge-intensive exceptions.
• Every statement is grounded via semantic search on a knowledge base of manuals, wiring diagrams, and experiential knowledge, with no invented instructions.
• The critical path stays local and offline-capable, and security follows from local execution, container isolation, and the graph-first, inspectable flow.
• Augmentation, not replacement. Decision authority stays with the operator, and the agent provides the knowledge, not the judgment.