Graph Engineering mit KI: Ein Fall aus dem eigenen Betrieb
Graph Engineering mit KI ist derzeit ein absoluter Hype-Begriff in der KI-Welt. Dieser reale Fall dokumentiert jedoch: Daran ist nichts Mystisches und es hat rein gar nichts mit Raketenwissenschaft zu tun. Es ist schlicht die Art, wie man heute einen KI-gestützten Ablauf baut, der unbeaufsichtigt laufen soll.
Graph Engineering klingt zunächst nach einer Werkzeugkategorie. Tatsächlich ist es eine präzise Zerlegung: Arbeit wird in einzelne Schritte geschnitten, Übergänge werden als logische Bedingungen formuliert und der Zustand wird explizit gespeichert. Das Ergebnis ist ein klar definierter Graph aus Knoten und Kanten.
Der wahre Nutzen zeigt sich erst in der Frage, die sich ohne diese Zerlegung gar nicht stellen lässt: Welcher Knoten braucht tatsächlich einen KI-Agenten und welcher nicht? Diese Antwort entscheidet über Kosten, Laufzeit und die Verlässlichkeit eines unbeaufsichtigten Ablaufs.
Ein Praxisbeispiel aus dem eigenen Haus zeigt, wie das funktioniert: Ein Prozess, der seit dem 2. Juni 2026 im Einsatz ist und seit dem 26. August zweimal täglich selbstständig publiziert.
Der Fall
Die KI-News-Seite von iconference.ch wird nicht manuell gepflegt. Die Quellenliste umfasst 40 Einträge, und sie zerfällt in zwei Gruppen, die auf verschiedenen Wegen hereinkommen.
21 Quellen liefern einen RSS- oder Atom-Feed, darunter OpenAI, Google DeepMind und mehrere Schweizer Fachmedien. Diese holt ein Python-Skript deterministisch ab, mit einem Zeitfenster von zwei Tagen und höchstens fünf Einträgen je Quelle. Bereits gesehene Links fallen über eine Zustandsdatei heraus. Fällt eine Quelle aus, überspringt das Skript sie und läuft weiter.
Die übrigen 19 haben keinen Feed, etwa die News-Seite von Anthropic. Für sie legt das Skript nur einen Platzhalter mit der URL an. Geholt werden sie erst im nächsten Schritt vom KI-Agenten, der die Seite per HTTP abruft und daraus die ein bis drei neuesten Meldungen liest. Zusätzlich durchsucht er das Postfach [email protected] nach Newslettern.
Aus diesen Kandidaten wählt der Agent aus und verfasst zweisprachige News-Beiträge. Danach übernimmt wieder Code: zusammenführen in eine JSON-Datei, statische Seiten bauen, committen, pushen. Zwei Minuten später ist der Inhalt online. Stand heute: 607 Meldungen aus 94 Läufen.
Knoten, Kanten, Zustand
Die Knoten sind die konkreten Arbeitsschritte: Quellen abrufen, kuratieren, publizieren.
Die Kanten sind deterministische Bedingungen, keine blossen Dekorationspfeile auf einer Präsentationsfolie. Liegt der Entwurf für einen Lauf bereits vor, bricht das Skript sofort ab. Sind die Kandidaten schon geholt, werden sie wiederverwendet statt erneut abgefragt. Jede dieser Regeln ist als klare Abfrage im Skript hinterlegt und nachvollziehbar.
Der Zustand liegt als Datei auf der Festplatte. Damit übersteht er einen Absturz. Ein abgebrochener Lauf kostet lediglich einen Neustart, aber keine verlorene Arbeit.
Nur ein Knoten braucht eine KI
In diesem Ablauf benötigt genau ein Knoten ein Sprachmodell. Er erledigt dort zwei Aufgaben, für die es keine festen algorithmischen Regeln gibt: die Auswahl der Kandidaten und das Schreiben der News-Beiträge in zwei Sprachen. Beides erfordert Urteilskraft und Formulierungsgabe. Diesen Knoten übernimmt Claude Fable mit fest definiertem Modell und stark eingeschränktem Werkzeugkasten: Lesen, Schreiben, Web-Abruf und Postfach-Suche, mehr nicht. Vor dem Umbau waren es zwei Modellläufe, weil auch der Publish-Schritt über ein Modell lief.
Genau dieser Knoten ist zugleich die einzige Stelle, an der fremder Text ins System kommt: Feed-Titel, Zusammenfassungen, ganze Web-Seiten, alles ungeprüft. Der Auftrag behandelt diesen Text deshalb ausdrücklich als Daten und nie als Anweisung. Der Agent befolgt keine Handlungsaufforderung aus einem News-Inhalt, und der Web-Abruf ist auf die URLs der Quellenliste begrenzt, nie auf eine URL, die im Inhalt selbst auftaucht. Ein Ablauf, der fremde Seiten liest und danach unbeaufsichtigt in ein Git-Repository schreibt, braucht diese Grenze. Ohne sie genügt ein präparierter Feed-Eintrag.
Alle übrigen Knoten kommen ohne KI-Agenten aus, da sie rein deterministisch arbeiten: Feeds abholen, Dubletten gegen die letzten 14 Tage abgleichen, JSON zusammenführen, Statik erzeugen, Git-Commit und Git-Push durchführen sowie den Statusbericht per Mail versenden.
Der letzte Knoten ist neu und wirkt auf den ersten Blick wie ein typischer Fall für eine KI. Nach jedem Durchlauf wird eine System-Mail generiert: Was ging live? Welcher Commit-Hash? Wie hoch ist der Gesamtdatenbestand? Ein Sprachmodell braucht es dafür jedoch nicht. Der Inhalt steht fest, sobald der Lauf beendet ist, und die Schlagzeilen wurden zwei Schritte zuvor verfasst. Es gibt nichts mehr zu formulieren, nur noch zu berichten.
Genau hier verläuft die Trennlinie in der Praxis: Nicht «Text erzeugen» erfordert ein Sprachmodell, sondern «Text erzeugen, für den es keine starre Regel gibt».
Diese Zerlegung dauert auf dem Papier eine halbe Stunde: Drei Spalten für Knoten, Kanten und Zustand, gefolgt von der Frage bei jedem Knoten, ob eine einfache Bedingung genügt hätte. Diese Analyse gehört vor die Werkzeugauswahl, nicht danach.
Wer den Graphen gebaut hat
Ich habe gesagt, was entstehen soll und was es können muss. Die technische Architektur stammt von Claude: welcher Knoten ein Modell benötigt, welcher deterministisch bleibt und wo die Abbruchbedingungen liegen müssen. Anschliessend erstellte Claude den Code, also Skripte, Validierungen und Prompts.
Damit hat Claude in diesem Vorhaben zwei Rollen. Als Baumeister hat er den Ablauf entworfen und gebaut. Im laufenden Betrieb ist er der Entscheider an dem einen Knoten, der Urteil verlangt. Diese Trennung ist kein Detail: Der Baumeister arbeitete unter meiner Beurteilung, der Entscheider arbeitet ohne Eingriffe von mir.
Meine Rolle war die des Auftraggebers und Prüfers: beurteilen, ob das Konzept trägt, und die Freigabe erteilen. Getestet wurde an einer isolierten Ordnerkopie, und zwar Trockenläufe, blockierte Läufe, echte Commits mit Push, bereits publizierte Entwürfe sowie Entwürfe ohne jegliche Auswahl.
86 Läufe unter Aufsicht
Vom 2. Juni bis zum 26. August enthielt der Graph einen zusätzlichen Knoten: die menschliche Freigabe. Der Ablauf bereitete den Entwurf vor und hielt an. Ich prüfte die zwölf zweisprachigen News-Beiträge, wählte aus und löste die Publikation manuell aus. In dieser Phase entstanden 1052 News-Beiträge, von denen 550 veröffentlicht wurden.
Die Entscheidung zur Vollautomatisierung beruhte auf zwei Faktoren. Der erste ist Kapazität: Manuelle Freigabe skaliert nicht, ein Lauf pro Tag war das Maximum des Machbaren, heute laufen zwei.
Der zweite war der anspruchsvollere Teil, nämlich Vertrauen. Über 86 Läufe hinweg musste ich keine veröffentlichte Meldung zurückziehen: Die Auswahl war stimmig, die Übersetzungen präzise, die Publikationsvorschläge korrekt. Eine Automatisierung mit Aussenwirkung gibt man nicht frei, weil die Architektur auf dem Papier überzeugt, sondern weil die Ergebnisse über Monate hinweg stabil bleiben. Ein einzelner fehlerfreier Durchlauf beweist gar nichts.
Was die Automation ersetzt hat
Wenn ein Mensch einen Entwurf prüft, tut er zwei Dinge gleichzeitig: Er fängt ab, was gar nicht erst hinausgehen darf, und er beurteilt die inhaltliche Qualität. Will man diesen Kontrollschritt automatisieren, muss man beide Aufgaben aufteilen. Das Abfangen übernimmt harter Programmcode, während die Qualitätsbeurteilung über geschärfte Prompts und Leitplanken an die KI übergeben wird.
Der Kurationsauftrag an die KI wurde dafür präzisiert:
- Maximal zwölf Veröffentlichungen pro Durchlauf.
- Strikte Sperre bei Warnhinweisen zu Datum oder Dubletten.
- Jeder verworfene Eintrag erhält die Kennzeichnung «Nicht publiziert» samt einer Begründung in einem Satz.
- Grenzfall-Regel: Im Zweifel wird ein Eintrag stehen gelassen.
Die technischen Prüfungen vor und nach der Generierung übernimmt Python, kein Sprachmodell. Der Publish-Schritt bricht sofort ab, wenn:
- ein Text ein internes Stichwort enthält,
- der Staged-Diff auf ein Secret-Muster anschlägt,
- das Website-Repository offene Änderungen enthält,
- kein Fast-Forward gegen origin möglich ist.
Sollte beim Zusammenführen etwas Unerwartetes passieren, setzt ein try/except-Block alle berührten Dateien automatisch zurück.
Ergänzt wird das System durch drei Mechanismen, die den Menschen nicht ersetzen, sondern informieren. Jeder nicht publizierte Eintrag trägt seine Begründung, was eine lückenlose Spur ergibt. Nach jedem Lauf kommt der Mail-Bericht. Und ein veröffentlichtes Element lässt sich nachträglich über einen regulären Publish wieder entfernen.
Der erste Lauf ohne Freigabe ging schief
Am 26. August um 12:08 Uhr startete der erste unbeaufsichtigte Lauf und schlug fehl. Das Skript rief node ohne vollständigen Pfad auf. Unter launchd lautet der Standard-PATH /usr/bin:/bin:/usr/sbin:/sbin, während node in /usr/local/bin lag. Der vorherige manuelle Test war erfolgreich, weil er in einer Shell mit vollständiger PATH-Variable ausgeführt wurde.
Schwerwiegender als der Fehler selbst war die Folgewirkung: Die Ausnahme war nicht abgefangen worden. Die halb zusammengeführte news.json verblieb im Repository, was den darauffolgenden Lauf blockiert hätte. Ein Ausfall, der den nächsten Lauf mitreisst, ist kein temporärer Fehler mehr, sondern ein Systemstillstand.
Am 27. August fiel der Mittagslauf erneut aus, diesmal aufgrund einer Netzwerkstörung mit gescheiterter Namensauflösung aller 21 RSS-Quellen. Der Abendlauf fing den Tag problemlos auf, da das Zeitfenster für Kandidaten auf zwei Tage ausgelegt ist. Die zwei täglichen Ausführungsslots waren ursprünglich als Kapazitätsentscheidung gedacht, erwiesen sich nun aber als wirksame Ausfallsicherung.
Wann die Freigabe unverzichtbar bleibt
Dieser konkrete Ablauf darf ohne menschliches Eingreifen laufen, weil vier Voraussetzungen gleichzeitig erfüllt sind:
- Das Ergebnis ist öffentlich sichtbar und Fehler fallen sofort auf.
- Jeder Schritt ist vollständig umkehrbar.
- Es hängen weder finanzielle Mittel noch verbindliche Zusagen daran.
- Es liegen 86 überwachte Produktivläufe als Nachweis vor.
Fehlt auch nur eine dieser Bedingungen, bleibt die menschliche Freigabe zwingend erforderlich. Ein Angebot, eine Zahlung, eine Kundennachricht oder eine Änderung an kritischer Infrastruktur: Dort sind Handlungen irreversibel und die Risikoabwägung folgt völlig anderen Regeln.
Die Freigabe aus dem Code zu entfernen war die kleinere Arbeit. Die eigentliche Leistung bestand darin, vorher exakt zu verstehen, welche Aufgabe sie bisher erfüllt hatte.
Was ohne KI nicht entstanden wäre
Es ist undenkbar, dass ich diesen Ablauf ohne KI gebaut hätte. Betreiben könnte ich ihn erst recht nicht. Beides wäre nicht an der Idee gescheitert, sondern an meiner Zeit und am fehlenden Know-how, Python und Skripte selbst zu programmieren.
Genau darin liegt der Punkt von Graph Engineering mit KI: Es geht nicht nur darum, bestehende Abläufe zu beschleunigen. Es entstehen Abläufe, die vorher gar nicht möglich waren.
Welche Geschäftsvorfälle in Ihrem Betrieb liessen sich auf diese Weise verbessern, und welche würden überhaupt erst möglich?