Graph-first vs Loop-first for Edge AI Agents

An AI agent that keeps iterating until it lands on some solution is impressive in a chat window. On a machine on the shop floor, it is a liability. Whoever runs the equipment does not want to hear that “the AI will get it right.” They want to know what it can do, what it cannot do, and in what order, above all once a real-time control loop is in play. That question splits two architectures for AI agents on the machine, loop-first and graph-first.

Loop-first, the agent decides and you hope

In the loop-first model you give the agent a goal and leave the path to it. It calls a tool, checks the result, corrects itself, then calls the next tool, looping five, six, seven times until it converges. This works for open-ended research. For machine control it is hard to govern.

The problem is not the intelligence, it is the missing structure. What remains at the end is a transcript, a sequence of attempts and not a traceable blueprint. The same task may take a different path on the next run. There is no fixed boundary on which actions are possible at all. In an environment where a wrong write touches material, machine, or person, “the agent will probably do the right thing” is not a commitment you can stand behind.

Graph-first means the graph is the program

Graph-first inverts the relationship. Instead of leaving the flow to the agent, the flow itself is the program, a deterministic sequence of typed nodes with clear boundaries. One node reads a sensor, one node checks a threshold with deadband, one node publishes an MQTT message, and one node is the AI agent. The AI is not the conductor, it is one instrument in the orchestra.

The decisive point is that the workflow graph is the artifact. You can read it, version it, walk through it in review, and inspect it before rollout. Every node has a type, a defined input and output. The AI may decide inside its node. A local small language model classifies, summarizes, or proposes a parameter. But it cannot rewrite the graph. The action space is bounded by structure, not by good intentions.

The same graph model carries across many use cases, from condition monitoring through threshold response to data enrichment at the edge. You learn one way of thinking, not ten tools.

The plan-mode analogy

Anyone working with coding agents already knows the pattern. Good agents first produce a plan and then execute it. The plan is visible, reviewable, and correctable, and the execution follows it.

Graph-first takes this idea to its conclusion. The plan is the program, and it is fixed before runtime. The intelligence is not in reinventing the flow at runtime, but in making a decision at exactly the right points. First the blueprint, then the execution. Here the blueprint is not thrown away the moment things get serious.

Why industry needs this

Three properties make graph-first attractive for local AI in industry.

• Auditability. The graph reads like a wiring diagram. What happens is known before the start, not reconstructed afterwards from a transcript.
• Boundedness. The agent cannot do anything outside its node. Its entire action space is the graph, and the graph is finite and visible.
• Security from the architecture. Local execution, container isolation, and the bounded, inspectable graph together yield a security model that does not have to rest on the AI behaving well.

Real-time stays deterministic with agent-as-a-tool

The sharpest objection first. Real-time control tolerates no AI agent that thinks for an unpredictable stretch. True, which is why the agent never sits in the control loop. The pattern is agent-as-a-tool. The deterministic controller keeps running at its fixed cycle, and the AI agent only writes parameters, buffered and outside the loop. It shifts a setpoint, and the controller picks it up when it suits. The intelligence acts on the control without sitting inside it.

An anonymous scenario

A drying station in a production line. A classic PID controller holds the temperature, reliable but rigid. When material moisture changes, the station runs too hot or too cold, and someone adjusts it by hand.

An Edge Agent runs right at the station. A trigger fires when a threshold with deadband is crossed. An AI node evaluates the trend of the last readings and proposes an adjusted setpoint. A write node places that setpoint in the controller’s buffer area. The controller keeps working without interruption at its own cycle. If the AI node fails or returns nonsense, the station keeps regulating on the last valid setpoint. The result is an AI agent on the machine that thinks along without taking over control.

How it works at the edge

Technically the agent is a single binary, the same one on Raspberry Pi, Jetson, industrial controller, or x86. Redeploy, not rewrite. Next to it runs a local, OpenAI-compatible inference server (such as llama.cpp) serving a small language model with 1 to 3 billion parameters. Hardware I/O is first-class, with GPIO, ADC/DAC/PWM, UART/serial, and MQTT on real Linux drivers. Triggers range from interval and time through threshold-with-deadband and pin-edge to an incoming MQTT message.

Behind it stands an intelligence cascade. Rules first, then classical ML, then the on-device SLM, and only in the exceptional case a larger model. A large share of industrial tasks fit on a local SLM. With a local model the on-device AI runs offline. Without one, requests travel outward. Here, local AI in industry means the decision is made where the machine stands, inside a flow you read beforehand.

Key Takeaways

• Loop-first lets the agent iterate until some solution stands, flexible but hard to trace and hard to bound.
• Graph-first makes the workflow graph the program, with typed nodes, clear barriers, and the AI as one node among many.
• As with the plan mode of coding agents, first the blueprint and then the execution, only here the plan is fixed before runtime.
• Industry gains auditability, boundedness, and a security model from the architecture rather than from trust.
• Real-time stays deterministic, because via agent-as-a-tool the agent only writes buffered parameters and never sits in the control loop.