Graph Engineering für KI-Agenten: Multi-Agent-Loops zuverlässig orchestrieren

Warum wird jetzt über Graph Engineering gesprochen?

Der Ausdruck bekam neue Aufmerksamkeit, nachdem Peter Steinberger auf X fragte: „Are we still talking loops or did we shift to graphs yet?“. Kurz darauf ordnete LangChain die Debatte aus Herstellerperspektive als „3 Years of Graph Engineering with LangGraph“ ein.

Der Name ist neu und nicht standardisiert. Die technische Grundlage ist es nicht. Zustandsautomaten, gerichtete Graphen, bedingtes Routing, Fan-out/Fan-in, Map-Reduce und Workflow-Engines existierten lange vor heutigen LLM-Agenten.

Neu ist vor allem die Granularität eines Knotens. Ein Node kann inzwischen einen vollständigen Agentenlauf mit eigenem Kontextfenster, Werkzeugen und internem Arbeitszyklus kapseln. Der Graph verbindet nicht mehr nur Funktionen oder einzelne Modellaufrufe, sondern mehrere probabilistische Loops mit deterministischen Kontrollen.

Das ist eine relevante Verschiebung, aber kein neues Informatikgesetz. Der Graph macht aus unzuverlässigen Agenten nicht automatisch ein zuverlässiges System. Er macht ihre Übergaben, Abhängigkeiten und Fehlerpfade zunächst nur expliziter.

Was ist Graph Engineering für KI-Agenten?

Graph Engineering ist die Praxis, agentische und deterministische Arbeitsschritte als expliziten, zustandsbehafteten Ausführungsgraphen zu entwerfen, zu prüfen und zu betreiben.

Ein solcher Graph besteht aus vier Grundelementen:

Element	Aufgabe	Beispiele
Node	führt einen begrenzten Arbeitsschritt aus	Funktion, Tool-Aufruf, LLM-Aufruf, Agenten-Loop, menschliche Prüfung
Edge	bestimmt den nächsten Übergang	Sequenz, Bedingung, Delegation, Retry, Abbruch, Eskalation
State	transportiert den prüfbaren Zustand	Eingaben, Artefakte, Status, Budgets, Findings, Fehler
Gate	entscheidet über Fortsetzung oder Stopp	Schema-Check, Test, Rubrik, Freigabe, Kostenlimit

Die Definition bezieht sich auf Ausführungs- und Kontrollflussgraphen. Sie hat nichts mit Knowledge Graphs als Wissensspeicher oder Graph Neural Networks als Modellklasse zu tun.

Ein Agentengraph ist außerdem nicht zwingend ein Directed Acyclic Graph (DAG). Retry-, Review- und Optimierungsschleifen erzeugen Zyklen. Gerade langlebige Agentensysteme benötigen solche Schleifen, müssen sie aber durch Stop-Regeln begrenzen.

Wie unterscheiden sich Loop Engineering und Graph Engineering?

Loop Engineering steuert den iterativen Arbeitszyklus eines Agenten: planen, handeln, Ergebnis prüfen, Kontext aktualisieren und erneut entscheiden. Graph Engineering organisiert die Beziehungen zwischen mehreren solchen Loops sowie deterministischen Schritten und menschlichen Gates.

Die Ebenen bauen aufeinander auf:

Ebene	Zentrale Frage
Prompt Engineering	Welche Instruktion erhält das Modell?
Context Engineering	Welche Informationen stehen im Kontext?
Harness Engineering	Welche Tools, Rechte, Speicher und Feedbacksignale umgeben den Agenten?
Loop Engineering	Wie arbeitet und korrigiert sich ein Agent über mehrere Schritte?
Graph Engineering	Wie werden mehrere Loops, Funktionen und Freigaben verbunden und betrieben?

Graph Engineering ersetzt den Loop nicht. Ein Agenten-Node kann selbst einen zyklischen Loop enthalten. Ein Graph mit schlecht konstruierten Loops verteilt nur schlechte Zwischenergebnisse schneller.

Auch der AI Harness bleibt notwendig. Der Graph beschreibt Topologie und Kontrollfluss. Der Harness setzt Werkzeugzugriffe, Laufzeit, Speicher, Rechte und Sicherheitsgrenzen praktisch um.

Welche Graphmuster sind in Multi-Agent-Systemen sinnvoll?

Nicht jede Aufgabe braucht eine dynamische Agentenorganisation. Häufig reichen wenige bekannte Muster.

Muster	Struktur	Geeignet für	Hauptproblem
Sequenzielle Kette	A → B → C	stabile, abhängige Schritte	unnötige Serialisierung
Router	A → B oder C	klar trennbare Aufgabentypen	falsche Routingentscheidung
Fan-out/Fan-in	A → B/C/D → E	unabhängige Recherche- oder Reviewpfade	Kosten, Duplikate, Widersprüche
Barrier/Join	E wartet auf B, C und D	vollständige Mehrfachprüfung	langsamster Node blockiert den Lauf
First-success	E akzeptiert das erste valide Ergebnis	Fallbacks und Latenzoptimierung	ein frühes schwaches Resultat gewinnt
Orchestrator-Workers	Planer erzeugt Worker dynamisch	offene, parallel zerlegbare Aufgaben	falsche Zerlegung, doppelte Arbeit
Evaluator-Optimizer	Erzeuger ↔ Prüfer	Verbesserung anhand klarer Kriterien	Endlosschleife, Reviewer-Bias
Human Gate	Agent → Freigabe → Aktion	irreversible oder riskante Aktionen	Wartezeit und Betriebsaufwand

Anthropic beschreibt Prompt Chaining, Routing, Parallelization, Orchestrator-Workers und Evaluator-Optimizer als wiederverwendbare Workflow-Muster. Das ist keine universelle Graph-Runtime. Es ist eine Sammlung von Architekturprinzipien, die sich mit Frameworks oder eigener Orchestrierung umsetzen lassen.

Parallelisierung bringt nur dann einen Vorteil, wenn Teilaufgaben tatsächlich unabhängig sind. Anthropics Research-Team berichtet für komplexe Suchanfragen von bis zu 90 Prozent kürzerer Recherchezeit, wenn ein Lead-Agent mehrere Subagenten und parallele Tool-Aufrufe koordiniert. Das ist ein Maximalwert aus einem herstellereigenen Research-System, kein allgemeiner Geschwindigkeitsfaktor für Agentengraphen.

Was zeigen Anthropic und MAST über Multi-Agent-Orchestrierung?

Anthropics internes Research-Eval liefert ein starkes, aber eng begrenztes Herstellersignal. Laut Anthropic übertraf ein System mit Claude Opus 4 als Lead und Claude Sonnet 4 als Subagenten einen einzelnen Claude-Opus-4-Agenten im eigenen Research-Eval um 90,2 Prozent. Der Blogpost nennt dafür weder die genaue Bewertungsmetrik noch Aufgabenzahl, Runs oder Streuung. Als Beispiel beschreibt Anthropic die Suche nach allen Vorstandsmitgliedern der Unternehmen im Information-Technology-Sektor des S&P 500. Daraus folgt nicht, dass Multi-Agent-Systeme bei jeder Aufgabe diesen Vorteil erreichen.

Die Kosten steigen gleichzeitig deutlich. In Anthropics internen Nutzungsdaten verbrauchten Agenten typischerweise etwa viermal und Multi-Agent-Systeme etwa 15-mal so viele Token wie normale Chat-Interaktionen. Parallelität kann also Wandzeit sparen, ohne Geld oder Gesamtrechenaufwand zu reduzieren.

Die unabhängige MAST-Studie betrachtet nicht nur Modellfehler, sondern das Gesamtsystem. Die Forschenden sammelten 1.642 annotierte Traces aus sieben Multi-Agent-Frameworks. Aus einer detaillierten manuellen Teilanalyse von 150 Traces entstand eine Taxonomie mit 14 Fehlermodi in drei Gruppen:

• Probleme im Systemdesign
• Fehlausrichtung zwischen Agenten
• unzureichende Aufgabenverifikation

Die wichtige Erkenntnis: Fehler entstehen nicht nur, weil ein Modell halluziniert. Sie entstehen auch durch unklare Rollen, falsches Routing, unvollständige Übergaben, ungeprüfte Zwischenergebnisse und ungeeignete Abbruchbedingungen.

Wie funktioniert Verifikation in einem Agentengraphen?

Ein zusätzlicher Reviewer-Node ist noch keine verlässliche Qualitätskontrolle. Ein LLM kann auch in frischem Kontext halluzinieren, Anforderungen missverstehen oder Scheinkritik erzeugen. Verifikation muss deshalb auf mehreren Ebenen stattfinden.

Deterministische Checks zuerst

Syntaxprüfung, Schema-Validierung, Tests, Builds, Linter, Hash-Vergleiche und bekannte Geschäftsregeln gehören in deterministischen Code. Ein LLM-Reviewer ist dafür teurer und weniger zuverlässig.

Semantische Reviews mit klarer Rubrik

Offene Ergebnisse wie Rechercheberichte lassen sich nicht vollständig mit Unit-Tests prüfen. Hier kann ein Reviewer Faktenabdeckung, Quellenqualität, Widersprüche und Anforderungstreue anhand einer festen Rubrik bewerten. Anthropic beschreibt für Rechercheausgaben eine LLM-as-a-Judge-Rubrik mit Fakten- und Zitationsgenauigkeit, Vollständigkeit, Quellenqualität und Tool-Effizienz. Separat empfiehlt das Unternehmen bei Agenten, die über viele Turns persistenten Zustand verändern, den korrekten Endzustand statt eines einzigen vorgeschriebenen Ausführungspfads zu bewerten.

Ein frischer Kontext reduziert die Gefahr, dass der erzeugende Agent seine eigenen Annahmen nur bestätigt. Er garantiert aber keine unabhängige Wahrheit. Bei relevanten Claims braucht der Reviewer Zugriff auf Primärquellen und nicht nur auf die Zusammenfassung des vorherigen Nodes.

Human Gates bei hohen Fehlkosten

Zahlungen, Veröffentlichungen, Löschvorgänge, Rechteänderungen und externe Kommunikation sollten vor der Seiteneffekt-Kante eine menschliche Freigabe erhalten. Das Gate muss den konkreten State und die geplante Aktion zeigen. Eine pauschale Frage wie „Fortfahren?“ reicht nicht.

Was braucht ein produktionsreifer Agentengraph?

Ein Diagramm mit Agentennamen ist noch kein Produktionssystem. Die eigentliche Engineering-Arbeit beginnt bei den Übergängen.

Typisierte Verträge statt Prosa-Handoffs

Jeder Node braucht definierte Eingaben, Ausgaben und Statuswerte. Freitext kann zusätzlich enthalten sein, darf aber nicht die einzige Schnittstelle bilden.

{
  "node_id": "security-review",
  "status": "passed",
  "findings": [],
  "evidence": [],
  "artifacts": [],
  "budget": {
    "tokens_used": 0,
    "tool_calls": 0
  }
}

Der nächste Node muss fehlende Felder, einen blockierten Status oder widersprüchliche Evidenz erkennen können. Sonst wird ein unvollständiges Ergebnis als Erfolg weitergereicht.

Externer State und Checkpoints

Der relevante Zustand darf nicht nur im Chatverlauf eines Agenten leben. Er gehört in versionierte Artefakte, Datenbanken oder Checkpoints mit stabilen IDs. LangGraph dokumentiert dafür Persistence und unterbrechbare Ausführung.

Checkpoints ermöglichen Recovery nach Rate Limits, Prozessabbruch oder Toolfehlern. Ohne sie startet ein langer und teurer Lauf wieder am Anfang oder versucht, seinen früheren Zustand aus Prosa zu rekonstruieren.

Idempotente Seiteneffekte

Ein Retry darf keine Bestellung doppelt auslösen, keinen Pull Request mehrfach öffnen und keine Datei unkontrolliert überschreiben. LangGraphs Dokumentation warnt bei Interrupts ausdrücklich vor nicht-idempotenten Operationen, weil ein Node beim Fortsetzen erneut ausgeführt werden kann.

Praktisch bedeutet das: stabile Idempotency Keys, Upserts statt ungeschützter Inserts und Vorabprüfungen vor externen Aktionen.

Tracing und Evals getrennt behandeln

Ein Trace beantwortet, welcher Node mit welchem Modell, Tool und State ausgeführt wurde. Er sollte mindestens Run-ID, Node-ID, Parent-Beziehung, Routingentscheidung, Latenz, Tokenverbrauch, Tool-Aufrufe, Retries, Fehlerklasse und Artefakt-Referenzen erfassen.

Tracing beantwortet aber nicht, ob die Entscheidung fachlich richtig war. Dafür brauchst du Evals auf dem Endzustand und auf kritischen Übergängen. Das OpenAI Agents SDK erfasst beispielsweise LLM-Aufrufe, Tools, Handoffs und Guardrails in Traces; die Qualitätsmetrik musst du trotzdem passend zur Aufgabe definieren.

Harte Budgets und Stop-Regeln

Jeder Lauf braucht Grenzen für Fan-out, Laufzeit, Token, Tool-Aufrufe und Retries. Zusätzlich ist eine No-Progress-Erkennung nötig: Wiederholt ein Optimizer dieselbe Korrektur oder widersprechen sich Reviewer dauerhaft, muss der Graph abbrechen oder an einen Menschen eskalieren.

Wie unterscheiden sich aktuelle Framework-Ansätze?

Die Framework-Wahl entscheidet nicht über die Qualität des Systems. Sie bestimmt vor allem, welche Teile von State, Routing, Persistenz und Tracing du selbst bauen musst.

Ansatz	Orchestrierungsmodell	Stärke	Grenze
LangGraph	zustandsbehafteter Ausführungsgraph	Checkpoints, Interrupts, Human-in-the-loop, deterministische und agentische Nodes	Low-Level-Ansatz; Topologie und Betriebslogik bleiben Entwickleraufgabe
AutoGen GraphFlow	gerichteter Graph mit Sequenz, Parallelität, Bedingungen und Loops	Execution Graph, Message Filtering, Join-Logik	laut offizieller Dokumentation experimentell
Google ADK	Graph-, Template-, dynamische und kollaborative Workflows	Sequence-, Parallel- und Loop-Primitiven unter einem Dach	mehrere Abstraktionsebenen erhöhen den Architekturaufwand
OpenAI Agents SDK	Handoffs oder Manager mit Agents-as-Tools	klare Zuständigkeit und integriertes Tracing	kein primär graphzentriertes DSL
Anthropic-Muster	einfache Komposition aus Routing, Parallelisierung und Evaluator-Loops	frameworkunabhängige Architekturprinzipien	keine universelle Runtime für State und Recovery

LangGraph ist nicht gleich Graph Engineering. Es ist eine mögliche Implementierung. Dasselbe Architekturprinzip lässt sich mit AutoGen, Google ADK, dem OpenAI Agents SDK, Workflow-Engines oder eigenem Code umsetzen.

Wann lohnt sich Graph Engineering?

Ein Graph ist sinnvoll, wenn mindestens eines dieser Kriterien erfüllt ist:

• Teilaufgaben sind wirklich unabhängig und parallelisierbar.
• Unterschiedliche Nodes benötigen getrennte Kontexte, Modelle, Tools oder Berechtigungen.
• Der Prozess läuft lange und muss pausierbar sowie wiederaufnehmbar sein.
• Zwischenergebnisse lassen sich als getrennte Artefakte prüfen.
• Irreversible Aktionen benötigen explizite Freigaben.
• Routing und Recovery müssen nachträglich nachvollziehbar sein.

Breite Recherche ist ein guter Kandidat. Mehrere Worker können unterschiedliche Suchräume bearbeiten, während ein Synthese-Node Widersprüche und Quellenabdeckung prüft. Auch Security-Reviews profitieren von getrennten Prüfperspektiven, sofern Findings durch Tests oder konkrete Evidenz belegt werden.

Für Coding-Aufgaben ist die Lage schwieriger. Gemeinsame Dateien, Architekturentscheidungen und Tests erzeugen starke Abhängigkeiten. Mein Artikel zu KI-Agentenschwärmen zeigt deshalb ebenfalls: Mehr parallele Worker lösen das Integrationsproblem nicht, sondern verschieben es zum Orchestrator.

Wann ist ein einzelner Agent die bessere Wahl?

Baue keinen Graphen, wenn ein einzelner Agent die Aufgabe in einem begrenzten Loop mit guten Tools und objektiven Tests zuverlässig löst. Das gilt besonders für kleine Änderungen, kurze Analysen und stark gekoppelte Teilprobleme.

Auch Anthropic empfiehlt, mit der einfachsten tragfähigen Lösung zu beginnen. Frameworks können Prompts und Responses hinter zusätzlichen Abstraktionen verstecken und dadurch das Debugging erschweren.

Ein Single-Agent-System ist meist besser, wenn:

• alle Teilaufgaben denselben vollständigen Kontext benötigen,
• kaum echte Parallelität vorhanden ist,
• kein belastbares Prüfsignal existiert,
• der wirtschaftliche Aufgabenwert den zusätzlichen Tokenverbrauch nicht rechtfertigt,
• State, Tracing und Recovery noch nicht sauber gelöst sind.

Die richtige Eskalationsreihenfolge lautet: zuerst den einzelnen Modellaufruf verbessern, dann Harness und Loop stabilisieren, anschließend bei nachgewiesenem Bedarf einen Graphen ergänzen.

Welche Grenzen hat Graph Engineering?

Fehler können sich verstärken

Ein plausibles, falsches Zwischenergebnis wird downstream schnell zur vermeintlichen Tatsache. Strukturierte Verträge erkennen fehlende Felder, aber keine überzeugend formulierte Falschinformation. Dafür sind Quellenprüfung, unabhängige Evidenz und End-State-Evals notwendig.

Aggregation ist selbst ein Fehlerpunkt

Ein Synthese-Node kann Widersprüche glätten, Minderheitsbefunde verlieren oder einen Konsens erfinden. Fan-in braucht deshalb Regeln für Konflikte, Quellenpriorität und ungelöste Unsicherheit. „Mehrheit gewinnt“ ist bei Faktenfragen kein ausreichendes Verfahren.

Reviewer skalieren auch False Positives

Ein Reviewer, der zwingend Probleme finden soll, wird häufig welche melden. Mehr Review-Nodes bedeuten daher nicht automatisch höhere Qualität. Rubrik, Kalibrierung und Stichproben gegen menschliche Urteile sind wichtiger als die Zahl der Prüfer.

Parallelität spart nicht automatisch Kosten

Fan-out reduziert bei geeigneten Aufgaben die Wandzeit. Gleichzeitig wachsen Kontextduplikation, Tool-Aufrufe, Synthese und Review. Der entscheidende Messwert ist nicht die Laufzeit eines Nodes, sondern Qualität pro Gesamtkosten und die Fehlkosten des vollständigen Runs.

Graphen erzeugen Betriebs- und Migrationsaufwand

Topologie, State-Schema und Node-Verträge ändern sich. Laufende Instanzen müssen nach einem Deployment entweder mit der alten Version fortgesetzt oder kontrolliert migriert werden. Ohne Versionierung kann ein Checkpoint nach einer Änderung unlesbar oder semantisch falsch werden.

Observability ist keine Evaluation

Ein perfekter Trace kann einen fachlich falschen Lauf vollständig dokumentieren. Beobachtbarkeit ist Voraussetzung für Debugging. Sie ist kein Qualitätsbeweis.

FAQ: Häufig gestellte Fragen zu Graph Engineering

Ist Graph Engineering nur ein neues Wort für LangGraph?

Nein. LangGraph ist ein Framework. Graph Engineering bezeichnet allgemeiner das Entwerfen und Betreiben expliziter Ausführungsgraphen aus Agenten, Code, Tools und Freigaben.

Ist Graph Engineering dasselbe wie ein DAG?

Nein. Ein DAG enthält keine Zyklen. Agentensysteme nutzen häufig Retry-, Review- und Optimierungsschleifen und sind deshalb oft gerichtete zyklische Graphen.

Ersetzt Graph Engineering Loop Engineering?

Nein. Graphen verbinden mehrere Loops und kontrollieren ihre Übergänge. Der interne Arbeitszyklus eines Agenten bleibt bestehen.

Macht ein Multi-Agent-Graph Aufgaben automatisch schneller?

Nein. Nur unabhängig parallelisierbare Teilaufgaben können Wandzeit sparen. Joins, Synthese, Retries und gemeinsame Abhängigkeiten erzeugen zusätzlichen Overhead.

Macht ein Multi-Agent-Graph Aufgaben billiger?

Nicht automatisch. Kleinere Modelle können einzelne Nodes verbilligen, während mehr Agenten, Reviews und Retries den Gesamtverbrauch erhöhen. Gemessen werden müssen Endqualität, Wandzeit und Gesamtkosten gemeinsam.

Reicht ein zweiter Agent zur Verifikation?

Nein. Ein frischer Reviewer-Kontext kann Selbstbestätigung reduzieren, aber ebenfalls falsche Findings erzeugen. Deterministische Tests, klare Rubriken und Primärquellen bleiben notwendig.

Welche Metriken sollte ein Produktionsgraph erfassen?

Wichtig sind Erfolgsrate, End-State-Qualität, Laufzeit, Gesamtkosten, Tokenverbrauch, Toolfehler, Retries, Routingfehler, Reviewer-Fehlalarme und menschliche Eskalationen.

Wann sollte ich keinen Agentengraphen bauen?

Wenn ein einzelner Agent die Aufgabe mit gutem Harness und objektiver Verifikation zuverlässig löst oder wenn die Teilaufgaben denselben Kontext und Zustand stark teilen.

Fazit

Graph Engineering ist kein Ersatz für gute Prompts, sauberen Kontext, einen belastbaren Harness oder funktionierende Agenten-Loops. Es lohnt sich, wenn mehrere unabhängige Loops, deterministische Gates und menschliche Freigaben mit explizitem State orchestriert werden müssen. Meine Empfehlung: Baue zuerst einen zuverlässigen einzelnen Loop. Skaliere erst dann zum Graphen, wenn Messdaten zeigen, dass Parallelität, getrennte Kontexte oder unterschiedliche Berechtigungen den zusätzlichen Betriebsaufwand rechtfertigen.

Weiterführend: Vom Prompt zum Loop Engineering und AI Harness erklärt.

## Quellen

• LangChain: 3 Years of Graph Engineering with LangGraph
• Anthropic: Building Effective AI Agents
• Anthropic: How we built our multi-agent research system
• Cemri et al.: Why Do Multi-Agent LLM Systems Fail?
• Peter Steinberger: „Are we still talking loops or did we shift to graphs yet?“
• LangGraph: Overview
• LangGraph: Interrupts
• Microsoft AutoGen: GraphFlow
• Google ADK: Workflows
• OpenAI Agents SDK: Orchestration
• OpenAI Agents SDK: Tracing
• Öffentliches NotebookLM mit der Quellensynthese