Long-Running AI Agents: Kein Kontextverlust mit ADK

Das Wichtigste in Kürze

• Google stellt mit dem Agent Development Kit (ADK) ein neues Architekturmuster vor, das KI-Agenten über Tage oder Wochen pausieren und ohne Kontextverlust fortsetzen lässt.
• Statt unstrukturierter Chat-Historien setzt das Framework auf explizite State Machines, die den Agentenzustand in diskreten Phasen wie „awaitingdocuments“ oder „provisioninglaptop“ verwalten.
• Das ADK ist Open Source und lässt sich lokal mit SQLite oder in der Cloud mit Cloud SQL betreiben – die Nutzung des Frameworks selbst ist kostenlos.

Google hat im Entwicklerblog ein detailliertes Architekturmuster für sogenannte Long-Running AI Agents veröffentlicht, die über Wochen hinweg aktiv bleiben, zwischendurch auf null skalieren und trotzdem keinen Kontext verlieren. Wie Google im Beitrag erläutert, basiert das Konzept auf dem hauseigenen Agent Development Kit (ADK) – einem Open-Source-Framework, das speziell für produktionsreife, zustandsbehaftete KI-Agenten entwickelt wurde. Der zentrale Ansatz: Der Agent arbeitet nicht mit einer endlos wachsenden Prompt-Historie, sondern steuert seinen Fortschritt über eine klar definierte State Machine mit persistentem Zustand.

Die Neuerungen im Detail

State Machines statt Chat-Historien

Das Kernproblem herkömmlicher KI-Agenten liegt laut Google darin, dass sie ihren Kontext in der Konversationshistorie mitschleppen. Bei Prozessen, die sich über Tage oder Wochen erstrecken, führt das zu Kontextverlust, explodierende Token-Kosten und unvorhersehbarem Verhalten. Das ADK-Architekturmuster löst das Problem durch eine explizite Zustandsmaschine: Jeder Agent durchläuft definierte Phasen – etwa collecting_info, awaiting_documents oder setup_complete – und speichert seinen aktuellen Zustand in einem persistenten state-Dictionary.

Der Agent weiß zu jedem Zeitpunkt exakt, in welcher Phase er sich befindet, welche Informationen bereits gesammelt wurden und welcher Schritt als nächstes ansteht – unabhängig davon, wie lange die Pause dazwischen war.

Event-Driven Architecture mit Scale-to-Zero

Ein weiterer Baustein ist die Event-Driven-Architektur. Statt dauerhaft Rechenressourcen zu belegen, skaliert der Agent bei Inaktivität auf null Instanzen. Externe Ereignisse – etwa ein eingehender Webhook von einem HR-System oder eine E-Mail-Bestätigung – wecken den Agenten gezielt auf. Die Zustandsspeicherung erfolgt dabei über:

• SQLite für lokale Entwicklung und Prototyping
• Cloud SQL (PostgreSQL) für produktionsreife Deployments
• Firestore als alternative NoSQL-Option

Laut Google wird der gesamte Agentenzustand inklusive aller gesammelten Datenfelder in der Datenbank persistiert, sodass der Agent nach einem Neustart oder Cold-Start exakt dort weitermacht, wo er pausiert hat.

Multi-Agenten-Delegation

Das Architekturmuster unterstützt außerdem Multi-Agenten-Topologien. Im vorgestellten Beispiel eines HR-Onboarding-Prozesses delegiert ein Haupt-Agent (der „Onboarding Coordinator“) spezifische Aufgaben an Sub-Agenten – etwa einen dedizierten IT-Setup-Agenten, der Laptop-Bereitstellung, Zugangskarten und Software-Lizenzen koordiniert. Jeder Sub-Agent verfügt über einen eigenen Zustandsraum, kommuniziert aber über den gemeinsamen state des übergeordneten Agenten.

Die technischen Eckdaten im Überblick:

• Modell-Unterstützung: Gemini-Modelle (z. B. gemini-2.0-flash) als Standard, andere LLMs integrierbar
• Zustandspersistenz: Automatische Serialisierung über ADK-Session-Service
• Deployment: Cloud Run für serverlose, event-getriebene Ausführung
• Callback-Mechanismus: Agenten können an definierten Punkten auf menschliche Eingaben oder externe Systeme warten

Warum das wichtig ist

Dieses Architekturmuster adressiert eines der größten ungelösten Probleme im Bereich der KI-Agenten: Zuverlässigkeit über lange Zeiträume. Die meisten heutigen Agent-Frameworks – von LangChain über CrewAI bis hin zu AutoGen – sind primär für kurzlebige, synchrone Interaktionen konzipiert. Sobald ein Prozess Tage oder Wochen dauert, scheitern sie an Kontextverlust, Session-Timeouts oder schlicht an den Kosten für dauerhaft gehaltene Recheninstanzen.

Google positioniert das ADK damit gezielt für Enterprise-Workflows: Compliance-Prozesse, Genehmigungsverfahren, Kunden-Onboarding oder eben das im Blog beschriebene HR-Onboarding, das typischerweise 2-4 Wochen dauert und Dutzende von Zwischenschritten umfasst. Die Kombination aus State Machine, Event-Driven-Architektur und Scale-to-Zero macht solche Szenarien erstmals wirtschaftlich und technisch tragfähig.

Kritisch anzumerken ist: Das vorgestellte Muster ist stark auf das Google-Cloud-Ökosystem zugeschnitten. Wer Cloud Run, Cloud SQL und Gemini nutzt, bekommt eine nahtlose Erfahrung. Für Teams, die auf AWS, Azure oder lokale Infrastruktur setzen, erfordert die Adaption zusätzlichen Integrationsaufwand – auch wenn das ADK selbst Open Source bleibt.

Verfügbarkeit & Fazit

Das Agent Development Kit (ADK) ist als Open-Source-Projekt auf GitHub verfügbar und kann sofort genutzt werden. Die Nutzung des Frameworks selbst ist kostenlos; Kosten entstehen lediglich durch die verwendeten Cloud-Dienste (Cloud Run, Cloud SQL) und API-Aufrufe an Gemini-Modelle. Google stellt den vollständigen Beispielcode für den HR-Onboarding-Agenten im Blog-Beitrag bereit.

Mit diesem Architekturmuster liefert Google eine überzeugende Blaupause für produktionsreife Long-Running Agents. Wer Enterprise-Prozesse automatisieren will, die über einzelne Chat-Sessions hinausgehen, findet hier erstmals ein durchdachtes, skalierbares Fundament – vorausgesetzt, man ist bereit, sich auf Googles Cloud-Stack einzulassen.

Häufig gestellte Fragen (FAQ)

Was sind Long-Running AI Agents und worin unterscheiden sie sich von normalen Chatbots?
Long-Running AI Agents sind KI-Agenten, die über Tage oder Wochen aktiv bleiben und komplexe, mehrstufige Prozesse autonom steuern. Im Gegensatz zu Chatbots, die auf einzelne Sessions beschränkt sind, persistieren sie ihren Zustand in einer Datenbank und können nach beliebig langen Pausen exakt dort fortfahren, wo sie pausiert haben.

Wie verhindert das ADK den Kontextverlust bei langen Prozessen?
Das ADK nutzt eine explizite State Machine statt einer wachsenden Chat-Historie. Der aktuelle Zustand – inklusive aller gesammelten Daten und der aktuellen Prozessphase – wird in einer Datenbank wie SQLite oder Cloud SQL gespeichert. Damit ist der Kontext unabhängig von der LLM-Sitzung jederzeit vollständig rekonstruierbar.

Welche Kosten entstehen beim Einsatz von Long-Running AI Agents mit dem ADK?
Das ADK selbst ist Open Source und kostenlos. Kosten entstehen durch die genutzten Cloud-Dienste – etwa Google Cloud Run, Cloud SQL und API-Aufrufe an Gemini-Modelle. Durch die Scale-to-Zero-Architektur fallen allerdings nur dann Compute-Kosten an, wenn der Agent tatsächlich aktiv arbeitet.

Für welche Anwendungsfälle eignen sich Long-Running AI Agents besonders?
Sie eignen sich für alle Geschäftsprozesse, die mehrere Tage oder Wochen dauern und menschliche Eingaben oder externe Systeme einbeziehen – etwa HR-Onboarding, Compliance-Prüfungen, Vertragsverhandlungen oder mehrstufige Genehmigungsverfahren. Überall dort, wo heute Excel-Listen und manuelle E-Mail-Ketten den Prozess steuern.

Ist das ADK an Google Cloud gebunden oder auch mit AWS und Azure nutzbar?
Das ADK ist Open Source und grundsätzlich plattformunabhängig. Die im Blog vorgestellte Referenzarchitektur ist jedoch auf Google Cloud (Cloud Run, Cloud SQL, Gemini) optimiert. Ein Einsatz auf AWS oder Azure erfordert Anpassungen bei der Zustandsspeicherung und dem Deployment, ist aber technisch möglich.