Edge Agent Plattform statt Punktlösung

Der erste Anwendungsfall ist meistens einfach zu begründen. Eine Maschine soll früher melden, wenn ein Lager heißläuft. Ein Gebäude soll seine Lüftung an die tatsächliche Belegung anpassen. Für jedes dieser Probleme lässt sich eine Speziallösung kaufen oder bauen, eine Box, eine App, ein Skript. Das funktioniert genau einmal. Beim zweiten Anwendungsfall fängt man wieder bei null an, mit neuer Hardware, neuer Integration und neuer Wartung. Wer so wächst, sammelt Insellösungen statt eine Grundlage. Ein Edge Agent als Teil einer Plattform dreht diese Logik um. Die Investition in das erste Problem trägt das zweite, dritte und zehnte mit.

Punktlösung skaliert nicht

Eine Punktlösung ist auf genau ein Problem zugeschnitten. Das ist ihr Vorteil und gleichzeitig ihre Grenze. Sie bringt eigene Hardware mit, eine eigene Anbindung an die Steuerung, ein eigenes Update-Verfahren und eine eigene Bedienoberfläche. Drei Anwendungsfälle bedeuten drei Stück Hardware, drei Integrationswege und drei Dinge, die einzeln gepflegt, gepatcht und im Auge behalten werden müssen.

Der Aufwand wächst dabei nicht linear, sondern überproportional. Jede zusätzliche Insel erhöht die Zahl der Schnittstellen, an denen etwas auseinanderlaufen kann, über unterschiedliche Versionsstände, unterschiedliche Sicherheitsannahmen und unterschiedliche Logdaten hinweg. Was als pragmatische Einzelentscheidung beginnt, wird über die Jahre zu einer Landschaft, die niemand mehr vollständig überblickt. Genau hier verliert die Punktlösung ihren anfänglichen Geschwindigkeitsvorteil wieder.

Eine Grundlage, viele Anwendungsfälle

Eine Plattform trennt das Dauerhafte vom Fallspezifischen. Dauerhaft sind die Runtime, der Builder, der Deploy-Weg und die Verwaltung vieler Geräte. Fallspezifisch ist nur der Graph, also die Beschreibung dessen, was ein konkreter Edge Agent tun soll.

Das Fundament dafür ist eine graph-first Runtime. Der Workflow-Graph ist das Programm, die KI ist genau ein Knoten darin. Der Ablauf ist deterministisch, einsehbar und in seinen Grenzen klar definiert. Damit lässt sich derselbe Baustein-Vorrat über sehr unterschiedliche Aufgaben hinweg wiederverwenden. Hardware-I/O steht als erstklassige Knoten bereit (GPIO, ADC/DAC/PWM, UART/seriell, MQTT als Publish und als Trigger), dazu Trigger wie Schwellwert-mit-Hysterese, Pin-Flanke oder Zeitalarm, dauerhafter Speicher auf dem Gerät und semantische Suche über eine Wissensbasis. Service-Assistent, Gebäude- und Lüftungssteuerung, Smart Home und vorausschauende Wartung sind vier Felder, die ein Modell abdeckt. Was sich ändert, ist die Verdrahtung der Knoten, nicht das System darunter. On-Device-KI wird so vom Einzelprojekt zur Linie.

Dasselbe Binary von Pi bis Jetson

Eine Plattform ist nur dann eine Grundlage, wenn sie nicht an der Hardware zerbricht. Die Engine läuft als ein einziges Binary auf sehr unterschiedlichen Geräten, vom Raspberry Pi über einen Jetson und einen Industrie-Controller bis zu x86. Der Wechsel auf stärkere oder andere Hardware ist ein erneutes Ausrollen, kein Neuschreiben.

Das hat einen direkten Effekt auf die Skalierung. Ein Anwendungsfall, der auf einem kleinen Gerät als Pilot startet, zieht ohne Portierung auf eine leistungsfähigere Klasse um, wenn er in Serie geht. Die Intelligenz folgt einer Kaskade. Erst Regeln, dann klassisches maschinelles Lernen, dann ein lokales kleines Sprachmodell (SLM, 1-3B) über einen lokalen, OpenAI-kompatiblen Inferenz-Server direkt neben der Engine, darüber bei Bedarf ein mittelgroßes offenes Modell und erst als Ausnahme ein Frontier-Modell in der Cloud. Ein Großteil typischer Industrieaufgaben lässt sich bereits mit einem KI-Agent auf der Maschine auf SLM-Ebene erledigen, lokal und ohne ständige Cloud-Anbindung.

Verwaltung als eigentlicher Mehrwert

Aus einem Gerät werden schnell viele. Genau hier setzt die Verwaltungsschicht an, mit Fleet-Orchestrierung, einer Agent Registry und einem durchgängigen Deploy-Lebenszyklus. Ein Bootstrap-Bundle aus docker-compose und Gerätemanifest bringt ein Gerät in den Betrieb. Deploy, Preflight, Stop, Heartbeat und Status halten den Bestand sichtbar, und signierte Images sorgen für eine nachvollziehbare Verteilung. Über viele baugleiche Geräte hinweg verbessert föderiertes Lernen die Modelle, ohne Rohdaten zu zentralisieren.

Wichtig ist die offene Aufteilung. Engine, LLM-Proxy und Builder sind als Open-Core öffentlich und ohne Account voll nutzbar, und die Plattform funktioniert offline und standalone. Das Backend ist kein Tor, durch das man muss, sondern die Komfort- und Verwaltungsschicht für den Betrieb in der Breite. Sicherheit entsteht dabei aus lokaler Ausführung, Container-Isolation und dem auditierbaren, begrenzten Graphen. Die Architektur ist auf die Anforderungen des EU Cyber Resilience Act hin entworfen (CRA-Readiness als Architektureigenschaft, mit signierter Image-Verteilung und geplanter SBOM/Signierung).

So läuft das am Edge

Ein Betreiber startet mit vorausschauender Wartung an einer Maschine. Ein Schwellwert-Trigger mit Hysterese liest einen Vibrationssensor über ADC. Ein lokales SLM klassifiziert das Muster, und das Ergebnis geht per MQTT an die Leitwarte und wird im dauerhaften Speicher des Geräts protokolliert. Der Agent sitzt dabei nie in der Echtzeit-Regelschleife. Er folgt dem Muster „Agent als Werkzeug“ und schreibt nur gepufferte Parameter, etwa einen Sollwert, während der deterministische Controller ununterbrochen weiterregelt.

Drei Monate später kommt ein zweiter Fall dazu, ein Service-Assistent, der Technikern über semantische Suche die passende Anleitung aus einer Wissensbasis liefert. Neue Hardware ist dafür nicht nötig. Dasselbe Binary, derselbe Builder, derselbe Deploy-Weg, nur ein zweiter Graph, der über die Fleet-Schicht auf dieselbe Geräteklasse ausgerollt wird. Die Grundlage aus dem ersten Projekt trägt das zweite. Genau das ist der Unterschied zwischen einer Plattform und einer Insel.

Das Wichtigste in Kürze

• Eine Punktlösung löst genau ein Problem, und ihr Aufwand wächst überproportional mit jedem weiteren Anwendungsfall.
• Eine Edge Agent Plattform trennt Dauerhaftes (Runtime, Builder, Deploy, Fleet) vom Fallspezifischen (dem Graph), sodass ein Modell viele Anwendungsfälle trägt.
• Dasselbe Binary läuft von Raspberry Pi bis Jetson, also ist Skalierung ein erneutes Ausrollen, kein Neuschreiben.
• Fleet-Orchestrierung, Agent Registry und der signierte Deploy-Lebenszyklus sind der eigentliche Mehrwert über viele Geräte hinweg.
• Open-Core bedeutet ohne Account nutzbar und offline-fähig, wobei die Verwaltungsschicht Komfort ist, kein Zwang.