Google macht Genkit zum Full-Stack-Agenten-Framework

Google baut Genkit gerade von einem nützlichen KI-Framework zu einer echten Full-Stack-Agenten-Schicht aus. Die neue Agents-API ist auf den ersten Blick nur ein weiterer Baustein im Google-Agenten-Stapel. Tatsächlich ist die Nachricht größer: Google standardisiert jetzt die App-Schicht für persistente, benutzernahe Agenten – mit Sessions, Streaming, Remote-Zugriff, Human-in-the-loop und Hintergrundläufen.

Das ist ein anderer Schwerpunkt als bei ADK 2.0 und deterministischen Agent-Workflows. Dort ging es vor allem um kontrollierte Orchestrierung. Bei Genkit Agents geht es um die Frage, wie man daraus überhaupt eine brauchbare Produktfunktion baut.

Was Google konkret neu ausrollt

Im offiziellen Launch nennt Google die neue Genkit Agents API eine Full-Stack-Grundlage für konversationelle KI. Das ist nicht nur Marketing-Sprech. Hinter dem Paket stecken mehrere Dinge, die Teams sonst jedes Mal selbst zusammenlöten müssen:

• ein gemeinsames chat()-Interface für lokale und entfernte Agenten
• server- oder clientverwalteter Zustand für mehrturnige Gespräche
• Session Stores inklusive Firestore-Option für persistente Snapshots
• remoteAgent() als Protokollschicht zwischen Backend und Frontend
• Interrupts für Freigaben und andere menschliche Eingriffe
• Detach/Resume für längere Jobs, die den Request überleben sollen
• leichtgewichtige Multi-Agent-Delegation für Spezialisten-Rollen

Der wichtige Punkt ist: Google liefert hier nicht bloß noch ein SDK-Detail, sondern das wiederkehrende Runtime-Gerüst für Chat- und Agentenfunktionen in echten Apps.

Warum das mehr ist als ein Genkit-Update

Viele KI-Teams haben das gleiche Problem. Die Modellseite ist oft schnell gebaut. Was danach kommt, frisst Zeit:

• Wo liegt der Gesprächszustand?
• Wie wird sauber zwischen Browser und Server gestreamt?
• Wie pausiert man riskante Aktionen für eine Freigabe?
• Wie laufen längere Agentenjobs weiter, wenn der Tab geschlossen wird?
• Wie brancht man von einem alten Stand weiter, ohne den Hauptverlauf kaputtzumachen?

Genau auf diese Schicht zielt Google jetzt.

Das ist auch der Grund, warum ich die Meldung für menzel.works relevanter finde als viele Modell-News. Hier verschiebt sich Infrastruktur in ein wiederverwendbares Produkt-Primitive. Wer Support-Assistenten, Research-Copilots, Genehmigungsstrecken oder interne Task-Agenten baut, spart nicht nur Boilerplate. Er bekommt eine klarere Architektur dafür, was im Modell, was in der Runtime und was im Client passieren soll.

Der eigentliche Signalwechsel

Google trennt den Agenten-Stack gerade sichtbar in mehrere Schichten auf:

• ADK für stärkere Orchestrierung und komplexere Agenten-Topologien
• Genkit Middleware für Governance, Policies und Kontrollpunkte (hier eingeordnet)
• Genkit Agents für die produktnahe Full-Stack-Laufzeit benutzerseitiger Agenten

Das wirkt erstmal wie mehr Fragmentierung. Ich lese es eher anders: Google hört langsam auf, Agenten als diffuse Magie zu behandeln, und zerlegt das Thema in sauberere Software-Schichten.

Gerade der neue remoteAgent()-Ansatz ist dafür ein gutes Beispiel. Statt für jede App ein eigenes Streaming- und State-Protokoll zu erfinden, soll Frontend und Backend dieselbe Agenten-Schnittstelle sprechen. Das ist pragmatisch. Und es zeigt, wo Google den Engpass sieht: nicht mehr nur beim Modell, sondern bei der Produktintegration.

Was für Teams praktisch interessant ist

Spannend wird das für alle, die persistente Agentenfunktionen in eine bestehende Anwendung einbauen wollen.

Ein paar konkrete Muster, die Genkit damit deutlich leichter macht:

• ein Support-Agent, der Ticketkontext über mehrere Turns hält
• ein interner Copilot, der erst nach Nutzerfreigabe kritische Tools ausführt
• ein Reporting-Agent, der im Hintergrund weiterarbeitet und später wieder aufgenommen wird
• ein Produkt-Assistent, der im Frontend streamt, aber seinen Zustand serverseitig sauber ablegt

Besonders wichtig finde ich das Detach/Resume-Modell. Viele Agenten-Demos tun so, als sei alles ein synchroner Chat-Request. In echten Systemen ist das oft Unsinn. Recherche, Dateiarbeit, Planerstellung oder Tool-Ketten dauern. Wenn die Runtime solche Jobs nativ weiterlaufen lässt, wird aus einem Chat-Feature eher ein belastbarer Arbeitsmodus.

Wo die Grenzen liegen

Ganz fertig ist das alles nicht. Google weist selbst darauf hin, dass die Agents-API aktuell Beta/Preview ist und Breaking Changes möglich sind. Außerdem ersetzt Genkit Agents nicht automatisch ADK oder klassische Flows.

Die praktische Grenze ist ziemlich klar:

• Wenn die Multi-Agent-Orchestrierung selbst das Produkt ist, bleibt ADK näher dran.
• Wenn ein Agent eine Funktion innerhalb einer App ist, wirkt Genkit Agents derzeit wie die passendere Ebene.

Diese Unterscheidung ist hilfreich, weil sie etwas ordnet, das im Agentenmarkt zuletzt oft verschwommen verkauft wurde.

Mein Fazit

Die eigentliche Nachricht lautet nicht einfach „Google bringt Agenten für Genkit“. Die eigentliche Nachricht lautet: Google baut gerade die fehlende App-Runtime zwischen Modell, Workflow und Benutzeroberfläche.

Genau deshalb ist das Thema eigenständig genug gegenüber ADK 2.0. ADK beantwortet stärker die Frage, wie Agenten und Workflows kontrolliert orchestriert werden. Genkit Agents beantwortet die Frage, wie daraus überhaupt eine robuste, mehrturnige Produktfunktion wird.

Für Teams, die 2026 nicht nur Agenten-Demos, sondern echte KI-Features bauen wollen, ist das ziemlich viel relevanter als der nächste Benchmark-Screenshot.

Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt und redaktionell geprüft.

Quellen: Google Developers Blog: Build agentic full-stack apps with Genkit, Genkit Docs: Full-stack agents