Google Gemini Enterprise Agent Platform — Vertex AI bekommt einen Agenten-Stack
Auf der Google Cloud Next am 22. April 2026 hat Google die Gemini Enterprise Agent Platform vorgestellt — und gleich GA gestellt. Was bisher als „Vertex AI Agent Builder” lief, ist jetzt Teil einer neuen, geschlossenen Plattform, die Modell-Auswahl, Agenten-Bau, Laufzeit, Memory und Governance unter ein Dach packt. Wichtigster struktureller Punkt: „All Vertex AI services and roadmap evolutions will be delivered exclusively through the Agent Platform” — Vertex AI als eigenständiges Produkt verschwindet.
Was die Plattform konkret bündelt
- Agent Studio — Low-Code-Visual-Builder für Agenten.
- Agent Development Kit (ADK) — Code-first-Umgebung; verarbeitet laut Google bereits 6+ Billionen Tokens pro Monat.
- Agent Runtime (vorher „Agent Engine”) — Sub-Sekunden-Cold-Starts, Support für mehrtägige Workflows.
- Memory Bank (vorher „Memory Bank”, Sessions heißen jetzt „Agent Platform Sessions”) — persistenter Langzeit-Kontext, $0,25 pro 1.000 Events oder Memories seit 28. Januar 2026.
- Agent Registry und Agent Gateway — zentrale Tool-Bibliothek, „Air Traffic Control” mit Sicherheits-Policies.
- Model Garden — 200+ Modelle, darunter Gemini 3.1 Pro, Gemma 4, Anthropic Claude.
Was vorher galt
Vertex AI war bisher ein Sammelsurium: Model Garden, Agent Builder, Vector Search, MLOps-Werkzeuge — gute Bausteine, aber lose verzahnt. Wer Agenten produktiv betreiben wollte, hat zwischen mehreren Konsolen, Pricing-Sheets und Lifecycle-Mustern hin- und hergesprungen. Ein Agent, der mehrere Tage State halten musste, war eine Eigenkonstruktion mit Cloud Tasks, Firestore und Custom-Glue. Memory zwischen Sessions ein eigenes Datenmodell.
Google selbst beschreibt die alte Welt nicht direkt als Schwäche, formuliert aber den neuen Anspruch klar: „We’ve simplified the entire lifecycle with AI-native coding capabilities to help you ship production-grade agents faster.”
Was jetzt gilt
1. Eine Plattform, ein Lifecycle. Agent Studio ist der Einstieg — Prompt rein, Agent raus. Reicht das nicht, exportiert man in den ADK und arbeitet code-first weiter, ohne den Kontext zu verlieren. Das ist der entscheidende Unterschied: Low-Code und Code-first sind nicht mehr zwei getrennte Welten mit Übersetzungsverlust, sondern ein durchgehender Pfad.
2. Mehrtägige Workflows als Standard. Der neue Agent Runtime hält State über Tage hinweg, ohne dass man sich selbst um Persistenz, Resume-Logik oder Cold-Start-Handling kümmern muss. Das öffnet Use-Cases, die mit klassischen Function-as-a-Service-Mustern fummelig waren — langlaufende Recherche-Aufträge, Onboarding-Flows mit Wartezeiten, Agenten, die auf externe Events warten.
3. Memory Bank als persistenter Kontext. Statt Konversations-History pro Session manuell zu pflegen, schreibt der Agent „Memories” in den Memory Bank — strukturierte Langzeit-Erinnerungen, die über Sessions hinweg verfügbar bleiben. Pricing seit 28. Januar 2026: $0,25 pro 1.000 Events oder Memories — billig genug, dass Memory standardmäßig eingeschaltet sein kann.
4. Agent Identity für Governance. Jeder Agent bekommt eine eindeutige kryptographische ID. Damit lassen sich Agenten-Aktionen so auditieren wie Service-Account-Aktionen. Wer in regulierten Branchen arbeitet, bekommt damit zum ersten Mal ein klares Audit-Modell für autonome Agenten.
5. Agent Garden mit Templates. Vorlagen für Code-Modernisierung, Finanzanalyse, Rechnungsverarbeitung und weitere Standard-Use-Cases. Zusammen mit den Native Ecosystem Integrations (Plug-and-Play-Connectors zu Workspace, BigQuery, Salesforce etc.) ist der Schritt vom „Hello Agent” zum produktiven Workflow auf Stunden statt Tage komprimiert.
Einordnung — was an der Marketing-Seite stimmt, was nicht
Die Bündelung ist real und sinnvoll. Lifecycle-Brüche zwischen Builder, Runtime und Memory waren die häufigste Bremse in Vertex-AI-Agentenprojekten — die fallen jetzt weg. Sub-Sekunden-Cold-Starts und mehrtägige Workflows sind harte technische Verbesserungen, die in vorhandenen Vertex-Setups so nicht erreichbar waren.
Die Schattenseite: Die Bündelung erhöht den Lock-in. Wer Agent Studio nutzt, schreibt seine Workflow-Logik in ein proprietäres Format, das sich nicht trivial nach AWS, Azure oder On-Prem portieren lässt. Memory Bank und Agent Identity sind ebenfalls Google-spezifisch. Wer Multi-Cloud-Strategie hat, wird das gegen die Bequemlichkeit abwägen.
Zweite Beobachtung: Google öffnet den Model Garden mit 200+ Modellen inklusive Anthropic Claude — das ist das Eingeständnis, dass Gemini allein das Modell-Spektrum nicht abdeckt. Für Kunden, die Modell-Diversität wollen, ist das ein klarer Pluspunkt; für die strategische Position von Gemini eher ein Hinweis darauf, dass Google im Modell-Wettkampf nicht klar führt.
Was du jetzt tun kannst
Wenn du auf Vertex AI sitzt: Prüfe in den nächsten Wochen den Migrationspfad. Google zieht den Stecker an Vertex-AI-als-Standalone — alle neuen Features kommen ausschließlich auf der Agent Platform. Bestehende Vertex-Workloads laufen weiter, aber Roadmap-Updates landen nicht mehr dort.
Wenn du Agenten neu aufsetzt und auf Google Cloud bist: Starte direkt mit Agent Studio für die ersten Iterationen, exportiere bei Bedarf in den ADK. Der Pfad ist sauberer als der vorige Weg über Vertex AI Agent Builder + manuelles MLOps.
Wenn du Multi-Cloud planst: Die Plattform ist mächtig, aber Lock-in-stark. Erwäge, die Workflow-Logik in einem portablen Format (Agents SDK, LangGraph, eigenes Routing) zu halten und die Plattform-Features punktuell zu nutzen — Memory Bank ist z. B. auch standalone nutzbar.
Entdecke mehr
Warum KI-Modelle unterschiedliche Code-Probleme finden
Drei Frontier-Modelle, dasselbe 1000-Zeilen-Skript, drei verschiedene Fundlisten — und warum genau diese Streuung Multi-Orchestrierung stark macht.
GlossarEnsemble / Multi-Modell-Orchestrierung
Ensemble bezeichnet das Kombinieren mehrerer bewusst variierter LLM-Läufe oder Modelle, deren Funde sich ergänzen. Multi-Modell-Orchestrierung steuert diese Läufe über Orchestratoren mit Sub-Agenten, sodass die Vereinigung der Ergebnisse größer ist als jeder Einzellauf.
LexikonFunction Calling / Tool Use
Wie ein LLM Werkzeuge aufruft: Tool-Definition als Schema, Modell wählt Funktion und Argumente, Ergebnis zurück ins Gespräch — der Grundbaustein jedes Agenten.