Edge AI Cannot Reliably Trigger Hardware Interrupts
By wGrow Project Team ·
We gave an agent a Python tool called open_valve, mapped to a GPIO pin. The plan was simple: read the sensor, open the dosing valve for 500 ms, close it. The agent set the pin high. Then it started on its next reasoning step, a compute spike stretched that step to 2,500 ms, and the valve stayed open for the whole stall. We flooded a test rig.
Nobody was hurt, and the rig was cheap to dry out. The lesson wasn’t cheap. Intelligence does not override physics. The valve doesn’t care how good the next token is.
Why token generation breaks real-time guarantees
The agent had no bug. It did exactly what we asked: call a tool, then keep reasoning. The mistake was ours, in the architecture. We put a probabilistic process in charge of a deadline.
A tightly scoped firmware path on a microcontroller can be designed, measured and held to a bounded timing budget. C alone doesn’t guarantee that, since unbounded loops, blocking I/O, interrupts and DMA contention can all break timing. But you can find those hazards and test against them. Physical machinery depends on that budget being enforced by firmware, timers and fail-safe limits, not by the next token arriving on time. In an RTOS, a missed deadline isn’t a glitch you retry. It’s a system failure. A hardware interrupt handler works in microseconds. Our valve window was 500 ms, generous by that standard, and we still blew through it by a factor of five.
Token generation makes no such promise. The time between tokens shifts with context length, memory bandwidth and thermal throttling, even on dedicated edge hardware. Longer context means more work per token. A warm device slows itself down. Another process grabs bandwidth and everything stretches. Average those effects over a long response and you get a comfortable number. You still can’t bound the worst case, and a valve only cares about the worst case.
So the rule is blunt: never put a language model in the critical path of a physical relay or hardware interrupt. Not “usually fast enough.” Not “with a watchdog on top.” Not there at all.
Separation of concerns in edge AI
After the flood we redrew the boundary. Agents set policy. Microcontrollers execute it.
The agent is the brain. It ingests telemetry, reasons over historical sensor data, and decides what the physical parameters should be: how long to dose, how often, under what conditions. It works asynchronously. Two seconds or twenty, nothing physical waits on it.
The microcontroller is the nervous system. It runs deterministic code that carries out the action using the parameters it was last given. It never asks the agent for permission at execution time, and it never waits.
Isolation is what matters most. If the agent crashes, hangs mid-inference or loses its network, the hardware loop keeps running on its last known good configuration. The failure mode becomes “stale policy,” which is a monitoring problem. It is no longer “valve stuck open,” which is a mop problem.
Building a deterministic handoff pipeline
Our edge modules now use an ESP32 for execution. The flow has four steps.
1. The agent emits a strict JSON payload. It carries configuration parameters only, such as valve_duration_ms: 500. The output is data, never an instruction to act now. We don’t rely on prompt discipline to enforce this. The payload schema does, because it has no field that means “open the valve at this instant.”
2. The payload travels over a message broker. The agent publishes and the ESP32 subscribes. The agent never holds a handle to the device, and it has no tool that touches a pin.
3. Deterministic C code parses and validates. The firmware checks the payload against hard limits compiled into the device. A duration outside the allowed range is rejected, and the previous configuration stays in force. The model can propose a number. It can’t talk the firmware out of its own bounds.
4. A hardware timer closes the valve. When the dosing condition is met, the C code drives the pin high and arms a hardware timer. The timer pulls the pin low after 500 ms, within the timer’s tolerance. The close doesn’t depend on a task getting scheduled, a network being up, or anything else being awake.
The inference engine has no idea what state the pin is in. That’s deliberate. The agent can be slow, wrong or offline, and the worst it can do is send a bad but bounded parameter.
That guarantee is only as strong as the bounds, though. Firmware limits catch out-of-range values, not in-range values that happen to be wrong for the moment. A 500 ms dose is safe on a healthy rig and may not be on a degraded one. So set the limits such that every value inside them is survivable, and keep monitoring and alerting on stale or drifting policy. This design caps the damage. It doesn’t make the agent’s judgment correct.
We also dropped a habit from the first design. We had treated the tool call as the unit of work: the agent acts, observes, acts again. That loop suits software. For hardware, the loop that matters is sense, decide, actuate, and it has to close on the device. The agent supervises that loop from above and adjusts its settings. It doesn’t sit inside it.
The hybrid control loop
If you’re moving from pure software agents to physical automation, expect to unlearn something. In software, a tool call that runs long is an annoyance. In hardware, the same delay can have consequences. The tooling that made agents easy to build, where anything callable becomes a tool, also makes it easy to wire a language model straight to a relay. Resist that. A tool that touches a pin isn’t a tool. It’s a liability with a function signature.
Language models are good at what classical control loops handle poorly: reading messy telemetry, noticing drift, choosing parameters from history. They’re bad at the one thing a control loop must do, which is finish on time. Let them supervise control loops, not replace them.
Edge IoT is likely to end up hybrid. Heavy, unpredictable models will set the rules somewhere with room to be slow. Lightweight, predictable microcontrollers will enforce those rules at the metal, where timing is law. We learned that boundary by flooding a test rig. You can learn it from this page instead.
Keep the LLM away from the relay.