Google baut Determinismus in Agenten ein: Warum ADK 2.0 mehr Workflow-Runtime als Agent-SDK ist

Google hat mit ADK 2.0 für Go und dem begleitenden Architekturtext „Why we built ADK 2.0“ eine ziemlich klare Botschaft geliefert. Die eigentliche Nachricht ist nicht bloß ein Versionssprung für ein SDK. Google versucht, Agenten-Orchestrierung aus dem diffusen Prompt-Raum herauszuziehen und stärker in eine kontrollierbare Workflow-Laufzeit zu verlagern.

Genau das macht die Ankündigung für menzel.works interessant. Denn viele Agenten-Projekte scheitern nicht daran, dass noch ein Modell fehlt. Sie scheitern daran, dass LLMs plötzlich Routing, Fehlerbehandlung, Freigaben und Geschäftslogik improvisieren sollen, obwohl diese Aufgaben in normaler Software besser in deterministischem Code aufgehoben sind.

ADK 2.0 ist damit weniger ein neues Agenten-Toolkit als ein Signal für die nächste Reifestufe agentischer Software.

Was Google konkret neu ausrollt

Im Zentrum von ADK Go 2.0 steht ein graphbasierter Workflow-Ansatz. Agentische Anwendungen werden nicht mehr nur als lose Tool-Loop gedacht, sondern als gerichteter Ablauf aus Knoten und Kanten, inklusive Verzweigungen, Fan-out/Fan-in, Schleifen und Teil-Workflows.

• Graph-basierte Workflows als erstklassige Struktur für Multi-Agent- und Tool-Abläufe
• Human-in-the-Loop als eingebautes Primitive statt improvisierter Sonderlogik
• Dynamische Orchestrierung in normalem Go-Code, wenn ein Ablauf erst zur Laufzeit feststeht
• Retries, Timeouts und Concurrency-Steuerung direkt auf Node-Ebene
• Ein gemeinsames Runtime-Modell für einzelne LLM-Agenten und komplexe Graphen

Dazu kommt ein Gedanke, den Google im zweiten Beitrag sehr direkt formuliert: LLMs sollen nicht länger unnötig klassische Ablaufsteuerung übernehmen. Wenn klar ist, dass Schritt B immer auf Schritt A folgt, dann ist es teuer, langsam und fehleranfällig, das jedes Mal vom Modell neu entscheiden zu lassen.

Warum das wichtiger ist als ein normales Framework-Update

Der spannende Teil steckt für mich nicht in einem einzelnen API-Detail. Spannend ist, dass Google damit eine Grenze sauberer zieht: Modelle für unklare, sprachliche, mehrdeutige Aufgaben – Workflow-Code für Routing, Reihenfolge, Wiederholungen und Freigaben.

Das klingt erst einmal nüchtern, ist aber praktisch enorm relevant. Gerade in produktiven Agent-Setups entstehen die meisten Probleme nicht bei einer schönen Demo-Frage, sondern an Stellen wie diesen:

• Ein Agent überspringt unter leicht veränderten Bedingungen einen Pflichtschritt.
• Ein Tool-Fehler wird nicht sauber behandelt und der Ablauf läuft halb kaputt weiter.
• Ein Freigabeschritt wird als Prompt-Anweisung modelliert, aber nicht als echte Sperre durchgesetzt.
• Kontext wächst über viele Turns so stark an, dass der Agent unsauber routet oder in Schleifen kippt.

ADK 2.0 ist Googles Antwort auf genau diese Betriebsschicht. Die Plattform sagt im Kern: Lasst das Modell dort denken, wo Denken gebraucht wird, und lasst den Rest wieder stärker wie Software ablaufen.

Der eigentliche Strategiewechsel: weniger Agenten-Romantik, mehr Ablaufkontrolle

Besonders deutlich wird das im Architekturtext zu ADK 2.0. Google argumentiert dort explizit gegen den Reflex, jedes Business-Problem als vollständig autonomen Agenten zu modellieren. Wenn ein Prozess vorgegeben ist, soll er deterministisch laufen. Das Modell kommt nur an Stellen hinein, an denen Mehrdeutigkeit, Klassifikation, Textarbeit oder offene Entscheidungssituationen auftreten.

Das ist eine wichtige Korrektur zum Agenten-Hype der letzten Monate. Viele Anbieter haben Agenten zunächst so verkauft, als müsse das LLM automatisch auch die Orchestrierung übernehmen. ADK 2.0 macht nun viel deutlicher: Autonomie allein ist kein Qualitätsmerkmal, wenn Zuverlässigkeit, Kosten und Auditierbarkeit wichtiger werden.

Damit nähert sich Google einer Architektur an, die man aus belastbaren Softwaresystemen kennt: feste Ablaufkanten, klar definierte Zustände, kontrollierte Unterbrechungen, Wiederaufnahme nach Fehlern und möglichst wenig implizite Magie.

Was das für Entwickler und Teams praktisch ändert

Für Teams, die wirklich mit Agenten bauen, ist diese Richtung ziemlich nützlich.

• Erstens: Human-in-the-loop wird vom Sonderfall zum Standardwerkzeug. Freigaben für Deployments, Ausgaben, Mails oder Dateiänderungen lassen sich sauber als Unterbrechung modellieren.
• Zweitens: Multi-Agent-Setups werden besser beherrschbar, weil Delegation nicht nur promptbasiert, sondern als Workflow-Struktur organisiert wird.
• Drittens: Retries, Timeouts und Resume-Verhalten wandern in die Laufzeit statt in individuelle Bastellogik.
• Viertens: Der Entwickler bekommt ein klareres Kriterium, wann ein Agent überhaupt sinnvoll ist – und wann klassischer Workflow-Code die bessere Wahl bleibt.

Gerade dieser letzte Punkt ist wichtiger, als es klingt. In vielen Teams spart man Zeit, Kosten und Ärger, wenn man nicht jede Prozessstufe dem Modell überlässt.

Wie das in Googles größere Agent-Strategie passt

ADK 2.0 steht nicht isoliert da. In den letzten Wochen hat Google an mehreren Stellen gezeigt, wohin die Reise geht: Genkit bekam Middleware und Governance-Schichten, ADK rückte näher an Android- und Hybrid-Workflows, und die Interactions API wurde zur primären Betriebsfläche für Gemini-Agenten.

ADK 2.0 ergänzt diese Linie um die eigentliche Ablaufmaschine. Wenn man es zuspitzen will, baut Google gerade nicht nur Agenten-Features, sondern Stück für Stück eine komplette Betriebs- und Entwicklungsumgebung für agentische Software.

Wo die Grenzen trotzdem bleiben

Natürlich löst auch ADK 2.0 nicht alle Agentenprobleme. Ein Workflow-Graph macht schlechte Tool-Definitionen nicht automatisch gut. Er ersetzt auch keine vernünftigen Evals, keine Rechteverwaltung und keine klare Produktlogik.

Außerdem sollte man Googles Beispielzahlen zu Token- und Latenzgewinnen nicht überbewerten. Sie illustrieren den Architekturpunkt, sind aber kein universeller Benchmark für jede Anwendung.

Trotzdem halte ich die Richtung für richtig. Wenn Agenten aus Demos in belastbare Arbeitssoftware kippen sollen, braucht es genau diese Verschiebung: weg von maximaler Modellfreiheit, hin zu klarerer Laufzeitkontrolle.

Fazit

Google zeigt mit ADK 2.0 etwas Wichtigeres als ein neues Agent-Framework-Feature. Die Firma zieht eine neue Grenze zwischen Modell und System. LLMs sollen dort eingesetzt werden, wo sie Mehrwert liefern – nicht dort, wo deterministische Software seit Jahren verlässlicher arbeitet.

Für die nächste Phase agentischer Tools ist das ein starkes Signal. Die spannendsten Plattformen werden wahrscheinlich nicht die sein, die Agenten maximal frei laufen lassen. Spannender werden die Plattformen, die Autonomie, Freigaben, Workflow-Code und Wiederaufnahme sauber zusammensetzen.

KI-Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt und redaktionell bearbeitet.

Quellen

• Google Developers Blog: Build reliable multi-agent applications with ADK Go 2.0 (30.06.2026)
• Google Developers Blog: Why we built ADK 2.0 (01.07.2026)
• Google Developers Blog: Build agentic full-stack apps with Genkit (01.07.2026) – zur Einordnung der Parallelbewegung bei Googles App-Framework