Google bringt ADK nach Kotlin und Android: Warum Agenten jetzt näher an private Hybrid-Workflows rücken

Google hat ADK 0.1.0 für Kotlin und zusätzlich ADK für Android angekündigt. Auf dem Papier sieht das erst einmal wie eine Spracherweiterung für ein bestehendes Framework aus. Für menzel.works ist die spannendere Nachricht aber eine andere: Google schiebt Agenten damit deutlich näher an reale Hybrid-Workflows aus Cloud, App und On-Device-KI.

Das ist relevanter, als es auf den ersten Blick wirkt. Denn viele KI-Anwendungen scheitern nicht daran, dass ihnen ein weiteres Modell oder ein weiteres SDK fehlt. Sie scheitern daran, dass sensible Nutzerdaten nicht sauber lokal bleiben, dass Mobilgeräte nur als dünne Oberfläche behandelt werden oder dass Agenten nicht sauber zwischen Cloud-Reasoning und lokaler Ausführung aufgeteilt werden können.

Genau an dieser Stelle setzt Google mit ADK für Kotlin und Android an. Die Plattform soll es einfacher machen, Agenten in Kotlin-Backends und Android-Apps so zu bauen, dass sie zwischen Cloud und Gerät delegieren können, ohne dass Entwickler diese Orchestrierung komplett von Hand verdrahten müssen.

Was Google konkret neu ausrollt

Laut Google bringt ADK für Kotlin agentische Bausteine in klassische Kotlin- und JVM-Projekte. Dazu gehören LLM-Agenten, Workflow-Agenten, Multi-Agent-Setups, Function Tools, MCP-Tools, A2A, Session State, Memory Services, Telemetry und eine Web-Oberfläche für Entwicklung und Tests.

Mit ADK für Android kommt zusätzlich eine spezialisierte Android-Variante dazu. Sie soll vor allem das Zusammenspiel zwischen On-Device-Modellen und Cloud-Modellen vereinfachen. Google nennt dabei mehrere konkrete Punkte:

• Hybrid Orchestration: Ein Cloud-Modell kann als Orchestrator arbeiten und Aufgaben an Sub-Agenten auf dem Gerät delegieren.
• On-Device Sequential Agents: Teilaufgaben lassen sich lokal nacheinander abarbeiten.
• Local Retrieval: Dokumente können direkt auf dem Gerät ausgewertet werden, damit sensible Inhalte nicht hochgeladen werden müssen.
• Flexible Tooling: Tools, Instruktionen und Sub-Agenten lassen sich als kontrollierte Agentenstruktur kombinieren.

Für Android nennt Google ausdrücklich drei Modellzugänge:

• ML Kit GenAI für On-Device-Zugriff auf Gemini Nano über AI Core,
• Firebase AI Logic für Gemini-Modelle in der Cloud,
• Google GenAI für schnelles Prototyping.

Google begründet den Schritt auch mit Reichweite: Gemini Nano sei inzwischen auf mehr als 140 Millionen Android-Geräten verfügbar. Damit wird On-Device-KI aus Googles Sicht nicht mehr zur Sonderlösung, sondern zur ernsthaften Plattformfläche.

Warum das mehr ist als nur ein neues SDK

Ich glaube, der eigentliche Punkt ist nicht Kotlin. Der eigentliche Punkt ist, dass Google hier ein ziemlich klares Architekturmodell normalisiert: Die Cloud denkt, das Gerät handelt lokal, und beides wird als ein gemeinsamer Agenten-Workflow behandelt.

Genau das ist für viele praktische KI-Produkte interessant. Wenn ein Assistent Reiseunterlagen, Rechnungen, Fotos, PDF-Anhänge oder andere sensible Dokumente auswerten soll, ist es oft unattraktiv, alles stumpf in die Cloud zu kippen. Gleichzeitig reicht ein reines On-Device-Modell für komplexere Orchestrierung, Dialogführung oder mehrstufige Entscheidungen oft noch nicht aus.

Googles Antwort darauf lautet jetzt: Hybrid statt entweder-oder. Der Hauptagent kann in der Cloud orchestrieren, während lokale Sub-Agenten private Daten auf dem Gerät prüfen, extrahieren oder validieren. Genau dieses Modell zeigt Google auch im offiziellen Reiseassistenten-Beispiel.

Der größere Trend: Agenten wandern tiefer in App- und Geräte-Logik hinein

Für menzel.works passt diese Meldung gut in einen breiteren Trend. Bei Google Antigravity war der Kern, dass Agenten als gemeinsame Plattform für Editor, Terminal und Browser gedacht werden. Bei Genkit Middleware ging es darum, Agenten kontrollierbarer und produktionsnäher zu machen.

ADK für Kotlin und Android ergänzt jetzt die Geräte-Seite dieser Strategie. Google baut nicht nur Agenten für Entwickler-Tools und Cloud-Runtimes, sondern schiebt dieselbe Logik näher an das Betriebssystem, an Apps und an lokale Datenquellen.

Das ist strategisch ziemlich klug. Denn wenn Agenten dauerhaft nützlich werden sollen, müssen sie nicht nur chatten oder Code erzeugen. Sie müssen:

• in bestehende App-Flows passen,
• private Daten möglichst lokal behandeln,
• über verschiedene Modellklassen hinweg delegieren,
• und für Entwickler mit vertretbarem Aufwand wartbar bleiben.

Was daran praktisch stark ist

Es gibt an diesem Launch ein paar Punkte, die ich wirklich relevant finde.

Erstens: Google verbindet Agenten hier nicht nur mit Server-Logik, sondern mit echter Android-Produktrealität. Das ist wichtiger als viele große Modellankündigungen, weil es direkt in Produktentwicklung hineinreicht.

Zweitens: Local Retrieval ist keine Kleinigkeit. Sobald Dokumente, Mails, Anhänge oder Nutzerdaten lokal analysiert werden können, entsteht eine glaubwürdigere Datenschutz- und Latenzgeschichte als bei reinen Cloud-Agenten.

Drittens: Das Kotlin-Ökosystem bekommt damit einen nativeren Zugang zu Googles Agenten-Stack. Wer auf JVM-Backends, Android oder gemischten mobilen Infrastrukturen arbeitet, muss sich weniger zwischen KI-Experiment und Produktcode zerreißen.

Viertens: Dass ADK gleichzeitig Multi-Agenten, Tools, Session State, Memory, Telemetry und eine Dev-Weboberfläche mitbringt, zeigt, dass Google nicht bloß eine Modellbindung ausliefert, sondern ein vollständigeres Framework platzieren will.

Was man trotzdem nüchtern sehen sollte

Natürlich ist das noch kein fertiger Marktumbruch. Google spricht ausdrücklich von einer 0.1.0-Version. Das ist ein experimenteller Start und kein Zeichen dafür, dass mobile Agenten schon als ausgereifte Standardarchitektur gelten sollten.

Auch die Hybrid-Idee löst nicht automatisch alle Probleme. Wer Cloud-Orchestrierung, lokale Modelle, Session State, Tools und sensible Daten kombiniert, holt sich neue Fragen bei Testing, Rechteverwaltung, Beobachtbarkeit und Kostensteuerung ins Haus.

Und nicht jeder Use Case braucht überhaupt diese Komplexität. Viele mobile KI-Features bleiben mit einem klaren Inferenz-Call oder einem kleinen Assistenzfluss einfacher und robuster als mit einem echten Multi-Agent-Setup.

Trotzdem halte ich den Schritt für wichtig, weil Google hier nicht nur von Agenten redet, sondern eine glaubwürdige technische Brücke zwischen On-Device-KI, Cloud-Reasoning und realer App-Entwicklung baut.

Mein Fazit

ADK für Kotlin und Android ist vor allem deshalb spannend, weil Google Agenten aus der reinen Cloud- und Demo-Ecke herausholt und näher an private, dauerhafte App-Workflows bringt.

Die größere Botschaft lautet nicht einfach „jetzt auch Kotlin“. Die größere Botschaft lautet: Agenten sollen dort arbeiten, wo echte Nutzerdaten, echte Geräte und echte Produktlogik sitzen. Und dafür setzt Google zunehmend auf hybride Architekturen statt auf ein starres Alles-in-die-Cloud-Modell.

Wenn sich diese Linie durchsetzt, wird der Wettbewerb bei Agenten nicht nur über Benchmarks oder Chat-Oberflächen entschieden. Dann zählt stärker, welcher Stack Cloud-Modelle, lokale Modelle, Datenschutz und App-Integration am saubersten zusammenbringt.

Weiterführende Beiträge auf menzel.works

• Google zieht Gemini CLI in Antigravity um
• Google baut Middleware für Agenten
• Gemini API bekommt Webhooks

Quellen

• Google Developers Blog: Announcing ADK for Kotlin and ADK for Android 0.1.0: Building AI Agents on Android and Beyond (21.05.2026)
• ADK Docs: Kotlin Quickstart / ADK Overview (abgerufen am 24.05.2026)
• GitHub: google/adk-kotlin README und Projektdokumentation (abgerufen am 24.05.2026)

KI-Hinweis: Dieser Beitrag wurde mit KI-Unterstützung recherchiert, strukturiert und formuliert.