Graph Engineering: Wann KI-Agenten feste Übergaben brauchen  

Wie Agentengraphen Arbeit verteilen, Zustände verwalten und Übergaben technisch verbindlich machen. 

KI-Agenten können Informationen auswerten, Tools aufrufen, Teilergebnisse weitergeben und den nächsten Arbeitsschritt anstoßen. Sobald ein Ablauf mehrere Agenten, Prüfinstanzen und Rollen verbindet, entstehen neue Anforderungen.

So ein Prozess kann in der Theorie zwar sauber aussehen, aber im Betrieb trotzdem an der entscheidenden Prüfung vorbeilaufen. Beispielsweise wenn die Prüfung durch den Reviewer zwar vorgesehen ist, der Agent trotzdem aber das nächste Tool aufruft, ohne dass jemand sein Ergebnis geprüft oder die Aktion freigegeben hat.  

Genau hier setzt Graph Engineering an. Es ordnet Agenten, Tools, Regelprüfungen und Menschen in einem Ablauf so an, dass die Runtime, also die Software, den nächsten Schritt erst ausführt, wenn die vorgesehene Prüfung bestanden oder eine Freigabe erteilt wurde. 

Die Architekturidee dahinter ist nicht neu. Sie knüpft an bekannte Workflows, Agent-Loops und Harness Engineering an. Was sich verändert hat, ist der Druck: Je mehr Agenten echte Aktionen in echten Systemen auslösen, desto klarer müssen Übergaben, Rollen und Rückwege definiert sein.

Was Graph Engineering bedeutet 

Graph Engineering beantwortet zwei Architekturfragen: Wie wandert Arbeit durch einen KI-gestützten Prozess? Und welche Entscheidung oder Bedingung löst den nächsten Schritt aus? 

Der Begriff Graph wird auf zwei Ebenen verwendet. Innerhalb eines einzelnen Agenten kann er dessen Agent-Loop beschreiben, also einen wiederkehrenden Arbeitsablauf. Ein Agent kann Informationen prüfen, bei Bedarf Tools aufrufen und Ergebnisse erneut bewerten, bevor er den nächsten Schritt ausführt oder die Aufgabe abschließt. In diesem Beitrag geht es vor allem um die weitere Ebene, welche die Zusammenarbeit mehrerer Agenten und anderer Arbeitsschritte in einem gemeinsamen Prozess beschreibt. 

Bei Exxeta ordnen wir Graph Engineering als Teil von Harness Engineering ein. Graph Engineering steuert Rollen, Zustände und Übergaben zwischen Arbeitsschritten. Harness Engineering gestaltet die Arbeitsumgebung mit Tools, Rechten, Tests und Rückmeldungen sowie verbindlichen Kontrollen innerhalb der Knoten und an ihren Übergaben. Ein Graph wird selbst Teil des Harness, sobald seine Kanten Prüfungen oder Freigaben erzwingen. 

Der Begriff Agentengraph bezieht sich auf seine Darstellung als Graph, also als Netz aus Knoten und Kanten. Ein Knoten, auch Node genannt, ist ein Arbeitsschritt. Das kann ein KI-Agent, ein Tool-Aufruf, Regelcode oder eine menschliche Freigabe sein. Kanten verbinden diese Arbeitsschritte und bilden Rückwege oder Abzweigungen ab. Der gemeinsame State ist die Datenstruktur, in der der Vorgang seine Fallinformationen, Zwischenergebnisse, Freigaben und Rückgabegründe festhält. 

Ein Knowledge Graph erfüllt eine andere Aufgabe. Er speichert Wissen als Entitäten und Beziehungen. Ein Agentengraph organisiert die Ausführung von Arbeit und die dazugehörigen Entscheidungen. 

Welche Engineering-Ebene beantwortet welche Frage? 

Damit Verantwortlichkeiten und Kontrollen nicht ineinanderlaufen, lohnt sich der Blick auf die unterschiedlichen Ebenen eines Agentensystems: 

• Prompt Engineering formuliert Auftrag und Ziel des Modells.  

• Context Engineering liefert die Informationen, also die Daten, Regeln und Quellen, die ein Agent für die Aufgabe braucht.  

• Harness Engineering gestaltet die Arbeitsumgebung innerhalb der Knoten und an ihre Übergaben mit Tools, Rechten, Tests und Rückmeldungen.  

• Loop Engineering steuert, wie ein Agent handelt und seine Arbeit bis zum Abschluss korrigiert.  

• Graph Engineering organisiert, wer wann mit wem zusammenarbeitet, also die Rollen, Zustände und Übergaben zwischen den Arbeitsschritten. 

Diese Ebenen greifen ineinander. Ein Agentengraph braucht einen klaren Auftrag, passenden Kontext und ein Harness, das die Arbeit in jedem Knoten prüfbar macht. 

Wie wird eine Übergabe verbindlich? 

Bei einer Übergabe zwischen Arbeitsschritten gibt ein einzelner Knoten sein Ergebnis zusammen mit einem Status an den State weiter, die gemeinsame Datenstruktur des Vorgangs. In einem verbindlichen Graphen wertet die Runtime diesen State gegen die an den Kanten hinterlegten Bedingungen aus und lässt nur zulässige Übergaben zu.  

Eine Übergabe wird verbindlich, wenn der Folgeschritt einen eindeutig definierten Status voraussetzt. Die Prüfinstanz kann Regelcode, ein weiterer Agent oder eine fachlich verantwortliche Person sein. Sie wirkt als Kontrollpunkt, wenn ihr Prüfergebnis im State gespeichert ist und die Runtime den Vorgang an der nächsten Kante abhängig davon anhält, zurückführt oder weiterleitet.  

Nur die zuständige Prüfinstanz darf den Freigabestatus setzen. Der ausführende Agent darf weder diese Freigabe selbst erzeugen noch die gesperrte Aktion über einen anderen Weg auslösen. Ein verbindlicher Ablauf garantiert noch keine fachlich richtigen Ergebnisse. Dafür braucht es geeignete Prüfungen. 

Ein praktisches Beispiel ist die Änderung von Bankdaten: 

1. Eine Person beantragt die Änderung. Ein erster Knoten erfasst die Anfrage und ordnet sie dem passenden Falltyp zu.  

2. Im zweiten Knoten prüft Regelcode Pflichtfelder, Berechtigungen und Grenzwerte. Fehlen Angaben oder schlägt eine Prüfung fehl, setzt dieser Knoten den Status auf „Rückfrage“.  

3. Die Runtime führt den Vorgang über eine Rückkante zurück. Eine Rückkante ist die Verbindung zu einem früheren Arbeitsschritt, in dem die fehlenden Angaben ergänzt oder der Fehler korrigiert werden kann. In diesem Beitrag bezeichnen wir diese technisch erzwungene Rückführung als Backpressure: Ein abgelehntes Ergebnis geht zur Bearbeitung zurück, während der nächste Schritt gesperrt bleibt. 

4. Erst wenn die Regelprüfung den Status auf „zur Freigabe“ setzt, folgt ein Human Gate, also eine menschliche Freigabe als technisch erzwungene Prüfstelle. Die fachlich verantwortliche Person prüft den Fall und setzt den Status auf „freigegeben“ oder „Rückfrage“. Die Runtime erzwingt diese Entscheidung nicht selbst. Sie blockiert die Änderung, bis einer dieser zulässigen Status im State steht. 

5. Nur bei „freigegeben“ führt die Runtime über die entsprechende Kante zur Änderung der Bankdaten. Die Freigabe ist damit Teil der technischen Bedingung für den nächsten Schritt. 

Wann passt ein Graph besser als ein einzelner Agent? 

Ein einzelner Agent ist der bessere Start, wenn der Lösungsweg offen ist, etwa bei einer Recherche zu einem unbekannten Thema oder einer Fehlersuche ohne klare Spur. Ein Agentengraph passt zu wiederkehrenden Abläufen mit festen Stationen, Prüfpflichten, Berechtigungen oder Freigaben. 

Jeder zusätzliche Node erzeugt eine weitere Übergabe, die das Team begründen und prüfen muss. Unter der Annahme, dass zehn unabhängige Schritte jeweils zu 90 Prozent korrekt sind, liegt die Erfolgswahrscheinlichkeit der gesamten Kette bei rund 35 Prozent. Die Rechnung beschreibt keine realen Agentensysteme. Sie zeigt jedoch, warum jeder Node einen konkreten Auftrag, eigene Rechte oder ein eigenes Prüfkriterium braucht. 

Die folgende Entscheidungshilfe ordnet typische Prozesssignale ein. Der Vorteil eines Agentengraphen liegt in der expliziten Koordination mehrerer Stationen. 

Die Knoten begrenzen Berechtigungen nicht allein. Runtime, Tools und Zielsysteme müssen diese Berechtigungen technisch durchsetzen. 

Welche Prozesse eignen sich als Einstieg? 

Geeignet sind Prozesse, deren Rollen, Datenquellen und Freigaben fachlich bereits getrennt sind. 

• Stammdatenänderung:
  Anliegen zuordnen → Daten abrufen → Voraussetzungen prüfen → Aktion freigeben → Änderung ausführen → Ergebnis bestätigen. 

• Regelmäßiges Reporting:
  Daten aus mehreren Quellen parallel prüfen → Kennzahlen zusammenführen → Bericht erstellen → Quellenreview → veröffentlichen. Weichen Quelle, Zeitraum oder Kennzahl voneinander ab, führt der Ablauf in das Quellenreview zurück. 

• Änderungsfreigabe in der Softwareentwicklung:
  Analyse → Tests → Security-Check → Review → Freigabe → Deployment. 

Workflow-Werkzeugen wie n8n, Power Automate oder Airflow bilden solche Strukturen aus Arbeitsschritten und Übergaben ab. Zieht ein Sprachmodell in einen dieser Knoten ein, sollten Teams abhängig vom Risiko einen definierten Ausgangskontrollpunkt und Gegenkontrolle im Knoten vorsehen. So prüfen sie, ob die Übergaben auch bei fehlerhaften oder unvollständigen Ergebnissen nachvollziehbar bleiben. 

Welche Graph-Struktur passt zu einem Prozess? 

Für diesen Beitrag nutzen wir drei Strukturmuster. Sie unterscheiden sich darin, wer den Ablauf plant und ob die Runtime die Übergaben verbindlich durchsetzt. In realen Systemen können sich diese Muster innerhalb eines Graphen verbinden. 

Behavioral Graphs geben dem Agenten Spielraum 

Bei einem Behavioral Graph entscheidet der Agent beim Routing selbst, welcher Schritt folgt. Für offene Aufgaben reicht häufig zunächst ein einzelner Agent mit gutem Harness. Ein Behavioral Graph wird sinnvoll, wenn mehrere Arbeitsschritte zusammenwirken, das Routing aber bewusst beim Agenten bleibt. Ein Research-Agent kann etwa eine neue regulatorische Fragestellung untersuchen und auf Basis seiner Funde weitere Quellen oder Fachgebiete einbeziehen. Das Team definiert Budget, Tool-Berechtigungen und Abbruchkriterien. Runtime, Tools und Zielsysteme müssen diese Grenzen technisch durchsetzen. 

Structural Graphs machen Übergaben verbindlich 

Beim Structural Graph legt das Team die Übergaben und Bedingungen im Code fest. Die Runtime lässt den nächsten Schritt nur zu, wenn die vorgesehenen Prüfungen und Freigaben im State als erfüllt hinterlegt sind. Das passt zu wiederkehrenden Prozessen mit klaren Rollen und prüfbaren Zwischenergebnissen. Bei einer Stammdatenänderung durchläuft der Fall Identitätsprüfung, Regelcheck, Fachfreigabe und Ausführung. Der von der Prüfung gesetzte Status entscheidet, ob der Vorgang fortgesetzt oder über eine Rückkante zurückgeführt wird. 

Hybrid Graphs machen individuell erstellte Abläufe verbindlich 

Beim Hybrid Graph erstellt das Modell für einen Einzelfall selbstständig einen Graphen. Es legt die nötigen Arbeitsschritte, Kanten und Bedingungen passend zum Use Case fest. Sobald dieser Graph erstellt ist, sind die zulässigen Übergaben festgelegt. Die Runtime führt ihn verbindlich aus; bedingte Abzweigungen und Schleifen folgen dann den Regeln des erzeugten Graphen. Das eignet sich für komplexe Fälle mit wechselndem Ablauf, etwa Dynamic Workflows in Claude Code. Ein verbindlicher Ablauf garantiert auch beim hybriden Graphen noch keine fachlich richtigen Ergebnisse. Dafür braucht es geeignete Prüfungen. 

Wie setzen Teams Agentengraphen produktionsreif auf? 

Vor dem ersten Code klären Fachbereich, Architektur und Engineering gemeinsam vier Artefakte. Sie machen aus einem Ablaufbild eine umsetzbare Architektur. 

• Prozesskarte: Rollen, Entscheidungen, Freigaben und Fehlerwege 

• Node-Verträge: Eingabe, Ausgabe, Berechtigung, Zuständigkeit und Prüfkriterium 

• State-Schema: Zulässige Statuswerte, Eigentümerschaft und Datenklassifizierung  

• Evaluierungsplan: Kriterien für Qualität, Kosten und Eskalationen 

Lassen sich Status und Übergaben nur im Freitext beschreiben, braucht das State-Schema mehr Präzision. Es definiert, welche Zustände zulässig sind, wer sie setzt und welcher nächste Schritt daraus folgt. So bleibt ein Vorgang auch nach Pause, Rückfrage oder Rücksprung nachvollziehbar. 

Warum bleibt die Architekturfrage wichtiger als der Begriff? 

Graph Engineering erhielt im Juli 2026 durch eine Diskussion über Agent-Loops und Graphen neue Aufmerksamkeit. Kurz darauf ordnete LangChain den Begriff als Namen für eine Praxis ein, die bereits länger existiert. Die technische Idee ist damit älter als das Schlagwort. 

Mehr Struktur ist kein Qualitätsbeweis. Kann ein einzelner Agent eine Aufgabe mit passendem Kontext und klaren Prüfungen bearbeiten, schaffen zusätzliche Knoten vor allem weitere Übergaben. Teams sollten einen Graphen deshalb nur ergänzen, wenn er Zuständigkeiten, Rechte oder Kontrollen tatsächlich klarer macht. 

Für die Praxis genügt ein einfacher Prüfweg. Teams wählen zuerst einen wiederkehrenden Prozess, bei dem Zuständigkeiten, Rechte oder Freigaben sichtbar auseinanderfallen. Sie beschreiben danach jeden Knoten mit Eingabe, Ausgabe und zulässigem Status. Zuletzt legen sie fest, an welchen Übergaben die Runtime stoppen, zurückspringen oder einen Menschen einbeziehen muss. 

So wird aus der Diskussion um Graph Engineering eine überprüfbare Architekturentscheidung. Bei KI-gestützten Prozessen mit mehreren Arbeitsschritten entscheiden Fragen nach Ablauf, Verantwortung und Rückweisung über die Übergaben. Exxeta unterstützt dabei, den bestehenden Workflow zu analysieren, den kleinsten sinnvollen Graphen zu entwerfen und ihn mit realen Fällen zu evaluieren.