Am 18. Juli postete Peter Steinberger elf Wörter: „Reden wir noch über Loops, oder sind wir schon bei Graphen?“ An diesem Tag wurde nichts veröffentlicht. Kein Framework, kein Modell, keine neue Fähigkeit. Der Post überschritt innerhalb einer Woche drei Millionen Aufrufe, und schon am nächsten Morgen kursierte „Graph Engineering“ als Nachfolger von Loop Engineering, einem Begriff, der selbst erst seit Juni die Diskussion beherrscht hatte. Eine Woche später fragte Steinberger, allem Anschein nach amüsiert, ob er jetzt ein Graph Engineer sei. Der Begriff benannte nichts Neues. Er benannte den Diskurs, der sich um eine Frage gebildet hatte, und die Frage zündete, weil der Fragende sechs Wochen zuvor dasselbe mit Loops gemacht hatte. Steinberger hat OpenClaw gebaut; wenn er fragt, was die nächste Ebene ist, nimmt ein großes Publikum an, dass er sie schon gesehen hat.
Was der Begriff bedeutet, wenn man ihn ernst meint
Ein Agent-System als expliziten Graphen bauen: Knoten, die abgegrenzte Arbeit erledigen, Kanten, die entscheiden, was als Nächstes läuft, und ein gemeinsames Zustandsobjekt, das entlang der Kanten wandert und sammelt, was jeder Knoten produziert hat. Statt eines großen Prompts oder eines einzelnen Agenten, der so lange im Kreis läuft, bis er sich selbst für fertig erklärt, zeichnen Sie die Topologie, und eine Runtime arbeitet sie ab. Loop Engineering, entstanden aus Geoffrey Huntleys Ralph-Methode, drehte sich darum, einen einzelnen Agenten über sein Kontextlimit hinaus weiterlaufen zu lassen. Graph Engineering dreht sich darum, was passiert, wenn mehrere dieser Zyklen mit Abhängigkeiten, Verzweigungen und Gates dazwischen verdrahtet werden müssen.
Warum jetzt, und warum die Aufregung? Zum Teil, weil die Praxis dem alten Wort entwachsen war. Ein Loop mit einem Validator-Knoten, einem Reparaturpfad und einem menschlichen Freigabeschritt ist kein Loop mehr, und wer im Juni solche Systeme baute, hatte keinen Namen für das, was er da zeichnete. Zum Teil, weil dieses Feld Aufmerksamkeit über Namen verteilt: Prompt, Context, Harness, Loop, Graph, vier Umbenennungen desselben Zuverlässigkeitsproblems in achtzehn Monaten. Manche dieser Umbenennungen markierten eine Veränderung des Problems. Andere eine Veränderung dessen, wer gerade redete.
Der Vier-Punkte-Test: Ist das Graph Engineering?
Der Test, der dieses Jahr die Runde macht, um das eine vom anderen zu trennen, hat vier Teile. Ein System ist graph-engineered, wenn (1) Sie seine Schritte und Übergänge aufzählen können, ohne es auszuführen, wenn (2) diese Struktur getrennt von den Prompts existiert, die sie steuert, wenn (3) eine Runtime die Struktur ausführt statt imperativem Code, in dem der Kontrollfluss vergraben ist, und wenn (4) die Struktur über Läufe hinweg als etwas bestehen bleibt, das man versionieren kann. Der Test stammt aus der Fachpresse, nicht aus einem Standard, und die meistzitierte akademische Einordnung ist ein Preprint. Die Leute, die den Begriff definieren, sind größtenteils die Leute, die ihn verkaufen.
Ausführungsgraphen, keine Wissensgraphen
In diesem Bereich heißen zwei Dinge Graph, und sie haben nichts miteinander zu tun. Ein Knowledge Graph und die darauf aufbauenden GraphRAG-Systeme modellieren Daten: Entitäten, Relationen, was womit verbunden ist. Ein Ausführungsgraph modelliert, wer als Nächstes läuft, unter welcher Bedingung und mit welchem Zustand im Gepäck. Graph Engineering im Sinne von 2026 meint das Zweite. Knoten erledigen Arbeit, egal ob diese Arbeit ein Modellaufruf, ein Tool-Aufruf, ein Parser oder ein Mensch ist, der etwas freigibt. Kanten sagen, was danach passiert. Ein gemeinsames Zustandsobjekt fährt auf den Kanten mit und sammelt, was jeder Knoten produziert hat. Wenn jemand Graph Engineering sagt und Retrieval meint, meint er etwas anderes.
Jede Ebene bekommt ihren Namen, wenn die darunter nicht mehr der Engpass ist
Die Herkunft des Begriffs ist interessanter als seine Definition. Prompt Engineering optimierte den einzelnen Turn: was das Modell gefragt wird. Context Engineering optimierte das Fenster: was das Modell sieht. Loop Engineering optimierte den Zyklus: planen, handeln, reflektieren, überarbeiten, noch einmal. Graph Engineering optimiert die Übergänge zwischen den Zyklen: welcher Loop läuft, wann er übergibt und welches Gate dazwischen sitzt. Jede Ebene bekam einen Namen, als die Ebene darunter nicht mehr der Engpass war. Niemand brauchte ein Wort für Übergänge, solange ein einzelner Loop die ganze Aufgabe noch schlucken konnte.
Der Ralph Loop ist der Grenzfall: ein Knoten, eine Kante, und die Kante zeigt zurück auf den Knoten. Er besteht den Vier-Punkte-Test trivial, was ein brauchbarer Plausibilitätscheck für den Test ist. Eine Bash-Schleife, die bei jeder Iteration eine Prompt-Datei neu einliest, hat eine Struktur, die sich ohne Ausführung aufzählen lässt, eine vom Prompt-Inhalt getrennte Struktur, eine Runtime, die diese Struktur ausführt, und eine Struktur, die bestehen bleibt. Der Graph ist klein. Ein Graph ist er trotzdem.
Converge, Not Fork ist das Fan-out/Fan-in-Motiv, bei dem das Zustandsobjekt physisch geworden ist. Parallele Worker sind Knoten. Der gemeinsame SQLite-Bus ist der Zustand, den jeder Knoten liest und schreibt. Die Konvergenzregel ist die Fan-in-Kante. Als dieser Artikel für einen gemeinsamen Bus statt geforkter Kontexte argumentierte, ging es um Kantensemantik: ob der Graph zusammenführt, indem er Zustand weitergibt, oder indem er Transkripte weitergibt.
Die Drei-Loop-Topologie aus der clive-Serie ist ein Graph mit einer langsamen Kante, und die langsame Kante ist ein Mensch. Zwei schnelle innere Loops laufen ohne Aufsicht. Ein äußerer Loop geht nur weiter, wenn ein Mensch ihn weiterschaltet. Als Diagramm gezeichnet ist das eine bedingte Kante, deren Bedingung eine Freigabe ist, und das ist genau der Human-Checkpoint-Knoten, den die Graph-Frameworks beschreiben. Die Guest-House-Isolationsmethode zieht eine Grenze um einen Teilgraphen; der Produktionspfad über diese Grenze hinweg bleibt unverifiziert, und die Graph-Notation macht diese Lücke leichter sichtbar, nicht schwerer.
Harness Engineering im früheren Sinn war die Prompt-Seite derselben Trennung. Der Harness war alles, was um den Modellaufruf herumgebaut ist: Anweisungen, Tools, Retries, Verifikation. Graph Engineering ist das, was entsteht, wenn man diese Hülle nicht mehr als ein einziges Ding behandelt und anfängt, die Übergänge zwischen den umhüllten Aufrufen zu zeichnen. Der Harness steuert einen Knoten. Der Graph steuert die Kanten. Dieselbe Disziplin, eine Ebene höher, und genau um diesen Diff geht es.
Die Topologie ist das Schema
Die passende strukturelle Analogie ist ein Datenbankschema im Verhältnis zu seinen Abfragen. Das Schema migrieren Sie bewusst, mit Review, und die Migration ist das Artefakt, das Sie behalten. Abfragen schreibt man gegen das Schema und wirft sie weg, wenn sie nicht mehr nützen. Beim Graph Engineering ist die Topologie das Schema. Prompts sind Abfragen. Eine Änderung an einer Kante reviewen Sie wie eine Migration, und einen Prompt ersetzen Sie so, wie Sie eine Abfrage neu schreiben, wenn ein schnelleres Modell kommt. LangGraph und verwandte Frameworks sind die Referenzimplementierungen dieser Trennung: Das Framework hält die Kanten und den Zustand, und die Prompt-Strings sind bloß Daten, die die Knoten zufällig mit sich tragen.
Frameworks machen das auf eine Weise konkret, die man leicht für die ganze Geschichte hält. Die Guides führen durch Planen, Zerlegen, paralleles Ausführen, Zusammenführen, Validieren und Reparieren im Fehlerfall. Sie zeigen Router-Knoten, die an Spezialisten verteilen, und Evaluator-Knoten, die den Fortschritt freigeben oder blockieren. Das ist alles real. Es ist aber auch alles etwas, das ein einzelnes starkes Modell heute zur Laufzeit selbst entscheiden kann, wenn es die Tools und ein klares Ziel hat. Damit halten sich die Guides nicht lange auf.
Jede Kante ist eine Entscheidung, die das Modell nicht mehr trifft
Eine bedingte Verzweigung nach dem Muster „wenn die Validierung fehlschlägt, geh zum Reparaturknoten“ ist eine Routing-Entscheidung, die zur Designzeit festgeschrieben wurde. Ein Router-Knoten, der nach Intent verteilt, hat die eigene Lesart des Modells durch einen Klassifikator ersetzt, den Sie geschrieben haben. Jede dieser Entscheidungen ist für sich genommen vertretbar. Zusammen ergeben sie eine Wette: dass die Topologie, die Sie gezeichnet haben, besser routet, als das Modell es unbeaufsichtigt bei denselben Inputs täte. Anfang 2025 ging diese Wette meistens auf. Die Fortschritte seither waren Fortschritte genau bei dem Urteilsvermögen, das die Kanten dem Modell abnehmen, und die Wette hat ein Ablaufdatum, das mit jeder Modellgeneration näher rückt. Nichts davon spricht dagegen, den Graphen zu zeichnen. Es spricht dafür, zu wissen, welche Kanten da sind, weil man dem Modell die Entscheidung nicht anvertrauen kann, und welche da sind, weil ein Framework-Tutorial an dieser Stelle eine Verzweigung hatte. Die erste Art ist Governance und sollte bleiben. Die zweite ist Scaffolding und wird zum Bremsklotz.
Governance-Kanten und Scaffolding-Kanten
Man kann die beiden unterscheiden. Eine Governance-Kante kodiert eine Einschränkung, die gilt, egal wie fähig der Knoten dahinter wird: Ein Deployment braucht einen Menschen, Kosten brauchen eine Obergrenze, ein Merge braucht einen bestandenen Test. Eine Scaffolding-Kante kodiert einen Workaround für eine Fähigkeit, die dem Modell fehlte, als der Graph gezeichnet wurde: zerlegen, weil das Modell nicht die ganze Aufgabe im Kopf behalten konnte, separat validieren, weil das Modell seine eigene Arbeit nicht prüfen konnte. Governance-Kanten gehören ins Schema. Scaffolding-Kanten gehören in die Abfragen, wo man sie löschen kann.
Lesbarkeit und Fähigkeit driften auseinander
Die Nachvollziehbarkeit steckt in den Kanten, weil die Kanten der einzige Teil des Systems sind, den man lesen kann, ohne ihn auszuführen. Die Fähigkeit steckt in den Knoten, weil dort die Modelle sitzen. Beides bewegt sich in entgegengesetzte Richtungen: Die Kanten werden mit besserem Tooling lesbarer, die Knoten mit besseren Modellen undurchschaubarer. Graph Engineering heißt, diese beiden absichtlich auseinanderzuhalten. Ob der Graph oder das Modell den Kontrollfluss besitzen soll, ist keine Frage mit nur einer Antwort. Für ein Deploy-Gate lautet sie anders als für einen Research-Loop, und die Disziplin, auf die es ankommt, ist nicht das Zeichnen des Graphen, sondern die Entscheidung, Kante für Kante, welches der beiden man gerade vor sich hat.
Aus dem Englischen übersetzt: zum Originalbeitrag