LangGraph gegen Google ADK im Jahr 2026: Explizite Orchestrierung oder Agentenkomposition

Jeder, der heute einen Produktionsagenten entwickelt, stößt auf denselben überfüllten Markt: LangGraph, Google ADK, das OpenAI Agents SDK, PydanticAI, CrewAI, AutoGen, LlamaIndex und vermutlich noch ein weiteres Framework, das während des Schreibens dieser Liste entstanden ist. Die instinktive Frage lautet, welches Framework am besten ist – doch das ist der falsche Ausgangspunkt. Eine bessere Frage ist, wo das Framework Entscheidungen treffen sollte und wo die Anwendung die Kontrolle behalten muss.

So gestellt wird der Vergleich zwischen LangGraph und Googles Agent Development Kit (ADK) im Jahr 2026 interessanter, als es der alte Slogan „Graphen gegen Agenten“ vermuten lässt. Beide können ausgefeilte Agenten erstellen. Was sie voneinander unterscheidet, ist, wo die Kontrolle liegt, welche Standardfunktionen bereits integriert sind und wie viel Orchestrierungskomplexität das Team auf sich nimmt.

Die beiden Frameworks nähern sich an

Ältere Vergleiche ziehen eine klare Linie: LangGraph ist eine graphbasierte Orchestrierung auf niedrigem Niveau, während ADK ein auf höherem Niveau angesiedeltes Mehr-Agenten-Framework ist. Das gilt zwar noch immer teilweise, lässt aber viele Aspekte unberücksichtigt.

LangGraph ist um explizite Knoten, Zustände, Übergänge, Persistenz, Wiederholungsversuche sowie eine feine Steuerung der Ausführung organisiert. Sein Design setzt stark auf zuverlässige Ausführung, Prozesse mit menschlicher Beteiligung, Zustandsverwaltung sowie klar definierte Orchestrierungsmechanismen.

ADK umfasst mittlerweile ebenfalls mehrere Orchestrierungsstile:

• graphbasierte Workflows
• dynamische Workflows
• kollaborative Mehr-Agenten-Workflows
• deterministische Ausführungsknoten
• von Agenten gesteuerte Delegation

In ADK 2.x kann ein Graph LLM-Agenten, einfache Funktionen, Tools, Routing-Logik, Zustände sowie menschliche Eingaben miteinander kombinieren. Daher liegt die Wahl nicht mehr zwischen Graphen und Agenten, da jedes Framework beides leisten kann. Was sich unterscheidet, ist die Art und Weise, wie das System aufgebaut wird.

Wie LangGraph denkt

LangGraph wird zunächst als Orchestrierungsengine verstanden. Die Gestaltung beginnt mit einer Reihe von Fragen: Wie ist der Zustand? Was ändert ihn? Wohin kann die Ausführung als Nächstes gehen? In bildlicher Darstellung sieht der Ablauf so aus:

State
  ↓
Node
  ↓
Decision
 ↙   ↘
A     B
↓     ↓
Tool  Agent
 \     /
  ↓   ↓
 Validation
     ↓
    End

Der Graph hier ist mehr als nur eine Verbindungsanlage. Er wird Teil der Architektur, was sich auszahlt, wenn das System wichtige, deterministische Geschäftslogik enthält. Ein Workflow kann benötigen:

• anzuhalten und auf die Freigabe durch eine Person zu warten
• eine fehlgeschlagene Operation erneut auszuführen
• sich nach einem Ausfall eines Tools zu erholen
• von einem gespeicherten Zustand aus fortzusetzen
• basierend auf strukturierten Daten abzweigen
• zwischen Modellaufrufen gewöhnlichen Code ausführen
• den Zustand über lang andauernde Aufgaben hinweg beibehalten

LangGraph macht jede dieser Aspekte explizit, was ein starkes Modell darstellt. Der Nachteil ist, dass das Team mehr Verantwortung für die Orchestrierungsplanung trägt.

Wie ADK denkt

ADK kommt einem Agenten-Anwendungsframework näher. Anstatt von einer Zustandsmaschine auszugehen, kann die Gestaltung von Agenten ausgehen:

Coordinator
├── Specialist Agent
├── Specialist Agent
├── Specialist Agent
└── Specialist Agent

Jeder Agent kann seine eigenen Anweisungen, Werkzeuge, Verantwortlichkeiten, Grenzen, Unteragenten sowie Modell-Einstellungen mitführen. Das Framework bietet anschließend mehrere Koordinierungswege an. Ein relativ autonomes System kann es einem Koordinator ermöglichen, die Arbeit an Spezialisten weiterzuleiten. Ein vorhersehbarer Prozess kann Graph-Orchestrierung nutzen. Arbeiten, die sich leichter in Code ausdrücken lassen, können dynamische Workflows verwenden.

Der attraktive Aspekt moderner ADK-Lösungen besteht darin, dass sie bewusst gestaltete Agentenabstraktionen bereitstellen, ohne darauf bestehen zu müssen, dass jeder Schritt von einem LLM gesteuert wird. Wenn die Zuverlässigkeit es erfordert, kann die Ausführung auf deterministischen Code herabgestuft werden.

Die zentrale Frage: Wer kontrolliert den Workflow?

Das ist vermutlich das Erste, was bei der Entscheidung zwischen den beiden Ansätzen geklärt werden muss. Stellen Sie sich zwei Extreme vor.

Hauptsächlich deterministisch

Der Prozess ist bereits Schritt für Schritt bekannt:

Receive request
→ validate
→ retrieve information
→ classify
→ call service
→ validate result
→ human approval if necessary
→ respond

Das Modell fügt Intelligenz in den Prozess ein, während die Anwendung den Prozess selbst steuert. Das entspricht der Art und Weise, wie LangGraph Entwickler dazu anregt, bestimmte Wege zu denken, und ADK-Graphen-Workflows können nun denselben Stil abbilden.

Hauptsächlich agentgesteuert

Hier ist das Ziel bekannt, doch die Reihenfolge der Schritte nicht:

User goal
   ↓
Coordinator
   ↓
Which specialist is needed?
   ↓
Delegate
   ↓
Maybe call another specialist
   ↓
Synthesize

In diesem Fall ist die Koordination teilweise semantischer Natur, und ADKs kooperatives Multi-Agenten-Modell passt dazu ideal. Auch LangGraph kann dieses Muster sicherlich umsetzen. Die Fähigkeit dazu steht außer Frage. Entscheidend ist, welche Abstraktion am besten zur bereits gewünschten Architektur passt.

LangGraphs Stärke: expliziter Zustand

Der Zustand erscheint langweilig, bis ein Agent in die Produktion eintritt – dann wird er zu einem der wichtigsten Bestandteile des Systems. Die Betreiber benötigen Antworten auf Fragen wie diese:

What has already happened?What did the previous agent produce?Which tools were executed?What has been validated?What still needs approval?Where should execution resume?What should the next node actually see?

LangGraph bewahrt den gemeinsamen Zustand in der Mitte seines Programmiermodells auf, sodass Transitions sichtbar sind. Zudem fördert es eine nützliche Disziplin: Man sollte einen strukturierten Zustand beibehalten, anstatt alles in einen weiteren riesigen Prompt zu packen. Der Anwendungsstatus und der Modellkontext sollten nicht automatisch dasselbe sein, und diese Lücke wird mit dem Wachstum von Agentensystemen größer.

Stärke von ADK: Zusammenstellung von Agenten

Die beste Abstraktion von ADK besteht darin, wie leicht spezialisierte Agenten zu Bausteinen werden. Anstatt eines riesigen Agenten mit einem umfangreichen Systemprompt werden die Verantwortlichkeiten getrennt:

                Coordinator
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Research       Domain        Action
     Agent          Agent         Agent
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Validation

Das ist wichtig, denn das Design mehrerer Agenten sollte nicht bedeuten, weitere Agenten zu erstellen. Es sollte vielmehr darum gehen, sinnvolle Grenzen zu ziehen. Ein Spezialist verdient es, zu existieren, wenn die Isolierung seines Kontexts, seiner Tools, Berechtigungen, Verantwortlichkeiten, seines Modells oder seiner Bewertungskriterien zu einer besseren Architektur führt. Ohne das ist ein weiterer Agent lediglich ein weiterer Modellaufruf mit einem cleveren Namen.

Mehr Agenten bedeuten kein besseres System

Ein sehr häufiger Fehler besteht darin, diese Arithmetik anzunehmen:

1 agent = simple
5 agents = sophisticated
20 agents = extremely sophisticated

So funktioniert das nicht. Jeder zusätzliche Agent kann weitere Modellaufrufe, weitere Anfragen, weiteren Kontext, weitere Übertragungen, weitere Möglichkeiten zum Scheitern, weitere Bewertungsgrenzen, mehr Latenz, mehr Token sowie mehr Debugging mit sich bringen.

Bevor man einen zusätzlichen Agent hinzufügt, sollte man prüfen, welche Fähigkeit dadurch wirklich verbessert wird – schließlich ist diese Verantwortung isoliert. Solide Gründe sind beispielsweise ein eigenständiges Werkzeugset, strengere Sicherheitsberechtigungen, ein separater Kontext, ein anderes Modell, eine eigene Bewertung, eine Spezialisierung, die wiederverwendet werden kann, oder Aufgaben, die parallel ausgeführt werden können. „Eine Multi-Agent-Architektur klingt besser“ gehört nicht zu dieser Liste.

Die Schlussfolgerung

Die nützlichste Gliederung ist nicht Grafiken gegenüber Agenten. Es geht vielmehr um explizite Orchestrierung gegenüber agentenzentrierter Komposition. LangGraph beginnt mit dem Workflow, seinem Zustand sowie den Steuermechanismen dazu. ADK beginnt mit Agenten, die Werkzeuge nutzen und zusammenarbeiten, und fügt anschließend weitere explizite Workflow-Funktionen hinzu. Die nächsten Fragen, sobald eine dieser Ansätze in die Produktion übergeht, betreffen Context Engineering, Verträge, Ausführung mit menschlicher Beteiligung, Überwachbarkeit und Bewertung.