KI-Agenten sind Programme, die Aufgaben nicht nur beantworten, sondern eigenständig in mehreren Schritten abarbeiten: Daten abrufen, Werkzeuge aufrufen, Zwischenergebnisse bewerten, erneut ansetzen. Genau dieses Verhalten macht sie im Betrieb unbequem. Ein klassischer Webservice beantwortet eine Anfrage in Millisekunden und ist danach fertig. Ein Agent läuft unter Umständen minutenlang, ruft externe Systeme auf und verändert dabei Zustände.
Google adressiert diese Lücke mit der Agent Compute Engine, einer Laufzeitumgebung, die speziell für den Betrieb von KI-Agenten entwickelt wurde. Parallel dazu erweitert der Konzern die Governance-Funktionen, mit denen Unternehmen Agenten in Cloud-, Hybrid- und lokalen Umgebungen kontrollieren können. Governance meint hier die Summe der Regeln und Kontrollmechanismen, die festlegen, was ein Agent tun darf, worauf er zugreift und wie das nachvollziehbar bleibt.
Warum Agenten eine eigene Laufzeit brauchen
Die vorliegende Meldung nennt keine technischen Details zur Architektur. Die grundsätzliche Problemstellung ist aber aus der Praxis gut bekannt und erklärt, warum ein eigener Baustein überhaupt entsteht.
- Lange Laufzeiten: Agentische Abläufe passen schlecht in Request-Response-Muster, die auf kurze Antwortzeiten ausgelegt sind.
- Zustand: Ein Agent muss sich über mehrere Schritte hinweg merken, was er bereits getan hat. Zustandsloser Betrieb funktioniert nur eingeschränkt.
- Werkzeugzugriffe: Sobald ein Agent APIs aufruft, Dateien schreibt oder Datenbanken verändert, braucht es klare Grenzen und eine Isolation der Ausführung.
- Nicht-Determinismus: Dieselbe Eingabe kann unterschiedliche Abläufe erzeugen. Das erschwert Tests, Monitoring und Fehlersuche.
Wer diese Punkte heute selbst löst, baut im Ergebnis Infrastruktur: Warteschlangen, Zustandsspeicher, Timeouts, Sandboxing, Protokollierung. Ein dedizierter Dienst nimmt diesen Teil ab, bindet aber im Gegenzug an eine Plattform.
Governance als eigentlicher Hebel
Interessanter als die Rechenumgebung selbst ist die gleichzeitige Erweiterung der Governance-Funktionen. Das deutet darauf hin, dass der Engpass bei produktiven Agentenprojekten weniger in der Rechenleistung liegt als in der Frage, ob eine Organisation die Kontrolle über das Verhalten dieser Systeme behält.
Für mittelständische Unternehmen sind dabei typischerweise diese Fragen entscheidend:
- Welche Systeme und Datenquellen darf ein bestimmter Agent erreichen, und mit welchen Rechten?
- Welche Aktionen führt er selbstständig aus, welche erfordern eine menschliche Freigabe?
- Lässt sich im Nachhinein rekonstruieren, warum ein Agent eine bestimmte Entscheidung getroffen hat?
- Wer trägt intern die Verantwortung, wenn ein Agent eine fehlerhafte Aktion auslöst?
Ohne belastbare Antworten darauf bleiben Agenten in Unternehmen Prototypen. Mit Antworten werden sie zu Komponenten, die sich wie andere Softwarebausteine betreiben, überwachen und auditieren lassen.
Cloud, Hybrid und lokal
Bemerkenswert ist die ausdrückliche Nennung hybrider und lokaler Umgebungen. Viele Unternehmen können oder wollen bestimmte Daten nicht in eine öffentliche Cloud geben – wegen regulatorischer Vorgaben, wegen vertraglicher Zusagen gegenüber Kunden oder schlicht aus Risikoerwägungen.
Wenn sich Agenten auch außerhalb der Cloud betreiben und trotzdem zentral steuern lassen, verschiebt sich die Diskussion. Die Frage lautet dann nicht mehr, ob ein Unternehmen Agenten einsetzt, sondern wo welcher Agent läuft und welche Datenklasse er jeweils berührt. Das ist eine Architekturentscheidung, keine reine Toolfrage.
Was das für laufende Projekte heißt
Für Organisationen, die derzeit erste Agenten erproben, ergeben sich aus dieser Entwicklung einige praktische Konsequenzen.
Erstens: Es lohnt sich, die eigene Agentenlogik von der Ausführungsumgebung zu trennen. Wer Prompts, Werkzeugdefinitionen und Ablauflogik sauber kapselt, kann die darunterliegende Laufzeit später austauschen, ohne alles neu zu bauen. Der Markt für solche Umgebungen ist jung, und es ist nicht absehbar, welche Anbieter sich durchsetzen.
Zweitens: Rechte- und Rollenkonzepte sollten früh entstehen, nicht erst beim Produktivgang. Ein Agent, der mit einem Allzweck-Zugang auf ein CMS, ein ERP oder ein CRM zugreift, ist ein Risiko, das sich später nur mühsam zurückbauen lässt. Besser sind eng geschnittene technische Benutzer je Anwendungsfall.
Drittens: Protokollierung ist kein Nachgedanke. Welche Eingabe, welcher Werkzeugaufruf, welches Ergebnis – diese Spur braucht es, um Fehler zu verstehen und um gegenüber Prüfinstanzen auskunftsfähig zu sein.
Viertens: Nicht jede Automatisierung braucht einen Agenten. Wo ein Ablauf klar definiert ist, bleibt ein deterministischer Workflow die robustere und günstigere Lösung. Agentische Ansätze lohnen sich dort, wo der Weg zum Ziel von Fall zu Fall variiert.
Einordnung mit Augenmaß
Eine Produktankündigung ist noch kein Beleg für Praxistauglichkeit. Zu Verfügbarkeit, Reifegrad, Konditionen und konkreten Funktionsumfängen liegen aus der Meldung keine Angaben vor, entsprechend sollte man hier keine voreiligen Schlüsse ziehen. Was sich jedoch ablesen lässt: Die großen Plattformanbieter behandeln Agenten inzwischen als eigene Betriebsklasse und nicht mehr als Anwendungsfall bestehender Modell-APIs.
Diese Verschiebung ist das eigentliche Signal. Sie bringt mit sich, dass Betrieb, Sicherheit und Nachvollziehbarkeit von Agenten denselben Standards unterliegen werden wie andere Unternehmenssoftware – mit allen Vorteilen und allem Aufwand, der damit verbunden ist.
Konsequenz für Web- und Softwareprojekte
Für Web- und Softwareprojekte bedeutet das konkret: Wer Agenten in Redaktionsprozesse, Kundenportale oder interne Abläufe integrieren möchte, plant künftig nicht nur die Fachlogik, sondern auch eine Ausführungs- und Kontrollschicht mit ein. Schnittstellen sollten so geschnitten sein, dass sie feingranulare Berechtigungen und vollständige Protokollierung erlauben. Und die Entscheidung über den Betriebsort – Cloud, hybrid oder lokal – gehört in die Architekturphase, nicht in die Woche vor dem Go-live.
