# Graph Engineering beginnt dort, wo Routing zum Produktverhalten wird Canonical URL: https://huecki.com/blog/graph-engineering-routing-wird-produktverhalten/ Markdown URL: https://huecki.com/blog/graph-engineering-routing-wird-produktverhalten.md Language: German Published: 2026-07-26 Updated: 2026-07-26 Author: Dominic Hückmann Topic: AI Agent Workflows - Agent topics: Context Engineering, Agent Evals - Tags: Graph Engineering, LangGraph, AI Agents, Agent Workflows, Human-in-the-Loop, AI Engineering - Audience: AI agent builders, platform engineers, technical product leaders, developers building long-running AI workflows - Concepts: graph-engineering, langgraph, stateful-agents, durable-execution, human-in-the-loop, workflow-contracts Thesis: Eine Route gehört in einen expliziten Workflow-Graphen, sobald sie Teil des Produktvertrags ist und unabhängig getestet, wiederaufgenommen, auditiert oder von einer externen Instanz kontrolliert werden muss. Content status: field-note ## Summary Graph Engineering ist nicht das Zeichnen komplexer Agentendiagramme. Es beginnt dann, wenn Retry, Eskalation, Evidenzprüfung oder menschliche Freigabe sichtbares und testbares Produktverhalten werden. ## Description Ein neues LangGraph-Paper zeigt drei belastbare Muster für stateful AI-Workflows: explizite Zustände, Recovery-Routen und Human Gates statt Graph-Hype. ## Body Ein Agent generiert SQL. Die Query ist kaputt. Was passiert jetzt? Wenn die Antwort in einem Prompt versteckt ist – „prüfe deine Query und versuche es bei einem Fehler erneut“ – hast du eine Hoffnung formuliert. Wenn der Fehler im State landet, ein Retry-Zähler steigt und eine Route zurück zur SQL-Generierung führt, hast du Produktverhalten gebaut. Genau dort beginnt **Graph Engineering**. Nicht beim Diagramm. Nicht beim zweiten Agenten. Nicht bei einer möglichst beeindruckenden Anzahl von Nodes. Sondern dann, wenn eine Route wichtig genug ist, dass sie sichtbar, begrenzt, testbar und später erklärbar sein muss. ## Die kurze Version Das neue Paper [*Graph-Based Agentic AI with LangGraph*](https://arxiv.org/abs/2607.19297) liefert drei ausführbare Rezepte: 1. SQL-Analytics mit Validierung und Repair-Loop 2. Agentic RAG mit Evidenz-Gate und Citation-Check 3. Policy Review mit Human Interrupt und Checkpoint Die Autoren machen dabei etwas richtig, das im aktuellen Graph-Hype schnell verloren geht: > Sie behaupten nicht, dass ein Graph das Modell intelligenter macht. Der Graph macht andere Dinge besser. Er gibt dir explizite Orte, an denen der Workflow State speichert, Fehler routet, auf Menschen wartet, nach einer Unterbrechung weiterläuft und erklärt, warum ein bestimmter Pfad genommen wurde. Der letzte Wert ist wichtig. Das Paper ist ein Practitioner Guide, kein Beweis dafür, dass LangGraph Accuracy, Latenz oder Kosten verbessert. ## Ein Graph ist eine ausgelagerte Entscheidung Ein einfacher Agent-Loop sieht ungefähr so aus: Das ist für viele Aufgaben völlig ausreichend. Der Agent ruft ein Tool auf, liest das Ergebnis und entscheidet über den nächsten Schritt. Ein ReAct-artiger Loop kann erstaunlich viel leisten, ohne dass du einen Workflow-Graphen einführst. Das Problem beginnt, wenn die nächste Entscheidung nicht mehr nur Denkverhalten des Modells ist, sondern ein Vertrag mit dem Nutzer oder dem Betriebssystem: - Schwache Evidenz darf nicht zu einer gestützten Antwort führen. - Nach drei SQL-Fehlern muss der Run stoppen. - Eine Kündigungsempfehlung darf nicht ohne Freigabe finalisiert werden. - Ein pausierter Vorgang muss nach einem Neustart weiterlaufen. - Ein Operator muss später erkennen können, warum der Agent eskaliert hat. Dann reicht „das Modell wird sich hoffentlich erinnern“ nicht mehr. Der Graph macht die Entscheidung nicht automatisch korrekt. Er macht sie **adressierbar**. Du kannst sie testen. Du kannst sie beobachten. Du kannst sie einer Policy zuordnen. Du kannst sie ändern, ohne den gesamten Prompt umzuschreiben. ## Die drei Rezepte aus dem Paper ### 1. SQL: Fehler werden zu einer Route Der SQL-Workflow läuft nicht einfach von Frage zu Antwort. ```txt schema → sql_generation → validation ├─ valid → execution → summary ├─ error + budget → sql_generation └─ error + exhausted → fail ``` Das Entscheidende ist nicht die SQL-Generierung. Das kann auch ein einfacher Agent. Das Entscheidende ist, dass `error` und `attempts` Teil des typisierten States sind. Die Anwendung – nicht ein optimistischer Satz im Prompt – entscheidet, ob noch ein Versuch erlaubt ist. Damit wird der Retry zu testbarem Produktverhalten. ### 2. RAG: Schwache Evidenz wird zu einem Zustand Beim RAG-Rezept entscheidet die Qualität der gefundenen Dokumente über den nächsten Pfad: ```txt retrieve → grade evidence ├─ strong → generate → verify citations → finalize ├─ weak + budget → retrieve again └─ weak + exhausted → unsupported / failed ``` Das ist eine kleine, aber wichtige Verschiebung. Viele RAG-Systeme behandeln Evidenzqualität als Prompt-Tipp: „Nutze nur die bereitgestellten Quellen.“ Das Paper behandelt sie als Routing-Signal. Schlechte Evidenz produziert dann nicht nur vorsichtigere Prosa. Sie verändert die Ausführung. ### 3. Human-in-the-Loop: Ein Mensch wird zur Autoritätsgrenze Das Policy-Review-Rezept ist der stärkste Use Case: ```txt draft → risk score ├─ low → finalize └─ high → interrupt → human review → resume → finalize ``` Der Workflow pausiert, speichert seinen State und wartet auf eine externe Entscheidung. Danach wird derselbe Thread mit Reviewer-Feedback fortgesetzt. Ein Callback allein reicht dafür nicht. Ein Ticket allein reicht nur dann, wenn der Workflow außerhalb des Graphen endet. Wenn die Ausführung später mit demselben State weitergehen soll, brauchst du eine haltbare Resume-Grenze. ## Ich habe den mitgelieferten Code ausgeführt Das Paper liefert ein Ancillary Package mit Mock-Modell, Fixtures und drei Workflows. Ich habe das Paket in einer isolierten Python-Umgebung installiert und die veröffentlichte Testsuite ausgeführt: ```txt 3 passed ``` Danach habe ich alle 15 mitgelieferten Fixture-Fälle gestartet: - 5 SQL-Fälle - 5 RAG-Fälle - 5 Human-Review-Fälle Alle erreichten den erwarteten terminalen Status. Der SQL-Tool-Fehler brauchte zwei Versuche. Die Fälle mit schwacher oder mehrdeutiger RAG-Evidenz verbrauchten ihr Retry-Budget und endeten korrekt als `failed`. Eine abgelehnte Human-Freigabe endete als `escalated`. Das ist ein gutes Zeichen: Die Rezepte sind nicht nur Pseudocode. Aber die Reproduzierbarkeit hat eine Grenze. Die committed Pytest-Datei enthält nur drei Testfunktionen. Viele Fehler- und Recovery-Fälle liegen als Fixtures vor, werden von der Testsuite aber nicht mit eigenen Assertions abgedeckt. Mein Urteil: **Ausführbarer Architektur-Guide: ja. Vollständige Regression-Suite: nein. Produktionsnachweis: ausdrücklich nein.** ## Wann du keinen Graphen brauchst Graph Engineering kann sehr schnell zu Diagramm-Engineering werden. Du zerlegst eine lineare Aufgabe in zwölf Nodes, führst drei State-Schemas ein und baust Routing-Code für einen Prozess, den ein `if` und ein Retry-Wrapper verständlicher gelöst hätten. Das Paper warnt selbst davor. Für strukturierte Extraktion ist ein Schema-first Stack oft passender. Für Prompt- und Program-Optimierung ist DSPy näher am Problem. Für einen kurzen Tool-Loop reicht häufig ein SDK oder ReAct-Muster. Und selbst LangGraph hat eine Functional API, mit der du Persistence und Interrupts in normalem Python-Control-Flow nutzen kannst. Du musst nicht jede Workflow-Idee zuerst als sichtbaren `StateGraph` modellieren. ## Die eigentliche Schwelle Ich würde einen Schritt dann zu einem eigenen Node machen, wenn mindestens eine dieser Fragen mit Ja beantwortet wird: 1. Muss ich diesen Schritt unabhängig testen? 2. Braucht er eine eigene Retry-, Timeout- oder Abbruchregel? 3. Soll er im Trace als Produkt- oder Betriebsereignis sichtbar sein? 4. Darf vor oder nach ihm eine andere Instanz eingreifen? 5. Muss sein Ergebnis einen Prozessneustart überleben? Wenn alle Antworten Nein sind, gehört der Schritt wahrscheinlich in eine normale Funktion. Wenn mehrere Antworten Ja sind, hast du keine Prompt-Frage mehr. Du hast eine Workflow-Grenze. ## Was das Paper für Produktion offenlässt Die drei Rezepte zeigen die Form. Sie zeigen nicht den Produktionsbetrieb. Nicht gemessen werden: - Modellqualität - Latenz - Token- und Infrastrukturkosten - Streaming UX - Observability-Backends - Deployment-Topologie - Lastverhalten - Cross-Session Memory - Multi-Agent-Supervisor-Worker-Graphs Auch der Human-in-the-Loop-Demo-Flow nutzt einen In-Memory-Checkpointer. Für lokale Tests ist das okay. In Produktion braucht der State einen dauerhaften Store. Und es gibt eine wichtige Runtime-Falle: Laut offizieller LangGraph-Dokumentation startet ein unterbrochener Node beim Resume wieder von vorne. Side Effects vor dem Interrupt müssen deshalb idempotent sein. Das ist genau die Art Detail, an der ein schönes Diagramm zu einem schlechten System wird. Ein produktionsfähiger Graph braucht zusätzlich: ```txt authorization idempotency timeouts + cancellation retry budgets tenant isolation trace retention checkpoint lifecycle route contract tests output quality evals ``` Der Graph ersetzt diese Arbeit nicht. Er gibt ihr nur explizite Stellen. ## Das bessere mentale Modell Graph Engineering ist nicht „mehrere intelligente Nodes miteinander verbinden“. Es ist die Arbeit, aus impliziten Agentenentscheidungen einen kontrollierbaren Zustandsautomaten zu machen: Das Modell darf Inhalt erzeugen. Das Modell darf Kandidaten vorschlagen. Das Modell darf innerhalb eines Nodes explorieren. Aber Retry-Budgets, Autoritätsgrenzen, Abbruchbedingungen und persistente Zustandswechsel sollten nicht als lose Hoffnung im Prompt leben. Sobald eine Route Teil des Produktvertrags wird, gehört sie aus dem Prompt heraus. Dann beginnt Graph Engineering. ## Quellen - [Graph-Based Agentic AI with LangGraph](https://arxiv.org/abs/2607.19297) - [Ancillary Source Package des Papers](https://arxiv.org/e-print/2607.19297) - [LangGraph Overview](https://docs.langchain.com/oss/python/langgraph/overview) - [LangGraph Graph API](https://docs.langchain.com/oss/python/langgraph/graph-api) - [LangGraph Persistence](https://docs.langchain.com/oss/python/langgraph/persistence) - [LangGraph Interrupts](https://docs.langchain.com/oss/python/langgraph/interrupts) - [LangGraph Functional API](https://docs.langchain.com/oss/python/langgraph/functional-api) - [ReAct](https://arxiv.org/abs/2210.03629) - [DSPy](https://arxiv.org/abs/2310.03714) - [Anthropic: Building a Multi-Agent Research System](https://www.anthropic.com/engineering/multi-agent-research-system) ## FAQ ### Was ist Graph Engineering bei AI Agents? Graph Engineering macht die Zustände, Arbeitsschritte und Übergänge eines Agenten-Workflows explizit. Es ist besonders nützlich, wenn Fehler eine Recovery-Route brauchen, Arbeit pausieren und fortgesetzt werden muss oder menschliche Freigaben Teil des Prozesses sind. ### Wann sollte ich LangGraph statt eines einfachen Agent-Loops nutzen? Wenn State einen Neustart überleben muss, Verzweigungen sichtbares Produktverhalten ändern, Retries begrenzt und testbar sein sollen, ein Human Gate benötigt wird oder der Ausführungspfad später rekonstruiert werden muss. ### Macht ein Workflow-Graph den Agenten intelligenter? Nein. Das Paper behauptet keinen Intelligenzgewinn. Ein Graph macht den Workflow kontrollierbarer, beobachtbarer und besser testbar; die Modellqualität muss separat evaluiert werden. ### Ist Graph Engineering dasselbe wie ein Multi-Agent-System? Nein. Ein Graph kann einen einzigen Agenten, deterministische Tools und menschliche Freigaben orchestrieren. Mehrere Agenten sind nur eine mögliche Form von Nodes und nicht der Grund, einen Graphen einzuführen. ## Related - Zeigt, wie explizite Zustände unerlaubte Phasenwechsel verhindern.: agent-state-machines-seatbelts - Erklärt den Wechsel vom Prompt zur beobachtbaren Orchestrierung.: next-prompt-is-a-workflow - Ordnet Routing, State, Verification und Recovery in den gesamten Agent Harness ein.: harness-engineering-field-guide - Vertieft Evidenz-Gates für Retrieval-Workflows.: rag-evidence-set-contracts ## Source References - [Graph-Based Agentic AI with LangGraph](https://arxiv.org/abs/2607.19297) (paper) - [Ancillary source package](https://arxiv.org/e-print/2607.19297) (source code) - [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview) (official documentation) - [LangGraph Graph API](https://docs.langchain.com/oss/python/langgraph/graph-api) (official documentation) - [LangGraph persistence](https://docs.langchain.com/oss/python/langgraph/persistence) (official documentation) - [LangGraph interrupts](https://docs.langchain.com/oss/python/langgraph/interrupts) (official documentation) - [LangGraph Functional API](https://docs.langchain.com/oss/python/langgraph/functional-api) (official documentation) - [ReAct](https://arxiv.org/abs/2210.03629) (paper) - [DSPy](https://arxiv.org/abs/2310.03714) (paper) - [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) (engineering report)