From Edge AI to Agentic AI reasoning

Arduino®️ VENTUNO™ Q

QWEN3 AI model

Mosquitto MQTT broker

Edge Impulse Studio

<html><body>This is part 2 of the three industrial reference design chapters. <a href="https://projecthub.arduino.cc/marc-edgeimpulse/from-industrial-edge-ai-to-the-unified-namespace-10566b">Read the first part here </a>on Arduino Project Hub. This project builds: <ol><li>The initial project delivered continuous vibration acquisition, Edge Impulse anomaly detection, and publication of raw data, anomaly score, and health verdict into an ISA-95-aligned Unified Namespace. </li><li>This project adds a single local agentic AI that subscribes to those UNS topics, reasons over the anomaly context with an on-device LLM, and decides repair versus false alarm. The decision and the agent’s reasoning traces are published back into the same namespace. It uses the Arduino App Lab LLM brick. </li><li>Project 3 later will introduce multiple specialized agents coordinating over Agent-to-Agent (A2A). You can stop at Project 2 and still have a self-contained edge node that both detects and intelligently triages its own faults. </li></ol><h3>Introduction</h3>In 2026, detecting an anomaly is much needed but for Industry 5.0 is no longer enough. A vibration score that rises above a threshold still leaves a human (or a remote system) to interpret context, decide whether the machine needs attention, and start the response. The <a href="https://projecthub.arduino.cc/marc-edgeimpulse/from-industrial-edge-ai-to-the-unified-namespace-10566b">initial project from EdgeAI to UNS</a> closed the first half of the gap with the Arduino VENTUNO Q. It now runs real-time Edge Impulse anomaly detection and makes the raw signal, score, and verdict visible to every system via the Unified Namespace through a MQTT broker. This project closes the second half at the edge itself. A local software agent, powered by an on-device large language model, watches the same UNS topics, reasons about the anomaly in the context of the machine’s recent history, and decides whether a repair is warranted or the event can be dismissed. The decision and the “why” are written back into the namespace so every subscriber sees both the original detection and the reasoned triage at the same instant. Everything continues to run on a single industrial board, the Arduino VENTUNO Q (Qualcomm Dragonwing IQ8 + Hexagon NPU). No cloud inference, no central server, no point-to-point wiring. <h3>From detection to decision</h3>The Unified Namespace remains the single source of truth for state and events. The agent does not replace the UNS, it subscribes from it and contributes back to it publishing reasonings. <figure><img src="https://projects.arduinocontent.cc/8cfe900f-c583-43d8-8aad-2257d3656eb4.png"/><figcaption></figcaption></figure> Typical flow: The <a href="https://studio.edgeimpulse.com/public/1087181/live">Edge Impulse model from the part 1</a> publishes: <pre>…/vibration/raw </pre><pre>…/vibration/anomaly_score </pre><pre>…/vibration/verdict </pre>The local maintenance agent is subscribed to the relevant topics under the ISA-95 hierarchy (e.g., <code class="code">Acme/Barcelona/Packaging/Line_1/Conveyor_1/vibration/# </code>). When a new anomaly score is published, the agent which is subscribed wakes, gathers short recent context from the namespace, and prompts the on-device LLM (Qwen3 4B running via the App Lab LLM brick on the NPU). The agent reasons and produces a structured decision: <code class="code">repair </code>or <code class="code">false_alarm </code>, together with a short natural-language justification and any relevant confidence or recommended next steps. The decision and the reasoning trace are published back into the UNS, for example: <pre>…/vibration/agent_verdict </pre><pre>…/vibration/agent_reasoning </pre><pre>…/maintenance/decision (or equivalent under the equipment node) </pre>This pattern keeps the architecture clean. The UNS carries state and events and the agent performs directed reasoning and writes its conclusions on new topics. No hard-wired callbacks, no monolithic decision service. <h3>The local AI agent</h3>Machine builders still ship equipment that stops at alarm. Closing the interpretation loop at the edge delivers three concrete advantages: <ol><li>Latency and autonomy : the decision is made on the machine itself, even if the plant network or enterprise systems are temporarily unreachable. </li><li>Explainability : reasoning logs travel within the UNS, so maintenance, production, and engineering teams see the same justification if they are subscribed. </li><li>Scale : A single agent that publishes its logs into a unified namespace is the starting point for later multi-agent coordination (Project 3) without rewriting the sensing or publication layer. </li></ol> <figure><img src="https://projects.arduinocontent.cc/9c4f4b37-b762-40ac-bfe2-c18b80db9444.png"/><figcaption></figcaption></figure> The architecture remains decentralized with state living in MQTT topics, reasoning is local, and new consumers can appear at any time simply by subscribing. The agent is intentionally lightweight and single purpose for this project: <ol><li>Role : Maintenance triage agent. </li><li>Input : Live anomaly score, verdict, recent raw/score history, and any machine-state topics already present in the UNS. </li><li>Model : Local Qwen3 4B (or equivalent) served by the Arduino App Lab LLM brick on the Hexagon NPU. Short memory is kept so the agent can consider recent context without long context windows. </li><li>Output : Structured decision (repair / false_alarm) plus a concise reasoning trace that is itself published so operators and other systems can inspect the “why.” </li><li>Failure mode : If the LLM is unavailable or confidence is low, the agent can fall back to a conservative rule (e.g., treat high scores as repair) and still publish a clear decision. </li></ol>Because the agent both reads and writes the UNS, the same topics that power the <a href="https://projecthub.arduino.cc/marc-edgeimpulse/from-industrial-edge-ai-to-the-unified-namespace-10566b">first part of the Project EdgeAI to UNS</a> dashboard now also power the agent’s reasoning visibility. The dashboard gains a third panel showing the agent’s current context, the prompt/trace, and the final decision. <h3>Getting started</h3>Hardware <ol><li>Arduino VENTUNO Q </li><li>Optional real vibration sensor (simulator still included) </li></ol> Software <ol><li>Arduino App Lab </li><li><a href="https://studio.edgeimpulse.com/signup?utm_medium=community&amp;utm_source=community&amp;utm_campaign=51891547-ventunoq-launch&amp;utm_content=signup-link">Edge Impulse Studio free account </a>. </li><li>Bricks required: `vibration_anomaly_detection` ( <a href="https://projecthub.arduino.cc/marc-edgeimpulse/from-industrial-edge-ai-to-the-unified-namespace-10566b">Edge Impulse model from Project 1: From EdgeAI to UNS </a>), custom `mqtt_broker` (Unified Namespace), LLM (local Qwen3 4B or equivalent) </li></ol> Steps Clone the <a href="https://github.com/mpous/edgeai-to-agenticai-reasoning-industrial-automation">Edge AI to Agentic AI reasoning project </a>from the Github Repository or just download the zip file with the code. Import the zip file into the Arduino App Lab with the Arduino VENTUNO Q connected. <figure><img src="https://projects.arduinocontent.cc/92928633-34a5-475c-bab8-368ddb3f8071.png"/><figcaption></figcaption></figure> Ensure the LLM brick is loaded, go to the AI models and downloadthe Qwen3 4B model (or your fav local model). <figure><img src="https://projects.arduinocontent.cc/accc7e81-b2b6-494d-9d08-795149885a67.png"/><figcaption></figcaption></figure>Ensure that the `Vibration Anomaly detection` brick has the Edge Impulse model downloaded and deployed. If not, you can find all the step-by-step instructions in the <a href="https://projecthub.arduino.cc/marc-edgeimpulse/from-industrial-edge-ai-to-the-unified-namespace-10566b">Part 1 of the project </a>. <figure><img src="https://projects.arduinocontent.cc/f5b55cd9-c6b8-43c8-bee7-8c70cc2ef217.png"/><figcaption></figcaption></figure> Click Run the app and open http://&lt;local-ip-address&gt;:5001 <figure><img src="https://projects.arduinocontent.cc/fb30f3d1-75ca-4bb1-a73f-c25840eb995b.png"/><figcaption></figcaption></figure> Trigger an anomaly (or wait for the simulator) and watch the agent reason and publish its verdict into the live UNS tree. <figure><img src="https://projects.arduinocontent.cc/6f8d25f0-dc26-4275-8783-1566c6a5da53.png"/><figcaption></figcaption></figure> <figure><img src="https://projects.arduinocontent.cc/fbd17d94-dbe5-40c4-b6d1-a280340c38c2.png"/><figcaption></figcaption></figure>You also can see the logs via the Arduino App Lab and the NPU and CPU performance. <figure><img src="https://projects.arduinocontent.cc/512bb1ec-e0e4-4cf1-bfd8-24b225404428.png"/><figcaption></figcaption></figure> Here you have the full cycle, from an anomaly detected locally during the conveyor's job using Edge Impulse ML model, to an agent running on-device in the Arduino VENTUNO Q reasoning if the anomaly detected is a false alarm or not, and publish that reasoning in the Unified Namespace of the company. <h3>Lessons for machine builders</h3>You now build a machine that does more than report a number or an anomaly score. It continuously evaluates its own health with an anomaly detection Edge Impulse model, reasons about that health with a local language model, and makes both the detection and the reasoned decision visible to the entire enterprise via a single Unified Namespace. This is the concrete second step from “vibration to repair” toward autonomous edge equipment. Project 3 builds directly on the decision topics published here by introducing multiple specialized agents that coordinate over Agent-to-Agent messaging while still treating the UNS as the shared state backbone. Note – Remember this project is for illustrative and educational purposes only. </body></html>

From Edge AI to Agentic AI reasoning

Local AI agent triage of vibration anomalies on Arduino VENTUNO Q with Edge Impulse, UNS, and on-device LLM