Warum deterministische Graphen emergente Loops in industriellen Steuerungen schlagen
Hinweis: Dieser Beitrag wurde unter dem Messaging-Stand vom Mai 2026 neu verfasst. Der ursprüngliche Embedded-C-Artikel passt nicht mehr zur Positionierung — ForestHub ist jetzt eine graph-first Orchestrierungsplattform, und die Engine interpretiert Workflows zur Laufzeit, statt Pro-Gerät-Code zu generieren.
Jedes gängige Agent-Framework heute — LangChain, OpenAI Agents SDK, Claude Code, n8n in seinen AI-Modi — teilt eine einzige Designentscheidung: die Loop des LLMs ist das Programm. Man gibt dem LLM einen System-Prompt, einen Stapel Tools, und lässt es iterieren, bis es entscheidet fertig zu sein. Skills, Hooks, Sub-Turns, Steering, MCP-Plugins sind alle Erweiterungen um diese Loop herum.
Für einen persönlichen Assistenten ist das das richtige Modell. Für industrielle Steuerung ist es das falsche. Wenn die Konsequenz eines Tool-Calls ist, dass ein Relais schaltet, ein Sollwert sich ändert oder eine Dosis ausgeliefert wird, ist „was das LLM entschieden hat" keine akzeptable Antwort an Ihren Auditor.
Vier Properties, die Loop-first strukturell nicht liefern kann
Industriekunden brauchen Workflows, die einsehbar sind (jede mögliche LLM-Entscheidung ist ein sichtbarer Wire auf dem Canvas), wiederabspielbar (gleiche Inputs erzeugen den gleichen Flow), auditierbar (die Menge der möglichen Aktionen ist endlich und aufzählbar) und eingegrenzt (das LLM kann auf keine Daten und Systeme zugreifen, zu denen es nicht explizit Zugang hat). Loop-first-Frameworks kann man sandboxen, ihre Shells denylisten, mit Approval-Hooks umwickeln — aber das zugrundeliegende Modell bleibt: gib dem LLM die Schlüssel und vertraue der Runtime, es einzudämmen.
Die Inversion
ForestHub kehrt das Verhältnis um: Der Graph ist das Programm, das LLM ein Knoten. Manche Knoten sind deterministisch (Sensor lesen, Wert transformieren, verzweigen, aktuieren). Andere Knoten sind LLM-Agenten. Die Engine orchestriert alles. Das LLM ist eine Komponentenart unter vielen.
Diese eine Inversion verändert die Form des Systems: explizite Komposition statt emergentem Verhalten, First-Party-Tool-Surface (kein Escape Hatch), push-basierter State (kuriert vom Builder), Branching als First-Class-LLM-Output, einheitliches Trigger-Surface, gleiche Engine von Cloud bis Gateway bis Device.
Striktes Superset
Hier kommt das Argument, das Wettbewerber übersehen: Sie können einen Loop-first-Agenten innerhalb unseres Graphen bauen. Ein Agent-Knoten, ein großer Prompt, viele Tools, keine Branches, run-to-completion. Unsere Engine unterstützt das ab Werk. Wir verlieren das Open-Ended-Assistant-Pattern nicht. Wir containen es. Constraint ist opt-in.
Die meisten Agent-Frameworks erzwingen eine Wahl zwischen freilaufender Chat-Loop und starrer Pipeline. Der Graph sitzt über beidem. Sechs konkrete Patterns dazu unter /patterns.
Der Graph ist das Programm. Das LLM ein Knoten.