Graph Engineering: Multi-Agenten-Workflows statt Chat-Ketten

Was ist Graph Engineering eigentlich?

Ein Agent-Graph verbindet mehrere spezialisierte KI-Agenten – Knoten, jeder mit eigener Loop aus Planen, Handeln, Prüfen – über Kanten: Übergaben, geteilter Zustand, Bedingungen. Der Graph legt fest, wer existiert, was jeder besitzt und wie Arbeit zwischen ihnen fliesst – sequenziell, parallel oder je nach Ergebnis verzweigt.

Woher der Begriff kommt. Im Juli 2026 postete Peter Steinberger, Gründer von OpenClaw, eine einzige Frage auf X: «Are we still talking loops or did we shift to graphs yet?» Der Tweet holte über 2,8 Millionen Aufrufe und einen neuen Begriff auf die Zeitachse. Er reiht sich in eine Kette ein, die 2023 mit Prompt Engineering begann und über Context Engineering, Harness Engineering und Loop Engineering führte – jede Stufe beschrieb, wie ein Team KI besser einsetzt: erst die Frage, dann die Information drumherum, dann die Umgebung, dann die Iteration. Graph Engineering beschreibt die nächste Stufe: wie mehrere Agenten als Organisation zusammenarbeiten.¹

Zwei Bedeutungen, ständig vermischt. Der Begriff trägt zwei Bedeutungen, die online ständig vermischt werden. Ein Knowledge Graph verknüpft Fakten – dieser Kunde arbeitet bei dieser Firma, dieses Feature gehört zu diesem Team – und hilft KI, über verstreute Daten hinweg zu schliessen. Ein Agent Graph dagegen bestimmt, wie Arbeit sich bewegt: Ein Planer verteilt an Researcher, ein Skeptiker prüft, ein Mensch genehmigt. Frameworks wie LangGraph machen diese zweite Bedeutung technisch fassbar: Knoten sind Funktionen oder Agenten, Kanten bestimmen den Datenfluss, ein zentraler Zustand ist die Quelle der Wahrheit für den ganzen Lauf.⁴

Der eigentliche Wert. Für Product Leader ist die zweite Bedeutung die relevante. Sie beantwortet eine altbekannte Frage neu: Wo entsteht der Wert, wenn ein Modell den Code sowieso schreiben kann? Die Antwort bleibt dieselbe wie beim Context Engineering davor: Der Engpass ist nicht das Coding. Es ist alles davor und danach – Planung, Prüfung, Übergabe, Freigabe. Ein Graph macht genau diese Schritte sichtbar und steuerbar, statt sie in einem Prompt zu verstecken.

Wann lohnt sich ein Graph – und wann reicht eine Loop?

Eine Loop reicht, wenn eine Aufgabe ein klares Ziel, echte Abhängigkeiten zwischen den Schritten und ein Kontextfenster hat, das den ganzen Vorgang trägt. Ein Graph lohnt sich, sobald Arbeit in unabhängige Spezialitäten zerfällt, Parallelisierung Zeit spart und verschiedene Schritte unterschiedliche Werkzeuge oder Modelle brauchen. Die Entscheidung lässt sich an vier Fragen festmachen.

Frage eins: echte Unabhängigkeit? Zerfällt die Aufgabe in Teile, die wirklich parallel laufen können – Kundenrecherche neben Konkurrenzanalyse, nicht Planung neben der Umsetzung derselben Funktion?

Frage zwei: unterschiedliche Werkzeuge? Braucht ein Schritt ein anderes Modell, ein anderes Werkzeug oder andere Berechtigungen als der nächste – etwa Code-Zugriff für den einen Knoten, nur Lesezugriff für den anderen?

Frage drei: braucht es eine Prüfinstanz? Muss ein Ergebnis geprüft werden, bevor es zählt – idealerweise von einem Modell, das die Arbeit nicht selbst geschrieben hat? Dasselbe Modell, das schreibt und bewertet, benotet sich selbst milde.

Frage vier: verträgt der Lauf einen Ausfall? Darf der Ausfall eines einzelnen Schritts nicht den ganzen Lauf mitreissen? Je mehr dieser vier Fragen mit Ja beantwortet werden, desto eher trägt ein Graph seine eigenen Koordinationskosten.

Die Kosten sind real. Nicht nur konzeptionell: Anthropic beschreibt in der eigenen Engineering-Dokumentation ein Orchestrator-Worker-System – ein Leitagent zerlegt eine Recherche und startet drei bis fünf spezialisierte Subagenten parallel. Im internen Recherche-Eval schlug dieses Setup einen Einzel-Agenten um 90,2 Prozent – bei rund 15-mal höherem Tokenverbrauch, wobei Tokenverbrauch allein schon 80 Prozent der Leistungsunterschiede erklärte. Die Faustregel dahinter lässt sich direkt übernehmen: Ein Graph lohnt sich, wenn der Wert der Aufgabe die Mehrkosten der Koordination übersteigt – nicht, weil ein Graph moderner wirkt als eine Loop.²

Wie baust du deinen ersten Graphen, ohne neue Tools zu kaufen?

Zeichne den Graphen, bevor du ihn automatisierst. Eine Bahn pro Rolle – Planer, Researcher, Skeptiker, Mensch – auf einem Board, einmal manuell durchgespielt, zeigt mehr als jedes Framework am ersten Tag.

Drei Reifegrade genügen. Stufe eins: manuell, jede Rolle als eigene Bahn auf einem Whiteboard oder in Excalidraw, Pfeile zeigen die Übergaben. Stufe zwei: dateibasiert, jeder Schritt schreibt ein eigenes Markdown-File – ein Planer legt `plan.md` an, Researcher füllen eigene Dateien, ein Skeptiker schreibt `review.md` –, das hinterlässt eine nachvollziehbare Spur. Stufe drei: orchestriert, mit Frameworks wie LangGraph für Zustandsverwaltung, Checkpoints und Human-in-the-Loop-Freigaben, oder AutoGens Graph-Flow für bedingte Verzweigungen. Das Werkzeug kommt nach dem Workflow, nicht davor – ein automatisierter Prozess, den niemand verstanden hat, produziert nur schneller Mittelmass.⁴

Was in jeder Stufe gleich bleibt, ist der geteilte Kontext: Jeder Knoten braucht denselben Stand von Code, Tickets und Entscheidungen, sonst wiederholt er Arbeit oder widerspricht dem letzten Knoten. Genau das ist die Aufgabe der Context Engine hinter Teklens' Live View – sie hält Planungs-, Umsetzungs- und Review-Agenten am selben, versionierten Projektwissen, statt dass jeder Knoten seinen eigenen Kontext neu zusammensucht.

Wo Multi-Agenten-Graphen brechen

Bei eng verzahnter Arbeit wie Coding schlägt der Graph oft zurück. Cognition, das Team hinter Devin, dokumentierte 2025 öffentlich, warum ihr Coding-Agent bei einem einzigen, gut mit Kontext versorgten Agenten blieb, statt auf mehrere Subagenten zu setzen.³

Das Kernargument. Subagenten, die parallel an Teilen desselben Problems arbeiten, teilen sich nicht automatisch denselben Kontext. Ein Subagent entscheidet sich für Framework A, ein anderer für Framework B – und niemand bemerkt den Widerspruch, bis der Code zusammengeführt wird. Bei Recherche-Aufgaben ist das verkraftbar, weil sich Ergebnisse am Ende zusammenfassen lassen. Bei Code, der kompilieren und zusammenpassen muss, wird derselbe Mechanismus, der bei Anthropics Recherche-System 90 Prozent Vorsprung brachte, zur Fehlerquelle.

Beide Belege stammen von Teams, die Graphen tatsächlich in Produktion betreiben – und widersprechen sich nicht, sie grenzen ab. Unabhängige, parallelisierbare Arbeit trägt einen Graphen. Eng verzahnte Arbeit mit gemeinsamem Zustand trägt eine Loop mit gutem Kontext besser. Die Aufgabe entscheidet, nicht der Trend.

Häufige Fragen

Empfehlungen

• Fang mit einer Loop an, nicht mit einem Graphen. Prüf zuerst, ob eine einzelne Loop mit vollständigem Kontext reicht. Füg Knoten erst hinzu, wenn eine der vier Entscheidungsfragen mit Ja beantwortet ist.
• Zeichne den Graphen, bevor du ihn automatisierst. Rollen, Pfeile, ein Board – einmal manuell durchgespielt. Wer die Struktur nicht von Hand versteht, automatisiert nur Verwirrung schneller.
• Trenn Worker von Checker. Kein Modell bewertet zuverlässig die eigene Arbeit. Ein eigener Prüf-Knoten ist Pflicht, sobald ein Ergebnis Tragweite hat.
• Rechne die Koordinationskosten mit. Ein Graph kostet real mehr Tokens. Rechtfertige das mit dem Wert der Aufgabe – nicht damit, dass ein Graph zeitgemässer wirkt.
• Setz den Human-Gate an den teuersten Schritt. Freigabe dort, wo ein Fehler wirklich etwas kostet – Deploy, Kundenkommunikation, Architekturentscheidung. Nicht bei jedem Zwischenschritt.
• Lass jeden Lauf Wissen hinterlassen. Notizen, Belege und Entscheidungen aus jedem Graphen-Durchlauf landen versioniert und wiederverwendbar – das ist der eigentliche Zinseszins von Graph Engineering.

Einordnung & Grenzen

• Die 90,2-Prozent-Zahl und der 15-fache Tokenverbrauch stammen aus Anthropics internem Recherche-Eval mit Claude Opus als Leitagent und Claude Sonnet als Subagenten – ein Branchen-Datenpunkt aus einem eigenen Benchmark, keine unabhängige Studie.
• Cognitions Gegenposition bezieht sich auf Coding-Agenten mit enger Interdependenz zwischen den Teilaufgaben. Für klar parallelisierbare Recherche- oder Content-Arbeit gilt eher Anthropics Erfahrung. Welche Seite passt, entscheidet die Aufgabe, nicht die Quelle mit der lauteren Meinung.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Peter Steinberger (@steipete) auf X (18. Juli 2026) ↗ – «Are we still talking loops or did we shift to graphs yet?» – über 2,8 Mio. Aufrufe, Auslöser des Begriffs.
2. 2.Anthropic, «How we built our multi-agent research system» (2025) ↗ – Orchestrator-Worker-System, 90,2 % Vorsprung, 15-facher Tokenverbrauch, 80 % Varianzerklärung durch Tokens.
3. 3.Cognition, «Don't Build Multi-Agents» (2025) ↗ – Warum Devins Coding-Agent bei einem gut kontextierten Einzel-Agenten blieb.
4. 4.LangGraph-Dokumentation (LangChain) ↗ – Knoten, Kanten und Zustand als Bausteine orchestrierter Agenten-Graphen.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.