Constantin, Consultant für GenAI bei Pexon Consulting | 10 Min. Lesezeit | 16.09.2026
TL;DR: orchestrierung oder langgraph
Orchestrierung oder LangGraph ist 2026 die Schnittfrage vor dem Framework-Streit: reicht eine Graph-Library für Zustand und Tools, oder brauchen Routing, Hybrid Search und Evaluation eine Schicht darüber. LangGraph bleibt Runtime. Die Control Plane bleibt LiteLLM. Azure AI Foundry ist Fläche, nicht zweite Marke.
| Frage | Antwort in einem Satz |
|---|---|
| Library reicht | Ein Graph, klare Tools, ein Team besitzt den Code |
| Schicht nötig | Keys, Budget, Audit, mehrere Flächen, messbarer Task-Erfolg |
| Nicht verwechseln | GraphRAG ist Retrieval, nicht Graph-Orchestrierung |
Das Problem: die Ausschreibung listet Frameworks, nicht Schichten
Teams bekommen eine Liste: LangChain, LangGraph, Semantic Kernel, AutoGen. Dazu Evaluation und Betrieb. Die Frage klingt wie ein Tutorial. Sie ist eine Architekturentscheidung für IT-Leitung und AI Engineering zugleich.
Wer zuerst das Framework installiert, baut oft einen zweiten Chat mit Zustandsgraph. Keys liegen noch im Client. Budget und Audit fehlen. Routing zwischen Modellen steckt in if-Zweigen. Evaluation bleibt Notebook.
Wir sehen das Muster in Anfragen mit Python-Teams und Tool Calling: der Runtime-Kern ist klar, die Schicht darüber nicht. Genau dort scheitert der Sprung vom POC in den Tenant.
Diese Seite beantwortet nicht „wie baue ich einen Graphen“. Dafür bleibt die LangGraph-Agent-Entwicklung. Hier geht es um den Schnitt davor.
Wann reicht LangGraph als Library?
LangGraph reicht, wenn Ihr Problem ein Graph-Problem ist: Verzweigung, Zustand, Tool-Loop, Retry, menschliche Freigabe im Pfad. Ein Team besitzt den Code. Ein Modellbackend reicht für den Start. Die Datenklasse ist geklärt.
Dann ist LangGraph die richtige Runtime. Nodes und Edges gehören in Ihr Repo. Tests laufen gegen den Graphen. Der Deploy hängt hinter Ihrer API. Ein zweites Produkt mit dem Namen Orchestrierung brauchen Sie dafür nicht.
Drei Signale, dass die Library genügt:
- Ein fachlicher Ablauf mit wenigen Tools, nicht fünf Chat-UIs mit eigenen Keys.
- Evaluation am Graphen selbst: feste Cases, feste Assertions, CI.
- Kein Spend- und Team-Routing über mehrere Modelle und Flächen.
Trifft das zu, stoppen Sie hier und bauen die Runtime. Pexon baut solche Graphen, wenn der Check sie braucht. Wir verkaufen LangGraph nicht als Plattform.
Praktisch heißt das: ein Ticket-Router mit drei Tools und einer Freigabe-Stufe darf in LangGraph leben. Ein unternehmensweiter Assistent mit Copilot in Office, Foundry für Fachdaten und einem Embed in der Fach-App darf das nicht allein tragen. Der Unterschied ist nicht der Hype um Agents. Der Unterschied ist, wer Keys und Budget besitzt.
Wann brauchen Sie Routing und Evaluation außerhalb des Graphen?
Die Schicht wird nötig, sobald der Graph nur noch ein Client unter mehreren ist. Open WebUI oder Foundry als Fläche. Embed in einer Fach-App. n8n für Workflows. Derselbe Key-Pool. Dieselbe Budget-Grenze. Derselbe Audit-Trail.
Dann reicht „ein Graph mit Tools“ nicht. Es braucht eine Control Plane: Keys, Teams, Routing, Spend, Failover. Bei Pexon ist das LiteLLM, siehe LiteLLM-Hub. Foundry ersetzt diese Plane nicht. Foundry ist die Microsoft-Fläche an derselben Plane, live unter Azure AI Foundry.
Evaluation außerhalb des Graphen heißt: Task-Erfolg und Halluzination für den Assistenten, nicht nur Node-Unit-Tests. Faithfulness allein sagt nicht, ob das Ticket gelöst wurde. Die Methoden-Nachbarschaft bleibt RAG evaluieren und testen. MLflow und Ragas gehören in Betrieb und Eval, nicht in eine zweite Runtime-LP.
Kurz: Library orchestriert den Ablauf. Die Schicht orchestriert den Betrieb.
Betrieb heißt bei uns 8×5 auf der App-Schicht, nicht 24/7. Cloud und Tokens zahlen Sie direkt. Ohne Enablement im Monat bleibt die Plane ungenutzt und wandert in Schatten-KI. Das ist kein Framework-Thema. Das ist Adoption.
Flaeche Foundry / Open WebUI / Embed
Plane LiteLLM: Keys, Routing, Spend, Audit
Runtime LangGraph nur wenn Graph-State der Engpass ist
Wissen eine RAG-Quelle im Setup, nicht GraphRAG-ProduktSemantic Kernel, AutoGen und der Showdown, den Sie nicht brauchen
Semantic Kernel und AutoGen erscheinen in Ausschreibungen, weil sie Microsoft- oder Multi-Agent-Folien füllen. Das ändert die Schnittfrage nicht.
| Baustein | Passt, wenn | Ersetzt nicht |
|---|---|---|
| LangGraph | Graph-State, Tool-Loop, Python-Haus | Keys, Budget, Audit |
| Semantic Kernel | .NET-/Microsoft-Plugin-Ökosystem | die Control Plane |
| AutoGen / Multi-Agent | Experimente mit Agenten-Rollen | Hybrid Search und Eval-Gates |
| LangChain allein | Chains und Integrationen | langlebigen Graph-State |
AutoGen in der Ausschreibung markiert oft den Multi-Agent-Wunsch, nicht den Betrieb. Rollen-Experimente gehören in einen Spike. Keys, Budget und Audit gehören in die Plane, bevor drei Agenten sich gegenseitig Tokens schicken. Sonst messen Sie Chaos, nicht Task-Erfolg.
Framework-Showdowns und „X vs LangGraph“-Blogs beantworten Tool-TOFU. Sie beantworten nicht, ob Sie eine Plane brauchen. Wer zehn Vergleiche liest und keine Schicht baut, bleibt beim zweiten Chat. Ein Spike mit zwei Frameworks in einer Woche ist billiger als ein Jahr doppelte Keys.
Für den Produkt-Job Harness und bauen-vs-kaufen bleibt die Agenten-Plattform. Das ist nicht diese Seite. Der Pfad heißt bewusst nicht nacktes /agenten/.
Graph-Orchestrierung ist nicht GraphRAG
Zwei Wörter mit „Graph“, zwei Jobs.
Graph-Orchestrierung: Zustand, Verzweigung, Tool-Loop. Runtime oft LangGraph. Canonical bleibt KEEP.
GraphRAG: Retrieval über Wissensgraph plus Chunks. Kein Produktname auf der offenen Plattform. Im Setup der App-Schicht liegt zuerst eine RAG-Quelle, typisch Vektor über pgvector oder Qdrant. Ob klassisches RAG reicht, ist eine eigene Entscheidung unter Setup und Wissen, nicht unter LangGraph.
Wer GraphRAG kauft, weil die Folie „Graph“ sagt, mischt Retrieval und Runtime. Das teure Ergebnis ist ein Index ohne Owner und ein Graph ohne Plane.
Ein zweites Missverständnis: MCP. Werkzeuge als Schema hinter der Plane sind nicht dasselbe wie ein LangGraph-Node. MCP erklärt das Protokoll. Die Plane hält die Keys. Der Graph ruft Tools. Drei Schichten, drei Jobs. Auf der Mutter liegt Tools-MCP live. Der KEEP-Leitfaden bleibt Was-ist. Hier nicht klonen.
n8n bleibt Workflow, nicht die Plattform. LibreChat und Open WebUI bleiben Chat-UI, nicht die Plane. Wer die UI zur Orchestrierung erklärt, baut den nächsten Schatten-Stack.
Production Gap: POC auf dem Laptop, Schicht im Tenant fehlt
Der Graph läuft lokal. Tool Calling funktioniert in der Demo. Dann kommt der Tenant: Entra-SSO, Budget pro Team, Audit für Revision, Foundry als Fläche oder Open WebUI, eine Wissensquelle, Guardrails fail-closed, Betrieb 8×5.
Genau dieser Sprung ist der Production Gap im Tenant. Die Library löst ihn nicht. Die offene KI-Plattform beschreibt die Marke. Das Setup beschreibt den Bau der App-Schicht. Listenpreise gehören nicht in diesen Blog und nicht auf KEEP-Seiten.
Was im Setup der ersten Wochen typisch liegt: Plane, eine Fläche, SSO, eine RAG-Quelle, Policy fail-closed, Monitoring-Minimum, Handover in Ihr Repo. Was nicht liegt: Hermes als Pflicht, Hintergrund-Agenten Stufe 2 bis 4, 24/7, GPU-Cluster als App-Schicht, SharePoint-Intranet, Cost-Router als Extra-Produkt.
Wir trennen Check, optionalen Workshop und Setup bewusst. Der Check dauert 45 Minuten. Er ersetzt kein Build. Er verhindert, dass Sie ein Framework kaufen, wo eine Plane fehlt, oder eine Plane kaufen, wo ein Graph gereicht hätte.
Häufig gestellte Fragen
Ist Orchestrierung oder LangGraph dasselbe wie eine KI-Agenten-Plattform?
Nein. Die Agenten-Plattform verkauft Harness und den Make-or-Buy-Job. Dieser Text ist der Schnitt Library gegen Schicht. Runtime-Bau bleibt auf der LangGraph-KEEP-Seite.
Ersetzt Azure AI Foundry LangGraph?
Nein. Foundry ist Fläche im Microsoft-Haus an der Control Plane. LangGraph bleibt optionaler Runtime-Kern für Graph-State. Foundry ersetzt LiteLLM nicht.
Brauche ich Semantic Kernel, wenn wir Microsoft nutzen?
Nur wenn das Plugin- und .NET-Ökosystem der Engpass ist. Für Python-Teams mit Graph-State bleibt LangGraph oft der Runtime-Kern. Die Plane bleibt trotzdem LiteLLM.
Wann reicht Evaluation im Graphen, wann brauche ich ein Gate in Produktion?
Unit-Tests am Graphen reichen für den Code-Pfad. Sobald Fachbereiche den Assistenten nutzen, brauchen Sie Task-Erfolg und Halluzinations-Checks außerhalb des Notebooks. Sonst rollt flüssiger Unsinn aus.
Sollen wir GraphRAG bauen, weil wir LangGraph nutzen?
Nein. LangGraph orchestriert Abläufe. GraphRAG ist ein Retrieval-Muster. Starten Sie mit einer klaren RAG-Quelle. Eskalieren Sie erst, wenn Multi-Hop und Entitäten den Vektor schlagen.
Nächster Schritt
Die Framework-Liste ist entschieden, wenn Sie Library und Schicht trennen. LangGraph baut den Graphen. LiteLLM trägt Keys und Audit. Foundry bleibt Fläche. Der nächste konkrete Schritt ist der Plattform-Check, nicht ein zweites Tutorial und nicht ein dritter Framework-Spike ohne Plane. Die Entscheidung Library gegen Schicht spart Ihnen den teuren Umweg über drei Frameworks ohne Plane.
Plattform-Check buchen (45 Min)
