Was ist Graph Engineering?

Graph Engineering beschreibt Multi Agent Systeme als expliziten Graph. Knoten sind Agenten, deterministische Funktionen, Router und menschliche Freigabepunkte. Kanten sind erlaubte Übergänge und Datenflüsse.

Der Begriff kam im Juli 2026 auf. Loop Engineering beschreibt, wie ein einzelner Agent arbeitet. Graph Engineering beschreibt, wie viele Agenten zusammen arbeiten. Die Topologie wird zum Artefakt: versionierbar, prüfbar, überwachbar.

Wichtig für die Einordnung: Das ist nicht Knowledge Graph Engineering. Ein Knowledge Graph strukturiert, was ein System weiß. Graph Engineering strukturiert, wer das System ist und wie Arbeit fließt.

Never Code Alone arbeitet täglich mit Agenten Setups. Claude Code und OpenCode laufen bei uns produktiv, orchestriert über n8n und Paperclip, mit lokalen Modellen über Ollama. Wir kennen die Stelle, an der ein einzelner Loop kippt und ein Team aus Agenten die bessere Antwort ist. Und wir kennen die Stelle, an der ein Graph nur Komplexität ohne Nutzen erzeugt.

Passende Leistungen: Agentic Coding für die Orchestrierung mehrerer Agenten, Quality Gates für KI Code als Kontrollpunkt an jeder Kante, NCA MCP Middleware für den Zugriff der Knoten auf Unternehmensdaten, rules.md und AGENTS.md für die Rollenbeschreibung jedes Knotens, Codebase Audit für den Blick auf das Ergebnis und Vibe Coding Onboarding für den Einstieg im Team.

Am 18. Juli 2026 stellte Peter Steinberger, der Entwickler hinter OpenClaw, eine kurze Frage auf X: Reden wir noch über Loops oder sind wir längst bei Graphen? Der Post lief innerhalb von Stunden auf mehrere hunderttausend Aufrufe.

Sechs Wochen vorher hatte derselbe Autor mit einem ähnlichen Einzeiler den Begriff Loop Engineering populär gemacht. Das Muster wiederholte sich. Innerhalb von Tagen erschienen Guides, Frameworks positionierten sich neu, und der Begriff war da.

Neu ist die Idee nicht. Multi Agent Forschung, Actor Modelle, Contract Net Protokolle und Airflow DAGs beschreiben seit Jahrzehnten dasselbe Prinzip. Neu ist, dass die Modelle gut genug sind, um als eigenständige Knoten zu laufen, und dass genug Teams das gleichzeitig bauen. Ein Namensereignis, kein Durchbruch.

Ein Agent Loop ist ein Zyklus für einen Agenten. Trigger feuert, Agent handelt, Verifier prüft, bei Bedarf neue Runde. Alle Guardrails gelten für einen Lauf: maximale Iterationen, Token Budget, Abbruch bei Stillstand.

Ein Graph ist die Organisation mehrerer Agenten. Jeder Knoten fährt seinen eigenen Loop. Die Kanten legen fest, wer wem etwas übergibt, was parallel läuft und was passiert, wenn ein Knoten fällt.

Der praktische Unterschied: Ein Loop verzeiht Unschärfe. Der Agent findet innerhalb der Iteration schon einen Weg. Ein Graph verzeiht nichts. Du musst jeden Knoten benennen, jede Kante deklarieren und jeden Fehlerfall festlegen, bevor das System läuft.

Genau das ist der Wert. Ein Graph zwingt dich, den Workflow wirklich zu modellieren. Und genau das ist auch der Preis.

Die Stufen ersetzen sich nicht. Sie stapeln sich. Ein Graph aus Knoten mit schlechten Loops ist ein Organigramm unzuverlässiger Mitarbeiter. Exzellente Loops in einer zufälligen Topologie erzeugen Koordinationschaos, sobald die Zahl der Agenten steigt.

Die folgende Tabelle ordnet die vier Stufen ein. Jede Stufe steuert eine andere Ebene und reicht für einen anderen Aufgabentyp.

Produktive Systeme fahren zwei Graphen gleichzeitig. Wer sie zusammenwirft, baut sich Ärger ein.

Der Org Graph ist stabil. Er beschreibt langlebige Agenten mit festen Rollen. Ein Security Agent besitzt Auth, Rechte und Audit Logs. Ein Data Agent besitzt Schema und Migrationen. Ein API Agent besitzt Endpunkte und Verträge. Jeder Knoten sammelt Kontext über die Zeit. Ein Security Agent, der 300 Pull Requests gesehen hat, kennt das Bedrohungsmodell der Codebasis implizit.

Der Work Graph ist flüchtig. Er beschreibt, was gerade passiert. Aufgaben teilen sich auf, laufen zusammen, verschwinden wieder, wenn neue Evidenz sie überflüssig macht. Er wird pro Auftrag erzeugt und danach verworfen.

Der Org Graph beantwortet die Frage nach dem Wer. Der Work Graph beantwortet die Frage nach dem Was, und zwar jetzt gerade.

Drei Kosten, die in jeder Diskussion untergehen und in jedem echten Projekt auftauchen.

Design Aufwand. Einen Loop skizzierst du in einer AGENTS.md und startest ihn in Minuten. Ein Graph verlangt vorher: Welche Domäne gehört wem, wie sieht die Übergabe aus, wann gilt ein Knoten als fertig.

Fehleroberfläche. Fällt ein Loop, ist ein Agent gefallen. Fällt ein Knoten im Graph, musst du nachvollziehen, ob der Fehler weitergelaufen ist, welche Knoten schlechte Eingaben bekommen haben und ob der Work Graph jetzt in einem inkonsistenten Zustand steht.

Kontextverlust an den Kanten. Jeder Knoten hält seinen eigenen Kontext. Kontext fließt nicht von allein weiter. Fehlt eine Kante, arbeitet ein Knoten ohne Information, die er gebraucht hätte. Das Thema kennen wir aus dem Context Window Management, nur eine Ebene höher.

Dazu kommen die Kosten. Ein Work Graph mit Fan Out, Retries und dynamisch erzeugten Teilaufgaben vervielfacht Modell und Tool Aufrufe. Ohne Budget pro Knoten läuft die Rechnung weg. Token Kosten reduzieren wird auf Graph Ebene zur Pflichtübung.

Der Begriff kollidiert mit einer älteren Bedeutung. Wer nach Graph Engineering sucht, landet oft bei Knowledge Graphs, Triple Stores und GraphRAG. Das ist ein anderes Thema.

Knowledge Graph: strukturiert Daten. Entitäten und Beziehungen für Retrieval und Reasoning. Anwendungsfeld ist RAG, etwa mit LlamaIndex und passenden Embedding Modellen.

Graph Engineering im Sinn von 2026: strukturiert das System. Mitglieder, Mandate, erlaubte Übergänge, Freigabepunkte.

Beides kann in einer Architektur nebeneinander stehen. Sie beantworten nur unterschiedliche Fragen. Wer die Begriffe vermischt, redet in Meetings aneinander vorbei.

Die Frameworks tragen den Graph teils schon im Namen. Eine kurze Einordnung, was wofür geeignet ist.

LangGraph macht Zustände und Übergänge zu erstklassigen Objekten im Code und ist geeignet, wenn die Topologie fest steht und nachvollziehbar sein muss. AutoGen hat Stärken bei Konversation zwischen Agenten. CrewAI arbeitet rollenbasiert und liegt damit nah am Org Graph Gedanken. Dify ist geeignet für visuell modellierte Workflows.

Aus dem Coding Umfeld gehören Claude Agent Teams, Ruflo, SwarmForge und Mirofish in dieselbe Diskussion. Paperclip nutzen wir bei NCA produktiv für die Orchestrierung.

Ohne Beobachtbarkeit bleibt jeder Graph eine Blackbox. Langfuse ist geeignet, um Läufe pro Knoten nachzuvollziehen. Für parallele Arbeit an derselben Codebasis helfen Git Worktrees, damit sich Knoten nicht gegenseitig überschreiben.

Der Zugriff der Knoten auf Tools und Daten läuft in der Regel über MCP. Wer die Rechte nicht pro Knoten schneidet, gibt jedem Agenten alles.

Die ehrliche Antwort für die meisten Teams: Ein guter Loop schlägt einen schlechten Graph deutlich.

Ein Loop reicht, wenn die Aufgabe in einer Domäne liegt, sequentiell abläuft und ein Mensch am Ende reviewt. Das trifft auf den Großteil der täglichen Entwicklungsarbeit zu. Wer hier einen Graph baut, kauft Komplexität ohne Gegenwert.

Ein Graph lohnt sich, wenn Arbeit echt parallel läuft, mehrere Domänen mit unterschiedlichem Kontext beteiligt sind, Freigaben an definierten Stellen sitzen müssen und die Zuordnung von Kosten und Fehlern pro Knoten gefordert ist.

Der Zwischenschritt, den viele überspringen: erst den Loop sauber bekommen. Ohne Quality Gates, ohne saubere Code Qualität mit KI Agenten und ohne Guardrails multipliziert ein Graph nur die vorhandenen Probleme.

Unsere Content Pipeline auf nevercodealone.de läuft selbst als kleiner Graph. Ein Agent recherchiert, ein Agent baut die Seite über MCP, ein Workflow in n8n und Paperclip erzeugt Bilder, und an genau zwei Stellen sitzt ein menschlicher Freigabepunkt: beim Bild und beim Publish. Diese zwei Kanten sind der Unterschied zwischen Automatisierung und Kontrollverlust.

Was wir dabei gelernt haben, gilt für jeden Graph: Freigabepunkte gehören dorthin, wo Konsequenzen entstehen, nicht überall verteilt. Und jeder Knoten braucht eine schriftliche Rollenbeschreibung, sonst driftet er.

Weiterführend im Glossar: Agentic Engineering und AI Engineering zur Begriffsklärung, SKILL.md als Baustein für einzelne Knoten, Agent Skills als Installationseinheit, KI Strategie für die Ebene darüber und Ollama für Knoten, die lokal laufen sollen.

Aus der Praxis: Agentic Coding Patterns, Enterprise Readiness und Human Readiness für Teams, die den Schritt gerade planen.

Diese Fragen tauchen in Gesprächen zu Multi Agent Setups regelmäßig auf, vom ersten Prototyp bis zur Frage nach Budgets und Freigaben.