KI-Agenten brauchen Runtime-Observability

AWS hat einen detaillierten Leitfaden für Runtime-Observability in Amazon Bedrock AgentCore veröffentlicht. Fast zeitgleich beschreibt Google neue Managed-Agents-Funktionen in der Gemini API. Gemeinsam zeigen beide Updates: Produktive Agenten brauchen nicht nur Modellzugriff und Toolrechte, sondern ein Betriebsprotokoll, das Laufzeit, Kosten und Zustände sichtbar macht.

Was sich ändert

AWS zeigt anhand von AgentCore Observability, wie Teams langsame Agentenläufe über CloudWatch-Abfragen, Request-IDs und OpenTelemetry-Traces analysieren können. Der Beitrag nennt typische Engpässe: Memory-Retrieval, Tool-Aufrufe, Token-Generierung und sequentielle Schleifen, die eigentlich parallel laufen könnten. Ein Beispiel zeigt 17 Spans über drei execute_event_loop_cycle-Durchläufe; bei Memory-Retrieval nennt AWS unter 200 Millisekunden als sinnvolle Zielmarke für interaktive Anwendungen.

Google ergänzt dieselbe Betriebslogik aus einer anderen Richtung. Managed Agents in der Gemini API unterstützen 3.6 Flash, Hooks, geplante Trigger und Budgetgrenzen über max_total_tokens. Erreicht ein Agent das Budget, pausiert der Lauf mit dem Status incomplete; der Environment-State bleibt erhalten und kann mit frischem Budget fortgesetzt werden.

Warum das relevant ist

Für Unternehmen verschiebt sich die Agentenfrage damit von „Darf der Agent das?“ zu „Können wir später erklären, was der Agent getan hat, warum es langsam wurde und wann er stoppen musste?“ Ohne Laufzeitspuren bleibt ein Agent ein schwer prüfbarer Prozess: Er kann formal erfolgreich sein, aber zu teuer, zu langsam oder operativ nicht wiederholbar.

Runtime-Observability verbindet Architektur, FinOps und Governance. Sie macht sichtbar, welche Tools Zeit verbrauchen, welche Speicherabfragen teuer werden, welche Agentenschleifen außer Kontrolle geraten und welche Budgets pro Fachvorgang realistisch sind.

DACH-Perspektive

Für DACH-Unternehmen ist das besonders relevant, weil Audit, Datenschutz und Lieferantensteuerung nicht erst nach dem Rollout beginnen. Wer Agenten in Service, Reporting oder Backoffice einsetzt, sollte vor Produktivstart definieren: Request-ID, Trace-Schema, Token-Budget, Abbruchregel, Fortsetzungsprozess, Verantwortliche und SIEM-Anbindung.

Der pragmatische Start ist kein weiteres Strategiepapier. Er ist ein Agenten-Betriebsprofil pro Use Case: Welche Spuren muss jeder Lauf hinterlassen, welche Grenzwerte gelten, und wer entscheidet, ob ein pausierter Lauf fortgesetzt werden darf?