Was ist der Unterschied zwischen Graph Engineering und Loop Engineering?

Loop Engineering gibt einem einzelnen KI-Agenten ein Ziel und eine Stopping Condition – der Agent wählt seinen Weg selbst. Graph Engineering legt die Topologie explizit fest: mehrere spezialisierte Einheiten als Nodes, Edges als definierte Verbindungen und ein typisierter Shared State. Der entscheidende Unterschied: Im Loop bestimmt der Agent den Weg, im Graphen bestimmen Sie ihn. Ein Graph besteht aus mehreren verbundenen Loops – Loop Engineering ist damit die Grundlage, auf der Graph Engineering aufbaut. Hinweis: Beide Begriffe sind aktuelle, praxisnahe Bezeichnungen aus der KI-Entwicklung und noch keine einheitlich definierten Fachbegriffe – die zugrunde liegenden Konzepte (Orchestrierung, State Machines, Workflow-Graphen) sind jedoch technisch etabliert.

Wann lohnt sich Graph Engineering für ein Unternehmen?

Graph Engineering lohnt sich, wenn ein Prozess mehrere spezialisierte Rollen hat, die unabhängig voneinander arbeiten, wenn parallele Ausführung Durchlaufzeiten reduziert, wenn definierte Qualitätsgates oder Human-in-the-Loop-Punkte nötig sind, oder wenn der Prozess hohe Anforderungen an Nachvollziehbarkeit und Dokumentation stellt – etwa im Kontext des EU AI Act. Die meisten Prozesse sind mit einem gut designten Loop besser bedient – Graph Engineering ist kein Allheilmittel, sondern die richtige Wahl für einen begrenzten, aber wichtigen Anteil an Anwendungsfällen.

Welche Frameworks werden für Graph Engineering eingesetzt?

LangGraph ist das am weitesten verbreitete Framework für Python-basiertes Graph Engineering – mit nativer Unterstützung für Checkpoints, Tracing und Human-in-the-Loop-Gates. Für Google-Cloud-Umgebungen eignet sich der Google Agent Development Kit (ADK) mit nativer Unterstützung für graph-basierte Workflows und dem A2A-Protokoll für die Zusammenarbeit mit Agenten aus anderen Frameworks. Für Microsoft-Umgebungen ist das Microsoft Agent Framework die aktuelle Wahl – der offizielle Nachfolger von AutoGen und Semantic Kernel, der beide Ansätze vereint. AutoGen selbst befindet sich seit Ende 2025 im Wartungsmodus und wird für neue Projekte nicht mehr empfohlen. Die Wahl des Frameworks hängt von der bestehenden Infrastruktur ab. Für Benchmark-Vergleiche empfehlen wir eigene Eval-Harnesses mit realen Use-Cases statt generischer Benchmarks.

Wie sicher sind Agenten-Graphen im Unternehmenseinsatz?

Agenten-Graphen können sehr sicher betrieben werden – vorausgesetzt, sie sind richtig designt. SESTdigital betreibt alle Systeme wahlweise in deutscher Cloud oder On-Premise. Der Shared State wird verschlüsselt persistiert, jede Einheit erhält nur Zugriff auf die State-Felder, die sie benötigt, und jede Edge-Traversal wird geloggt. Ergänzend gilt: Die Sicherheit hängt auch vom eingesetzten Framework und dessen Update-Stand ab – deshalb prüfen wir Frameworks laufend auf bekannte Schwachstellen. Strukturiert betriebene Agenten-Graphen sind in jedem Fall kontrollierbarer als unkontrollierte Schatten-KI, bei der Mitarbeitende private Tools für Unternehmensanalysen nutzen.

Was sind typische Fehler beim Einstieg in Graph Engineering?

Der häufigste Fehler: ein Loop-Problem mit einem Graphen lösen wollen, obwohl ein einzelner gut designter Agent ausreichen würde. Weitere typische Fehler sind zu viele, schlecht abgegrenzte Einheiten, ein Shared State ohne typisiertes Schema, fehlende Retry-Limits in bedingten Kanten und kein Eval-Harness vor dem Produktivbetrieb. Der strukturelle Fehler dahinter: kein definierter Owner für den Graphen. Ohne Owner wird kein Graph langfristig gepflegt.

Welche Rolle spielt Graph Engineering bei der EU AI Act Compliance?

Der EU AI Act schreibt keine bestimmte technische Architektur vor, verlangt aber Transparenz, Nachvollziehbarkeit von Entscheidungen und in bestimmten Fällen menschliche Aufsicht. Graph-basierte Architekturen erleichtern die Erfüllung dieser Anforderungen strukturell, weil jede Edge dokumentiert, jede Routing-Entscheidung nachvollziehbar und Human-in-the-Loop-Gates von Anfang an Teil des Designs sind. Deterministischer Kontrollfluss bedeutet: Kritische Entscheidungen werden nicht allein dem Reasoning des LLM überlassen, sondern durch explizite Kanten gesteuert – das erleichtert eine auditierbare KI-Governance, ersetzt aber nicht die individuelle rechtliche Prüfung im Einzelfall.

Müssen Führungskräfte Graph Engineering technisch verstehen?

Nein – aber sie sollten drei strategische Fragen beantworten können: Welche Prozesse sind Kandidaten für einen Graphen? Wer verantwortet den Graphen (Owner)? Wie wird der Graph gemessen (Eval-Kriterien)? Diese Fragen sind keine technischen Fragen. Sie sind die Voraussetzung für jeden erfolgreichen Einsatz von Agentensystemen im Unternehmen.

Wie steigt ein Unternehmen in Graph Engineering ein?

Der sinnvolle Einstieg ist eine technische Analyse: Welche Prozesse sind wirklich Kandidaten für Graph Engineering? Welche sind mit Loop Engineering besser bedient? Danach folgt das Graph-Design (Topology, State-Schema, Eval-Kriterien), dann die Implementierung mit dem passenden Framework – etwa LangGraph, dem Google Agent Development Kit oder dem Microsoft Agent Framework – und schließlich der Aufbau eines Eval-Harness vor dem Produktivbetrieb. SESTdigital begleitet alle Phasen – von der Analyse bis zum produktiven Multi-Agenten-System.

Graph Engineering: Wenn ein Loop nicht mehr reicht

Q: Wie funktioniert Verifikation in einem Agenten-Graphen?

Verifikation erfolgt über spezialisierte Reviewer-Knoten: Eine Einheit prüft das Ergebnis einer anderen gegen definierte Kriterien. Besteht das Ergebnis die Prüfung nicht, läuft eine bedingte Kante zurück zum Worker-Knoten – mit dem Prüfurteil im Shared State. Das Reasoning des LLM im Worker-Knoten wird durch dieses Urteil gezielt gelenkt. Wichtig: Immer ein Retry-Limit definieren, sonst entstehen Endlosschleifen und unnötige Kosten durch wiederholte Modellaufrufe.

Q: Was ist der Unterschied zwischen einem Knowledge Graph und einem Agenten-Graphen?

Ein Knowledge Graph ist eine Datenstruktur: Entitäten und ihre Beziehungen als Nodes und Edges – eine strukturierte Wissensbasis für GraphRAG und wissensintensives Retrieval. Ein Agenten-Graph ist dagegen eine Ausführungsstruktur: Er definiert, welche KI-Agenten in welcher Reihenfolge und unter welchen Bedingungen arbeiten. Beide Konzepte lassen sich kombinieren – ein Agenten-Graph, dessen Retrieval-Knoten einen Knowledge Graph durchsucht, ist eine leistungsfähige Architektur für komplexe Unternehmensanfragen.

Was viele glauben – und was wirklich stimmt

Mitte Juli 2026 drehte sich die Diskussion in der KI-Szene innerhalb weniger Tage. Wochenlang ging es um Loops, dann tauchte auf allen Kanälen ein neuer Begriff auf: Graph Engineering. „Loop Engineering ist tot, jetzt braucht es Graph Engineering“ las man sogar teilweise.

Wer unseren Artikel zu Loop Engineering gelesen hat, fragt sich zu Recht: Ist das schon wieder überholt?

Die kurze Antwort: nein. Ein Graph besteht aus Loops. Wer den Loop nicht beherrscht, baut mit einem Graphen nur ein aufwendigeres Problem. Der Hype hat eines richtig gemacht: Er hat den Begriff in die Breite gebracht. Was er falsch gemacht hat: Er hat Loop Engineering als veraltet dargestellt. Das stimmt nicht.

Dieser Artikel erklärt, was Graph Engineering wirklich ist, wie es sich von Loop Engineering unterscheidet, wann es sich lohnt – und wann nicht.

Was ist ein Graph Engineer?

Ein Graph Engineer entwirft und implementiert Agenten-Graphen: Er legt fest, welche Nodes welche Aufgabe übernehmen, wie die Edges zwischen ihnen verlaufen und welche Daten im Shared State wandern. Im Unternehmenskontext bedeutet das: deterministischen Kontrollfluss für KI-Agenten definieren, parallele Ausführungspfade planen und Verifikations-Knoten einbauen, die Qualität sichern, bevor ein Ergebnis weiterläuft. Graph Engineering ist keine akademische Disziplin – es ist angewandtes Software-Design für agentic Systeme.

Braucht man Mathematik-Kenntnisse für Graph Engineering?

Graph Theory als Mathematikfach ist anspruchsvoll. Graph Engineering als Praxis ist es nicht zwingend. Die Kernkonzepte – Nodes, Edges, State, Routing – lassen sich in einem halben Tag verstehen. Die eigentliche Schwierigkeit liegt im Design: Welche Topology passt zu welchem Prozess? Diese Fragen erfordern Erfahrung aus real umgesetzten Projekten, nicht Mathematik-Kenntnisse.

Definition: Graph Engineering vs. Loop Engineering

Der klarste Satz aus der Juli-Debatte lautet sinngemäß: Der Unterschied zwischen Loop und Graph ist, wer den Weg bestimmt – der Agent oder Sie.

Im Loop geben Sie Ziel und Messlatte vor, der Agent wählt seinen Weg selbst. Im Graphen legen Sie die Topology explizit fest: welche Einheiten existieren, welche Edges sie verbinden, welche Routing-Entscheidung an welcher Stelle getroffen wird.

Vergleichstabelle

Merkmal	Loop Engineering	Graph Engineering
Kontrollfluss	Agent entscheidet selbst	Sie definieren die Topology
Anzahl Agenten	Einer (mit Tools)	Mehrere spezialisierte Einheiten
Parallelisierung	Nicht vorgesehen	Fan-out / Fan-in nativ
Verifikation	Im Loop integriert	Eigener Reviewer-Knoten
Shared State	Implizit (Kontext)	Explizit typisiert
Auditierbarkeit	Schwierig	Jede Kante ist nachvollziehbar
Komplexität	Niedrig	Höher – aber kontrollierbar

Loop Engineering ist die richtige Wahl für eine klar abgegrenzte Aufgabe mit einem Agenten. Graph Engineering ist die richtige Wahl, sobald mehrere spezialisierte Agenten koordiniert werden müssen, parallele Zweige entstehen oder Human-in-the-Loop-Gates nötig sind.

Die Stufen im Überblick:

Prompt Engineering – Sie formulieren den richtigen Prompt für ein Modell.
Context Engineering – Sie steuern, welche Informationen das Modell bekommt (Retrieval, Memory, Tools).
Loop Engineering – Sie geben Ziel und Stopping Condition vor, der Agent läuft in einem Zyklus.
Graph Engineering – Sie verdrahten mehrere Agenten als Nodes, Edges und Shared State.

Jede Stufe baut auf der vorherigen auf. Wer Prompt Engineering nicht beherrscht, schreibt schlechte Knoten-Prompts. Wer Context Engineering überspringt, baut Graphen ohne sauberes Retrieval. Wer Loop Engineering nicht versteht, kann keinen sinnvollen Graphen designen.

Die drei Bausteine: Knoten, Kanten und geteilter Zustand

Graph Engineering besteht aus drei Elementen. Jedes hat eine klar definierte Rolle – und jedes muss verstanden werden, bevor der erste Code geschrieben wird.

Nodes (Knoten)

Ein Node ist eine Einheit, die Arbeit erledigt. Das kann ein spezialisierter KI-Agent sein, aber auch ein deterministischer Schritt: ein API-Aufruf, eine Datenbankabfrage, eine Formatierungsfunktion. Jeder Knoten hat genau eine Aufgabe – das ist der entscheidende Unterschied zum Loop, wo ein Agent viele Rollen gleichzeitig übernimmt. Die Einheiten arbeiten isoliert voneinander; sie lesen aus dem Shared State und schreiben ihr Ergebnis zurück.

Typische Knotentypen:
– Worker-Knoten: Führen eine Aufgabe aus (Analyse, Schreiben, Berechnung). Hier erledigt der KI-Agent seine eigentliche Arbeit.
– Reviewer-Knoten: Prüfen das Ergebnis anderer Einheiten gegen definierte Kriterien (Verifikation).
– Router-Knoten: Treffen eine Routing-Entscheidung – welcher Pfad als nächstes durchlaufen wird.
– Human-Gate-Knoten: Warten auf menschliche Freigabe, bevor der Graph weiterläuft.
– Retrieval-Knoten: Ziehen Daten aus einer Wissensbasis oder Datenbank (z. B. via RAG).

Die Stärke dieser Einheiten liegt in ihrer Spezialisierung. Ein Reviewer-Knoten, der ausschließlich prüft, liefert zuverlässigere Ergebnisse als ein Agent, der gleichzeitig schreibt und prüft. Wie jede Einheit intern work erledigt – welches Modell, welche Tools, welchen Prompt –, ist unabhängig von den anderen Einheiten im Graphen.

Edges (Kanten)

Edges definieren, wie der Graph traversiert wird. Es gibt vier grundlegende Typen:

Sequenzielle Kante: A läuft, dann B. Einfach, deterministisch. Dieser sequential Ablauf ist die Basis jedes Graphen.
Bedingte Kante: Wenn Bedingung X erfüllt → Knoten C; sonst → Knoten D. Das ist die Basis für Retry-Logik und Qualitätsgates. Jede bedingte Kante trifft eine explizite decision darüber, welcher Pfad als nächstes aktiviert wird.
Fan-out-Kante: Ein Knoten startet mehrere Einheiten parallel. Parallelisierung.
Fan-in-Kante: Mehrere parallele Einheiten laufen in einen gemeinsamen Knoten zusammen.

Die Kombination aus bedingten Kanten und Fan-out/Fan-in ist das, was Graph Engineering von einem simplen sequential Workflow unterscheidet.

Shared State (geteilter Zustand)

Der Shared State ist das Objekt, das entlang der Edges wandert. Jede Einheit liest daraus und schreibt hinein. Er enthält den Auftrag, Zwischenergebnisse, den aktuellen Entwurf, Prüfurteile und Metadaten. Die im State gespeicherten data – von Rohergebnissen bis zu Prüfurteilen – sind die Grundlage für jede Routing-Entscheidung im Graphen. Sensible data wie Finanzkennzahlen oder Kundendaten fließen ausschließlich durch explizit definierte State-Felder.

Ohne expliziten State haben Sie keine Organisation – sondern einen Gruppenchat, der nach jeder Nachricht vergisst, was vorher war. Der State ist der unterschätzte Teil des graph engineering. Wer ihn schlecht designed, kämpft später mit inkonsistenten Ergebnissen, die schwer zu debuggen sind.

Praxisbeispiel: Monatsreporting mit Graph Engineering

Stellen Sie sich einen KI-Agenten vor, der ein Monatsreporting erstellt. Im Loop läuft das so: Er plant, zieht Daten, schreibt, prüft sein Ergebnis gegen die Kriterien und korrigiert – bis eine Stopping Condition greift. Das funktioniert, solange das Reporting eine Aufgabe ist.

Nun wächst der Anspruch: Daten aus drei Systemen sollen parallel ausgewertet werden, ein zweiter Agent soll die Zahlen mit dem Vorjahr abgleichen, ein dritter – bewusst mit anderem Modell – soll den Entwurf kritisch gegenlesen, und erst dann entscheidet sich, ob das Reporting rausgeht oder zurück in die Überarbeitung wandert.

Das alles in einen einzigen Loop zu pressen, funktioniert selten: Der Agent verliert den Faden, mischt Rollen und prüft am Ende seine eigene Arbeit.

Beispiel 1: Monatsreporting (graph-basiert)

Die graph-basierte Alternative:

[Orchestrator]
    |
    |-- Fan-out -->
    |               [Datenanalyst ERP]
    |               [Datenanalyst CRM]   --> Fan-in --> [Synthese]
    |               [Datenanalyst Legacy]
    |
    v
[Autor]
    |
    v
[Reviewer-Knoten] -- Bestanden --> [Human-Gate] --> [Freigabe]
                 -- Abgelehnt --> [Autor] (retry)

Jede Einheit hat eine Aufgabe. Der Shared State enthält {auftrag, rohdaten_erp, rohdaten_crm, rohdaten_legacy, kennzahlen, entwurf, prüfurteil, freigabe_status}. Der Reviewer-Knoten prüft gegen definierte Kriterien – nicht gegen seine eigene Einschätzung. Der Human-Gate-Knoten wartet auf menschliche Bestätigung, bevor das Reporting versendet wird.

Beispiel 2: Dokumentenprüfung mit parallelen Fachknoten

Ein Compliance-Prozess, bei dem Verträge gleichzeitig von einem juristischen Knoten, einem Finanz-Knoten und einem Risiko-Knoten geprüft werden – independent voneinander, dann zusammengeführt in einem Synthese-Knoten. Die Orchestrierung dieser independent arbeitenden Einheiten zeigt, wie graph-based agent systems Durchlaufzeiten deutlich reduzieren.

Das ist Graph Engineering in der Praxis: nicht mehr Komplexität als nötig, aber genau so viel Kontrolle wie gebraucht.

Schritt-für-Schritt: Wie SESTdigital Multi-Agenten-Systeme umsetzt

Phase 1: Technische Analyse
Bevor eine einzige Einheit implementiert wird, analysieren wir den Prozess. Welche Teilaufgaben sind wirklich independent voneinander? Wo entsteht echter Mehrwert durch Parallelisierung? Wo reicht ein einfacher Loop? Diese Fragen kosten Zeit – sparen aber Monate in der Umsetzung.

Phase 2: Graph-Design
Wir definieren die Topology: Welche Knoten braucht der Graph? Welche Edges verbinden sie? Welche Routing-Entscheidungen sind deterministisch, welche modellbasiert? Wir skizzieren den Shared State als typisiertes Objekt, bevor wir Code schreiben. Gutes design entscheidet hier über Erfolg oder Misserfolg des Projekts.

Phase 3: Implementierung
Für die meisten Unternehmenskunden setzen wir auf LangGraph als Framework – es bietet native Unterstützung für Checkpoints, Tracing und Human-in-the-Loop-Gates. Für Google-Cloud-Umgebungen nutzen wir den Google ADK, für Microsoft-Umgebungen das Microsoft Agent Framework, den Nachfolger von AutoGen und Semantic Kernel. Die Wahl des Frameworks hängt von der bestehenden Infrastruktur ab, nicht von Präferenzen.

Phase 4: Eval und Harness
Jedes produktive System braucht ein Eval-Harness: eine Testumgebung, die den Graphen mit real eingesetzten Eingaben durchläuft und Ergebnisse gegen definierte Kriterien prüft. Ohne Harness Engineering wissen Sie nicht, ob Ihr Graph in der Produktion das tut, was er in der Entwicklung getan hat. Wir bauen das Harness parallel zur Implementierung – nicht als Nachgedanke.

Phase 5: Rollout und Schulung
Ein Graph, den nur zwei Entwickler verstehen, ist kein nachhaltiges System. Wir schulen die Teams, die mit dem System work erledigen – und die Führungskräfte, die Entscheidungen darüber treffen müssen.

Mehr zu Multi-Agenten-Systemen bei SESTdigital →

Verifikations- und Recovery-Mechanismen: Konkrete Patterns

Produktive Agenten-Graphen brauchen zwei Dinge, die in Tutorials fast immer fehlen: Verifikation und Recovery. Diese Patterns work in real eingesetzten Systemen – nicht nur in Demo-Umgebungen.

Pattern 1: Reviewer-Knoten mit Retry-Kante

Der einfachste Verifikations-Mechanismus: Ein Reviewer-Knoten prüft das Ergebnis eines Worker-Knotens gegen definierte Kriterien. Besteht es die Prüfung nicht, läuft eine bedingte Kante zurück zum Worker-Knoten – mit dem Prüfurteil im Shared State. Der Worker-Knoten liest das Urteil und korrigiert seine Arbeit. Das reasoning des LLM innerhalb des Worker-Knotens wird dabei durch das Prüfurteil gezielt gelenkt.

Wichtig: Begrenzen Sie die Retry-Anzahl. Ohne Maximum-Retry-Zähler im State läuft der Graph im Fehlerfall endlos. Drei Retries sind in den meisten Fällen ausreichend – danach sollte ein Human-Gate-Knoten aktiviert werden.

Pattern 2: Checkpoint-basiertes Recovery

LangGraph und ähnliche Frameworks unterstützen Checkpoints: Der State wird nach jedem Knoten-Durchlauf persistiert. Wenn der Graph an einem späteren Knoten fehlschlägt, kann er vom letzten Checkpoint neu gestartet werden – ohne alle vorherigen Einheiten erneut zu durchlaufen. Das reduziert Cost und Latenz erheblich bei langen Graphen.

Pattern 3: Typed Edges für deterministisches Routing

Typed Edges machen Routing-Entscheidungen explizit und nachvollziehbar. Statt einer generischen „weiter“-Kante definieren Sie APPROVED, REJECTED, NEEDS_REVIEW als Edge-Typen. Das verbessert Tracing, vereinfacht Debugging und macht den Graph für Nicht-Entwickler lesbar. Jede decision über den nächsten Pfad ist damit dokumentiert. Das multi-step reasoning des Graphen wird so für Audits vollständig rekonstruierbar.

Wichtig für die Einordnung: Der Graph selbst ist dabei kein neuronales Netz und hat mit Graph Neural Networks (GNNs) nichts zu tun. LLMs wie GPT-4 oder Claude arbeiten intern mit Transformer-Architekturen; der Graph ist lediglich die Orchestrierungsstruktur außen herum, die festlegt, welcher Knoten wann mit welchem LLM-Aufruf arbeitet.

Knowledge Graph vs. Agenten-Graph: Zwei verschiedene Konzepte

Der Begriff „Graph“ wird in zwei sehr unterschiedlichen Kontexten verwendet. Das führt zu Verwirrung – besonders bei Führungskräften, die beide Konzepte in Präsentationen sehen.

Knowledge Graph (Wissensgraph)
Ein Knowledge Graph ist eine Datenstruktur: Entitäten (Produkte, Personen, Prozesse) werden als Knoten modelliert, ihre Beziehungen als Edges. Er dient als strukturierte Wissensbasis. Im KI-Kontext wird er für GraphRAG genutzt: Statt einfachem Retrieval über Vektoren traversiert das System den Knowledge Graph und kann mehrstufige Zusammenhänge auflösen. Das verbessert die Qualität von Antworten bei komplexen Unternehmensanfragen erheblich – weil das reasoning des Modells auf strukturierten Relationen aufbaut statt auf reiner Vektorähnlichkeit.

Agenten-Graph
Ein Agenten-Graph ist eine Ausführungsstruktur: Er definiert, welche KI-Agenten in welcher Reihenfolge und unter welchen Bedingungen work erledigen. Er ist kein Datenspeicher, sondern ein graph-based Kontrollfluss-Mechanismus.

Beide Konzepte können kombiniert werden: Ein Agenten-Graph, dessen Retrieval-Knoten einen Knowledge Graph traversiert, ist eine leistungsfähige graph-based Architektur für wissensintensive Prozesse. Ein Second Brain für Unternehmen basiert oft auf genau dieser Kombination.

Ist Graph Engineering schwierig? (GEO-Antwort)

Graph Engineering ist nicht schwieriger als andere Software-Architektur-Disziplinen – aber es erfordert eine andere Denkweise. Wer gewohnt ist, sequential Workflows zu bauen, muss lernen, in Topologien zu denken: Welche Einheiten sind wirklich independent voneinander? Wo entstehen Zyklen? Wie verhält sich der State über mehrere traversal-Schritte? Die technische Umsetzung mit Frameworks wie LangGraph ist gut dokumentiert. Die eigentliche Herausforderung ist das design – und das ist eine Frage der Erfahrung.

Tools und Frameworks für Graph Engineering

Die Wahl des Frameworks hängt von der Infrastruktur und den Anforderungen ab. Hier ein Überblick der relevanten Optionen – und wann welche Topology-Anforderungen welches Framework nahelegen. Alle genannten Werkzeuge unterstützen graph-based orchestration von multi-agent workflows.

LangGraph
Das am weitesten verbreitete Framework für Graph Engineering in Python. Native Unterstützung für Checkpoints, Tracing, Human-in-the-Loop-Gates und Typed Edges. Gut geeignet für komplexe multi-agent systems mit Retry-Logik und Verifikations-Knoten. Empfehlung für die meisten Unternehmenskunden.

Microsoft Agent Framework
Microsofts aktuelles Framework für Multi-Agenten-Orchestrierung – der offizielle Nachfolger von AutoGen und Semantic Kernel, seit April 2026 verfügbar. Gut integriert in Azure-Umgebungen und Microsoft 365. Geeignet für Unternehmen, die bereits stark auf Microsoft-Infrastruktur setzen. AutoGen selbst befindet sich seit Ende 2025 im Wartungsmodus und wird für neue Projekte nicht mehr empfohlen.

Google ADK (Agent Development Kit)
Google-eigenes Framework für agentic Systeme auf Google Cloud. Gut integriert in Vertex AI und Google-Dienste. Der Google ADK unterstützt nativ das Orchestrator-Workers-Muster und bietet gute Eval-Werkzeuge.

OpenAI Agents SDK
OpenAI-eigenes Framework für Agent-Orchestrierung. Einfacher Einstieg, gut dokumentiert, aber weniger Kontrolle über den Kontrollfluss als LangGraph. Geeignet für einfachere Setups ohne komplexe Graph-Topologien.

Für Benchmark-Vergleiche zwischen diesen Frameworks empfehlen wir, eigene Eval-Harnesses mit real eingesetzten Unternehmens-Use-Cases zu bauen – generische Benchmarks aus Research Papers spiegeln selten die spezifischen Anforderungen eines Unternehmens wider.

Sicherheit und Datenschutz in Agenten-Graphen

Agenten-Graphen verarbeiten oft sensible Unternehmensdaten: Finanzkennzahlen, Kundendaten, interne Dokumente. Die Frage, wohin diese data fließen, ist berechtigt.

SESTdigital betreibt alle Systeme wahlweise in deutscher Cloud oder On-Premise – keine data verlässt die Unternehmensinfrastruktur ohne explizite Freigabe. Das gilt für den Shared State, für Checkpoint-Daten und für Tracing-Logs.

Drei konkrete Maßnahmen für sichere Agenten-Graphen:

State-Verschlüsselung: Der Shared State wird verschlüsselt persistiert. Checkpoint-Daten sind nur für autorisierte Systeme lesbar.
Knoten-Isolation: Jede Einheit hat nur Zugriff auf die State-Felder, die sie für ihre Aufgabe benötigt.
Audit-Logs: Jede Edge-Traversal wird geloggt – mit Zeitstempel, Knoten-ID und State-Hash. Das ermöglicht vollständige Nachvollziehbarkeit ohne Datenschutzrisiko.

Die Alternative – Mitarbeitende nutzen privates ChatGPT für Unternehmensanalysen, weil keine offizielle Lösung existiert – ist das eigentliche Sicherheitsrisiko. Ein kontrollierter Agenten-Graph mit klaren Datenpfaden ist sicherer als unkontrollierte Schatten-KI.

Graph Engineering für Führungskräfte: Was Sie wissen müssen

Sie müssen keinen Code schreiben, um Graph Engineering zu verstehen. Aber Sie müssen drei Fragen beantworten können:

1. Welche Prozesse sind Kandidaten für einen Graphen?
Prozesse mit mehreren spezialisierten Rollen, parallelen Teilaufgaben oder obligatorischen Qualitätsgates. Nicht jeder Prozess – die meisten Aufgaben sind mit einem Loop besser bedient.

2. Wer verantwortet den Graphen?
Ein Agenten-Graph braucht einen Owner: jemanden, der den State versteht, Routing-Entscheidungen verantwortet und Änderungen freigibt. Ohne definierten Owner wird der Graph nicht gepflegt und nicht weiterentwickelt.

3. Wie wird der Graph gemessen?
Ohne Eval-Harness und definierte Qualitätskriterien wissen Sie nicht, ob Ihr Graph funktioniert. Definieren Sie vor der Implementierung: Was ist ein gutes Ergebnis? Wie wird es gemessen? Wer prüft es?

Diese drei Fragen sind keine technischen Fragen. Sie sind strategische Fragen – und sie sind die Voraussetzung für jeden erfolgreichen Graph Engineering-Einsatz.

KI-Strategie und Roadmap mit SESTdigital →

Typische Fehler beim Übergang von Loop- zu Graph-Engineering

Die meisten Fehler entstehen nicht beim Schreiben von Code – sie entstehen beim Design. Das zeigt sich in real umgesetzten Projekten immer wieder.

Fehler 1: Zu früh zum Graphen
Der häufigste Fehler: Ein Loop-Problem wird mit einem Graphen gelöst. Das Ergebnis ist ein aufwendigeres System mit denselben Problemen. Prüfen Sie zuerst, ob ein verbesserter Loop reicht.

Fehler 2: Zu viele Einheiten
Jede Einheit, die keine klar abgegrenzte Aufgabe hat, ist ein potenzieller Fehlerort. Fünf gut designte Knoten schlagen zwanzig schlecht abgegrenzte.

Fehler 3: Shared State als Müllhalde
Wenn jede Einheit beliebig in den State schreibt, verlieren Sie die Übersicht. Definieren Sie den State als typisiertes Schema – und halten Sie sich daran.

Fehler 4: Kein Retry-Limit
Bedingte Kanten ohne Maximum-Retry-Zähler führen zu Endlosschleifen. Immer ein Retry-Limit im State definieren.

Fehler 5: Kein Eval-Harness vor dem Produktivbetrieb
Ohne Harness Engineering wissen Sie nicht, ob Ihr Graph in der Produktion das tut, was er in der Entwicklung getan hat. Ein Eval-Harness ist kein optionales Extra – es ist die Voraussetzung für produktive Systeme.

Fehler 6: Graph ohne Owner
Ein Agenten-Graph ohne definierten Owner wird nicht gepflegt, nicht weiterentwickelt und nicht verstanden.

Checkliste: Wann braucht Ihr Unternehmen Graph Engineering?

Beantworten Sie diese Fragen. Je mehr mit „Ja“, desto wahrscheinlicher ist Graph Engineering die richtige Architektur.

Prozess-Komplexität
– [ ] Hat der Prozess mehr als zwei spezialisierte Rollen, die independent voneinander arbeiten?
– [ ] Gibt es Teilaufgaben, die parallel ausgeführt werden könnten?
– [ ] Gibt es obligatorische Qualitätsgates, bevor ein Ergebnis weiterläuft?
– [ ] Ist menschliche Freigabe an bestimmten Punkten erforderlich?

Governance und Compliance
– [ ] Unterliegt der Prozess dem EU AI Act (Hochrisiko-Kategorie)?
– [ ] Müssen Entscheidungen des Systems auditierbar sein?
– [ ] Verarbeitet der Prozess besonders sensible Daten?

Technische Reife
– [ ] Haben Sie bereits funktionierende Loop-basierte Agenten im Einsatz?
– [ ] Haben Sie ein Eval-Harness für bestehende Agenten?
– [ ] Haben Sie einen definierten Owner für KI-Systeme?

Wenn Sie 6 oder mehr Fragen mit „Ja“ beantwortet haben: Graph Engineering ist wahrscheinlich die richtige nächste Stufe.

Wenn Sie weniger als 4 Fragen mit „Ja“ beantwortet haben: Starten Sie mit Loop Engineering.

SESTdigital: Von der technischen Analyse bis zum produktiven Multi-Agenten-System

SESTdigital begleitet Unternehmen auf allen Stufen – von der ersten Frage bis zum produktiven System. Mit 25+ implementierten KI-Projekten und KI-Softwareentwicklung seit 2021 kommen unsere Empfehlungen nicht aus dem Lehrbuch, sondern aus real umgesetzten Kundenprojekten.

Technische Analyse
Wir analysieren Ihre Prozesse und identifizieren, welche Kandidaten für Graph Engineering geeignet sind – und welche mit einem Loop besser bedient sind. Ergebnis: ein konkretes Graph-Design mit Knoten, Edges, State-Schema und Eval-Kriterien.

AI-Agent-Prototyp
In einem strukturierten Sprint entwickeln wir einen funktionsfähigen Prototyp Ihres Agenten-Graphen – mit Harness Engineering und erstem Eval-Durchlauf.

Multi-Agenten-System (Produktiv)
Von der technischen Analyse über das Graph-Design bis zur produktiven Implementierung in Ihrer Infrastruktur – deutsche Cloud oder On-Premise. Inklusive Schulung der verantwortlichen Teams.

Firmen-GPT mit Graph-Architektur
Sichere, interne KI-Plattform mit graph-basierter Retrieval-Architektur (GraphRAG) – trainiert auf Ihren Unternehmensdaten, gehostet in deutscher Cloud.

Jetzt unverbindliches Erstgespräch vereinbaren →

Graph Engineering: KI-Agenten koordinieren