Graph Engineering ist die vorerst letzte Stufe in der Ablaufsteuerung von KI-Systemen. Mit Prompt Engineering hat das kaum noch etwas zu tun.

Die Erzeugung und Optimierung KI-basierter Ergebnisse hat innerhalb einer nur sehr kurzen Zeitspanne eine steile Entwicklungskurve genommen. Zusammen mit den Tools und den KI-Modellen haben sich auch die eingesetzten Techniken zu deren Bedienung gewandelt. Nachdem zunächst das Prompt Engineering im Mittelpunkt stand, folgten mit dem Context Engineering, dem Harness Engineering und dem Loop Engineering weitere Schritte. Die vorerst letzte Stufe in dieser Evolution ist das Graph Engineering.

Abbildung: Die 5 Evolutionsstufen des KI-Engineerings

Stufe 1: Prompt Engineering

Beim Prompt Engineering geht es darum, die Eingabe an ein KI-System so zu formulieren, dass die erzeugten Ergebnisse möglichst nahe an den gewünschten Resultaten liegen. 

Few-Shot-Beispiele, Rollenanweisungen und Chain-of-Thought-Instruktionen richten ein allgemeines Modell auf eine konkrete Aufgabe aus. Die Annahme dahinter: Wer gut genug formuliert, bekommt gute Ergebnisse.

Praxisbeispiel

Ein Support-Team klassifiziert eingehende Tickets. Das Ticket geht zusammen mit der Anweisung an das Modell, den Ton als positiv, negativ oder neutral einzustufen und die Einstufung in einem Satz zu begründen. Dabei geht es lediglich um einen Aufruf und eine Antwort ohne Zwischenschritt. Für Stimmungsanalysen, Textzusammenfassungen oder das Umformulieren von Produktbeschreibungen reicht das bis heute.

Die Grenze des Prompt Engineerings zeigt sich, sobald mehrere Schritte zusammenkommen. Soll das System zum Beispiel für ein Ticket zusätzlich die Fehlerdatenbank abfragen, den Fall einer Prioritätsstufe zuordnen und eine Antwort entwerfen, muss ein einziger Prompt Kontext, Anweisungen und Ablauflogik gleichzeitig unterbringen. Die Aufmerksamkeit des Modells verteilt sich dabei, und die Ergebnisse werden unzuverlässiger. Komplexe Aufgaben verlangen Zerlegung, und Zerlegung erzeugt Ketten von Modellaufrufen.

Stufe 2: Context Engineering

Die nächste Stufe ist das Context Engineering. Es sieht sowohl KI-Systeme als auch das verfügbare Informationsökosystem als zu optimierende Komponenten an: Das KI-Modell arbeitet wie ein Prozessor, das Kontextfenster wie ein knapper Arbeitsspeicher. Context Engineering kümmert sich darum, was in diesem Speicher landet und was draußen bleibt. Die Frage verschiebt sich von der Formulierung zur Informationsarchitektur um das Modell herum.

Andrej Karpathy hat Context Engineering so beschrieben:

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.” Dazu gehören zum Beispiel Aufgabenbeschreibungen, Erklärungen, Beispiele, Daten, die auch multimodal sein können (auch Bilder, Videos etc.), Statistiken und historische Daten.

Größere Kontextfenster sorgen nicht automatisch für bessere Ergebnisse. Bei zu vielen Informationen gehen wichtige Signale im Rauschen unter. Zwei Gegenmittel haben sich etabliert. Progressive Disclosure gibt Informationen erst frei, wenn der aktuelle Arbeitsschritt sie braucht. Context Backpressure komprimiert den Kontext, sobald das Token-Budget knapp wird.

Praxisbeispiel

Eine Rechtsabteilung prüft Lieferverträge auf Haftungsklauseln. Statt 300 Seiten in das Modell zu laden, sucht ein semantisches Retrieval gezielt die passenden Paragraphen. Das Modell bekommt genau diesen Abschnitt, ein Referenzbeispiel für eine gültige Klausel und eine feste Bewertungsrubrik. Der gefilterte Kontext hebt die Trefferquote und drückt die Zahl erfundener Verweise.

Stufe 3: Harness Engineering

Während Context Engineering sich um den Input kümmert, ordnet der sogenannte Harness (englisch für Gurtwerk oder Geschirr) den Ablauf der Verarbeitung. Gemeint ist eine Schicht, die wie ein Betriebssystem um das Modell herum liegt: Sie verwaltet den Abruf von Werkzeugen, führt Code in abgeschotteten Umgebungen aus und setzt Sicherheitsregeln durch. Das Ziel dabei ist, aus einer wahrscheinlichkeitsbasierten Ausgabe eine kontrollierte Handlung zu machen.

Terminalbasierte Systeme wie OpenDev arbeiten mit einer mehrschichtigen Sicherheitsarchitektur: Leitplanken auf Prompt-Ebene, schemabasierte Werkzeugfreigaben, ein Berechtigungssystem zur Laufzeit, Validierung auf Werkzeugebene und eigene Hooks im Lebenszyklus.

Abbildung: Sessions und LLM Pool in OpenDev

Ein bekanntes Problem langer Sitzungen ist der “Context Rot”: Umfangreiche Werkzeugausgaben überlagern die eigentliche Aufgabe. Fortgeschrittene Harness-Systeme verschieben das Gedächtnis deshalb in ein virtualisiertes Dateisystem. Der sogenannte Ralph Loop spielt die ursprüngliche Absicht in ein bereinigtes Kontextfenster zurück, damit ein Agent seine Aufgabe über Stunden hinweg nicht aus den Augen verliert. Dabei kann die KI in einer Endlosschleife Aufgabe für Aufgabe abarbeiten und erhält immer wieder ein sauberes Kontextfenster. Stabile Prefixe halten dabei Systemanweisungen und Historie im Cache und senken Latenz und Token-Kosten.

Abbildung: Ralph Loop bei KI-Systemen.

Praxisbeispiel

Ein Coding-Agent soll ein Deployment-Skript reparieren. Er entscheidet, einen Shell-Befehl auszuführen. Der Harness fängt den Aufruf ab, prüft ihn gegen die hinterlegten Richtlinien, blockiert Löschkommandos, startet den Rest in einem isolierten Docker-Container und gibt nur die gekürzte Ausgabe oder die Fehlermeldung an das Modell zurück. Das Modell sieht nie die Maschine, sondern immer nur das, was der Harness durchlässt.

Stufe 4: Loop Engineering

Auf der Harness-Infrastruktur setzt die Schleife auf und damit auch das Loop Engineering: Der Agent durchläuft dieselben Phasen immer wieder: Kontext beobachten, nächste Aktion planen, Werkzeug ausführen, Ergebnis prüfen. Dieses ReAct-Muster brachte die ersten wirklich autonomen Agenten hervor.

Praxisbeispiel

Ein KI-Rechercheagent soll einen Marktreport zu Wärmepumpen erstellen. Er sucht, liest eine Herstellerseite, merkt, dass Preisdaten fehlen, startet eine neue Suche, liest weiter. Schritt folgt auf Schritt, bis der Datensatz vollständig ist. Für lineare Recherchen funktioniert das gut.

Schleifen sind zyklisch und sequenziell, der gesamte Kontrollfluss hängt an einem einzigen Punkt. Bei längeren Aufgaben bleiben Agenten in Fehlerschleifen hängen oder verlieren ihren ursprünglichen Plan. Mehrere Spezialisten parallel arbeiten zu lassen, ist im Schleifenmodell umständlich. Und eine menschliche Freigabe lässt sich kaum einbauen, ohne den ganzen Ablauf anzuhalten.

Stufe 5: Graph Engineering

Graph Engineering bricht die Schleife auf und beschreibt den Arbeitsablauf als gerichteten Graphen. Ein Knoten kann ein LLM-Agent sein, eine gewöhnliche Python-Funktion, ein Router, ein Aggregator oder eine menschliche Prüfinstanz. Die Kanten legen fest, wer wann von wem etwas bekommt. Die Topologie eines Multi-Agenten-Systems trennt sich damit sauber von der Logik innerhalb der einzelnen Knoten. Der Begriff des Graph Engineerings hat sich Mitte 2026 in der Branche als Bezeichnung für skalierbare Agentenarchitekturen durchgesetzt.

Praxisbeispiel

Ein Team lässt Software-Updates automatisiert vorprüfen. Der Graph arbeitet wie ein Projektteam mit klarer Rollenverteilung: Ein Planer-Knoten schneidet die Aufgabe zu, ein Worker-Knoten schreibt den Code. Danach verzweigt der Fluss in drei parallel laufende Reviewer für Sicherheit, Logik und Stil. Ein Synthesizer führt die drei Bewertungen zusammen, ein deterministisches Gate entscheidet über die Freigabe. Fällt die Prüfung negativ aus, läuft der Fluss über eine Rückkopplungskante zum Worker zurück.

Abbildung: Beispiel für einen KI-Graphen

Genau diese Rückkopplungskante zeigt einen der praktischen Vorteile des Graph Engineerings. Typisierte Kanten transportieren gezielt Informationen: Eine Kante mit dem Typ „Security_Feedback“ sagt dem Worker, aus welcher Richtung die Kritik kommt, und das Modell kann diese Information in seinen nächsten Versuch einbeziehen.

Mit wachsender Knotenzahl kann allerdings ein Kostenproblem entstehen, weil Systeme den Graphen gleichförmig abarbeiten und teure Token auch in nebensächliche Teilaufgaben stecken.

Eine wichtige Aufgabe kommt der sogenannten Adaptive Goal-aware Attention Orchestration (AGAO) zu: Sie gewichtet Knoten nach semantischer Nähe zum Nutzerziel, nach ihrer Stellung im Graphen und nach verfügbaren Ressourcen und lenkt Rechenleistung auf die kritischen Pfade.

Vier Bedingungen, die ein Graph erfüllen muss

Damit ein System als Graph-orchestriert gilt, müssen vier Punkte zusammenkommen:

• Explizite Struktur: Der Graph liegt als benanntes, auswertbares Objekt aus Knoten und Kanten vor. Ein Kontrollfluss, der sich aus freier Konversation zwischen Agenten ergibt, zählt nicht.
• Trennung von Struktur und Inhalt: System-Prompts und Instruktionen werden unabhängig von der Topologie verwaltet. Der Knoten ist der Träger, der Inhalt kommt zur Laufzeit hinein.
• Ausführbare Semantik: Eine Runtime interpretiert den Graphen, steuert Zustandsübergänge, Verzweigungen und Fehlerbehandlung. Ein Diagramm auf einer Folie reicht nicht.
• Graph als eigenständiges Artefakt: Er wird versioniert, im Repository verwaltet, in Batch-Läufen getestet und schrittweise verbessert.

Die fünf Engineering-Stufen im Überblick

Tabelle 1: Die 5 Engineering-Stufen im Überblick

Wofür sich Graph Engineering lohnt

Der Aufwand für Graph Engineering rechnet sich dort, wo drei Bedingungen zusammenkommen: 

• Die Aufgabe lässt sich in Teilschritte zerlegen.
• Fehler haben gravierende Folgen.
• Jemand muss den Ablauf später nachvollziehen können. 

Genau das trifft vor allem auf regulierte Umgebungen zu.

Governance in Unternehmen: Symbolic-in-the-Loop

In stark regulierten Branchen kommt es beim Einsatz von KI vor allem auf Steuerbarkeit und Kontrolle an. Budgetgrenzen, rollenbasierte Zugriffsrechte und menschliche Freigaben lassen sich als Knoten direkt in die Architektur einweben.

Einen Schritt weiter geht das Symbolic-in-the-Loop-Verfahren. Hier steht ein geprüfter Knowledge Graph am Ende einer KI-Pipeline und arbeitet als deterministischer Kontrollknoten. 

Beispiel: Ein Beschaffungsagent erzeugt eine Bestellung, ein Router-Knoten leitet den Entwurf an einen symbolischen Finanzgraphen weiter. Überschreitet die Bestellung das freigegebene Budget oder verstößt sie gegen eine Geschäftsregel, blockiert der Graph die Zustandsänderung. Die Prüfung läuft ohne menschliches Zutun.

Branchen, die von Graph Engineering besonders profitieren

Finanzwesen und Wirtschaftsprüfung

Prüfer stellen Fragen wie: Welche Kreditorenkonten sind gegenüber dem Vorjahr um mehr als 20 Prozent gewachsen? Keine einzelne Textpassage in einem Jahresabschluss enthält die Antwort auf diese Frage. Graphenbasiertes Retrieval modelliert Konten und Transaktionskategorien als Knoten und erlaubt aggregierte Sichten über das gesamte Hauptbuch.

Gesundheitswesen

Bei elektronischen Patientenakten steht der Datenschutz an erster Stelle. Cloud-Modelle scheiden deshalb oft aus rechtlichen Gründen aus. GraphRAG-Systeme lassen sich auch lokal betreiben: Offene Modelle wie Qwen 2.5 in der 7B-Variante oder Llama 3.1 mit 8B laufen über Ollama auf Consumer-Hardware und extrahieren aus bestehenden Akten brauchbare Knowledge Graphen. Lokale Retrieval-Modi drücken die Latenz, die Zahl erfundener Angaben sinkt.

Software- und Technologieunternehmen

Systeme wie OpenDev oder SWE-agent orchestrieren ganze Entwicklungszyklen: Repository analysieren, Fehler eingrenzen, Code patchen und Unit-Tests durchführen. Weil der Graph seinen Zustand nach jedem Knoten sichert, übersteht der Prozess Abbrüche. Bricht die Verbindung weg, setzt das System am letzten stabilen Zustand wieder auf.

Kundenservice und Backoffice

Auch außerhalb hochregulierter Felder zahlt sich eine auf Graphen basierende Struktur aus, sobald ein Vorgang verzweigt. Ein Reklamationsprozess mit Prüfung der Kaufhistorie, die Bewertung eines Anspruchs, das Erstellen eines Retourenlabels und die Freigabe ab einem bestimmten Warenwert bestehen aus Knoten mit klaren Übergaben. Lediglich der Freigabeknoten ist ein Mensch, alles davor läuft automatisch.

Wer damit arbeitet

Mit der Verlagerung vom reinen Prompt zum Graph Engineering verschieben sich auch die Rollen. Drei Profile haben sich herausgebildet:

• KI-Systemarchitekten entwerfen die Topologie, setzen Sicherheitsgrenzen und legen fest, wo der Fluss verzweigt und wo er wieder zusammenläuft.
• Data- und Knowledge-Engineers extrahieren Entitäten, bauen unternehmensweite Ontologien auf und stellen interne Datenbanken über standardisierte Schnittstellen bereit.
• MLOps- und Reliability-Engineers kümmern sich um Beobachtbarkeit, um das Routing zwischen verschiedenen Modellen und um Wiederanlauf nach Ausfällen.

In der Praxis übernimmt oft eine Person mit Erfahrung im Software Engineering die Topologie, während die Fachabteilungen die Regeln liefern, die in den deterministischen Knoten landen.

Werkzeuge, Modelle und Protokolle

Frameworks

Ein typisches Framework für die Arbeit mit Graphen ist LangGraph von LangChain. Es modelliert den Kontrollfluss als Graph, erlaubt zyklische Kanten und sichert den globalen Zustand nach jedem Durchlauf. Für Prozesse mit iterativem Feedback und Freigabeschritten ist das derzeit eine naheliegende Wahl. 

DSPy geht den umgekehrten Weg und verankert den Graphen im Programmcode: Signaturen legen fest, was ein Knoten aufnimmt und was er ausgibt, ein Compiler schreibt die Prompts dazu. 

LlamaIndex Workflows steuert die Pipeline über typisierte Ereignisse zwischen asynchronen Python-Funktionen und spielt seine Stärke bei verzweigten Retrieval-Pipelines mit Re-Ranking aus.

Tabelle 2: KI-Graph-Frameworks (Auswahl)

Modelle: Größe nach Aufgabe

Weil jeder Agent ein eigener Knoten ist, muss nicht überall dasselbe Modell laufen. Teure Spitzenmodelle bleiben den Planungs- und Syntheseknoten vorbehalten, wo Reasoning in mehreren Schritten gefragt ist. Extraktion, Klassifizierung und Formatprüfung übernehmen dagegen kleine Modelle, oft lokal betrieben. Dieses Routing zwischen Modellklassen ist ein wichtiger Kostenhebel der Architektur.

Ein weiterer Vorteil dieses Ansatzes: Sensible Daten können auf lokal betriebenen Modellen verbleiben. Die großen Modelle erhalten allenfalls Metadaten, die sie zum Bearbeiten ihrer Aufgaben benötigen. So kann zum Beispiel Claude Code mit Fable 5 als externer Architekt dienen, der im Bedarfsfall von den lokalen Modellen in Anspruch genommen wird. Dabei werden aber nur Tabellen und Prozesse übergeben, nicht aber die dort abgelegten bzw. verarbeiteten Daten.

Die Rolle von MCP und A2A

Lange musste für jede Kombination aus Modell und Werkzeug ein eigener Konnektor verwendet werden. Das Model Context Protocol, Ende 2024 von Anthropic veröffentlicht, arbeitet dagegen als quelloffener Standard nach dem Client-Server-Prinzip: Ein Agent spricht über JSON-RPC mit MCP-Servern, die drei Arten von Bausteinen anbieten, nämlich Ressourcen, Tools und Prompt-Vorlagen. Ein Knoten im Graph lädt damit zur Laufzeit genau die Werkzeuge, die der aktuelle Schritt braucht, ohne das Kontextfenster mit ungenutzten Definitionen zu füllen.

Während MCP die Verbindung nach unten regelt, kümmert sich das Agent-to-Agent-Protokoll (A2A) um die Übergabe zur Seite: Agenten aus verschiedenen Frameworks finden einander, authentifizieren sich und reichen Teilaufgaben weiter.

Wann der Aufwand nicht lohnt

Das Aufsetzen einer Graph-Struktur kostet Entwurfszeit, Infrastruktur und Testaufwand. Für einen einzelnen Report, eine feste Sequenz ohne Verzweigung oder eine Auswertung, die einmal im Quartal läuft, reicht ein KI-Pipeline mit sauberem Kontext. Sinnvoll wird eine Topologie aus Graphen ab dem Punkt, an dem ein Ablauf verzweigt, an dem Teilergebnisse parallel entstehen sollen oder an dem jemand später belegen muss, warum das System eine bestimmte Entscheidung getroffen hat. 

FAQ: die häufigsten Fragen zu Graph Engineering

Was unterscheidet Graph Engineering vom Prompt Engineering?

Prompt Engineering setzt an der Eingabe an, damit ein Modell in einem einzigen Durchlauf ein möglichst gutes Ergebnis liefert. Die gesamte gedankliche Last liegt beim Modell. Graph Engineering zerlegt den Ablauf in spezialisierte Knoten und verbindet sie über Kanten. Wer wann aufgerufen wird, wie Fehler behandelt werden und was parallel läuft, bestimmt die Architektur. Prompts sind lediglich Parameter innerhalb der einzelnen Knoten.

Ersetzt Graph Engineering das Context Engineering?

Nein, beide arbeiten auf verschiedenen Ebenen. Der Graph beschreibt, wie Agenten und deterministische Werkzeuge zusammenspielen. Context Engineering sorgt dafür, dass jeder einzelne Knoten zum Zeitpunkt seiner Ausführung genau die verdichteten Informationen bekommt, die er braucht. Ein gut entworfener Graph mit schlecht gefüllten Kontext-Fenstern liefert schlechte Ergebnisse.

Worin liegt der Unterschied zwischen Graph of Thoughts und Graph Engineering?

Graph of Thoughts beschreibt eine Suchstrategie des Modells: Es erzeugt intern verschiedene Argumentationsansätze, kombiniert und bewertet sie. Die Knoten sind generierte Gedanken. Beim Graph Engineering bestehen die Knoten aus programmierten Komponenten, etwa Python-Funktionen, API-Aufrufen oder spezialisierten Agenten, die ein Architekt definiert hat. Die Trennlinie verläuft entlang der Frage, wem die Knoten gehören.

Warum reicht klassisches RAG im Unternehmen häufig nicht?

Vektorbasiertes RAG findet Antworten, die als Textstelle in einem Dokument stehen. Für Fragen nach Mustern über einen gesamten Bestand fehlt der passende Anker. GraphRAG baut vorab einen Knowledge Graph, teilt ihn in thematische Cluster, fasst diese zusammen und aggregiert bei einer Anfrage die Teilantworten. Damit werden vergleichende und zeitbezogene Fragen beantwortbar, die vorher ins Leere liefen.

Was ist das Model Context Protocol, und wozu dient es?

MCP ist ein quelloffener Kommunikationsstandard nach dem Client-Server-Prinzip, der die Verbindung zwischen KI-Agenten und externen Werkzeugen oder Datenbanken vereinheitlicht. Statt für jede Kombination einen eigenen Konnektor zu schreiben, tauschen Agent und Server über JSON-RPC Ressourcen, Tools und Prompt-Vorlagen aus. Für Systeme auf Basis von Graphen heißt das: Ein Knoten holt sich zur Laufzeit genau die Werkzeuge, die er gerade braucht.

Braucht Graph Engineering die größten KI-Modelle?

Im Gegenteil, die Architektur verstärkt die Vorteile kleiner Modelle. Ein großes Frontier-Modell plant und synthetisiert, kleine offene Modelle übernehmen Extraktion und Klassifizierung. Komplette GraphRAG-Aufbauten mit 7B- und 8B-Modellen laufen oftmals schon auf Hardware mit 8 GB VRAM.

Ab wann lohnt der Umstieg von einer simplen KI-Agenten-Pipeline  auf einen Graphen?

Drei Kriterien sprechen für eine auf Graphen basierende KI-Architektur: Der Ablauf verzweigt regelmäßig, mehrere Teilaufgaben können parallel laufen, oder das Ergebnis muss später nachvollziehbar begründet werden. Kommt zusätzlich eine menschliche Freigabe ins Spiel, führt kaum ein Weg an einer expliziten Graph-Topologie vorbei.