KI-Agenten in der Infrastruktur: echte Einsätze im DevOps

KI-Agenten Beispiele DevOps - wenn es um echte Produktion geht - sehen ganz anders aus als die Hype-Decks suggerieren. Jede Liste "KI-Agent-Beispiele" im Marketing liest sich wie ein Produktkatalog: Chatbots, Sales-Assistenten, HR-Bots. Nichts davon beantwortet die Frage, die ein Platform Engineer stellt: Wie sieht ein Agent aus, wenn er wirklich an eine Deployment-Pipeline darf? Die ehrliche Antwort ist enger und weniger glamourös. Echte, produktive KI-Agenten in der Infrastruktur fallen in vier Kategorien: Auto-Rollback-Agenten, Triage-Agenten, Diagnostic-Agenten und Runbook-Ausführer. Alles andere ist ein Chatbot mit besserer Programmierung.

Wir haben diese aus öffentlichen Case Studies, Vendor-Postmortems und unserer eigenen SLO-gesteuerten Rollout-Arbeit zusammengetragen. Nichts davon ist von Anfang bis Ende vollständig autonom. Alle sind eng, nachvollziehbar und auf eine Aufgabe begrenzt.

Was zählt wirklich als KI-Agent in einer Deployment-Pipeline?

Ein Dashboard, das eine Anomalie anzeigt, ist kein Agent. Ein Slack-Bot, der dich anpingt, wenn p99 einen Schwellenwert überschreitet, ist auch keiner - das ist ein Cron-Job mit besserer Kopie. Die Unterscheidung, die für Platform Teams zählt: Ein Agent plant eine Sequenz von Aktionen über mehrere Systeme, passt seinen Plan basierend auf das Gefundene an und führt aus, ohne dass ein Mensch jeden Schritt bestätigt.

Nach diesem Maßstab ist die meiste "KI-DevOps"-Werkzeuge noch unterstützend, nicht agentisch. Sie zeigen Informationen schneller an. Die vier Kategorien unten überschreiten wirklich die Grenze zum Handeln, zumindest innerhalb eines definierten Blast Radius.

Der Rollback-Agent: Auto-Revert, bevor ein Mensch bemerkt es

Das ist die Form, die unseren Ansatz am ehesten entspricht. Ein Agent überwacht die SLO-Brennrate während eines Rollouts und reverted das Deployment, wenn das Budget einen Schwellenwert überschreitet - bevor ein Mensch ein Dashboard öffnet. Kein Ermessensspielraum, kein 3-Uhr-Morgens-Slack-Thread mit der Frage "Ist das schlecht genug zum Reverten?" Der Schwellenwert wird bei Tageslicht entschieden, wenn niemand von Adrenalin getrieben wird.

Eine minimale Version des Gates sieht so aus:

type RolloutState = {
  errorBudgetBurn: number; // Anteil des SLO-Budgets, das dieses Fenster verbrannt wurde
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14; // 14% des Monats-Budgets in einem Fenster = Page
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}

Das ist die ganze Entscheidung. Der Agent-Teil ist alles drum herum: Live-Fehlerrate und Latenz aus dem Observability-Stack pullen, gegen das vorab deklarierten SLO vergleichen, das Deployment via API reverten und eine strukturierte Nachricht in den Incident-Channel schreiben, die erklärt, was es ausgelöst hat und was es sah. Wir haben dieses Muster in Produktion bei einem Series-C-Fintech beobachtet, das ungefähr 40 Deployments pro Tag macht. Medianer Zeitpunkt von Burn-Erkennung bis Revert: unter 90 Sekunden. Das eigene manuelle Median des Teams, gemessen über sechs Monate von Postmortems, lag bei 11 Minuten.

Überspringe dieses Muster, wenn deine Deploy-Frequenz niedrig genug ist, dass ein Mensch ohnehin bei jedem Rollout live zuschaut. Der Agent verdient sein Recht bei Volume, nicht bei 2 Deployments pro Woche.

Der Root-Cause-Triage-Agent: Von Alert bis Slack-Thread in Minuten

Das ist die Kategorie mit den meisten öffentlichen Daten dahinter, weil es am einfachsten zu verkaufen und am einfachsten zu messen ist. Amazons DevOps Agent wird zum Beispiel durch einen CloudWatch-Alarm oder einen PagerDuty-Page ausgelöst, bildet eine Hypothese über die Ursache, befragt Logs und Traces, um sie zu testen, korreliert die Anomalie gegen aktuelle Deployment-Zeitstempel und postet Befunde in Slack mit einer empfohlenen Mitigierung. Amazon berichtet von bis zu 75% niedrigerem MTTR bei dokumentierten Deployments, und die Case Study der Western Governors University zitiert speziell, dass die Lösungszeit von etwa zwei Stunden auf 28 Minuten fiel (https://aws.amazon.com/blogs/devops/leverage-agentic-ai-for-autonomous-incident-response-with-aws-devops-agent/).

Das beachtenswerte Teil ist nicht die Prozentzahl. Es ist die Audit-Trail-Anforderung: Jeder Reasoning-Schritt, den der Agent macht, ist in einem unveränderlichen Record protokolliert, den er selbst nicht ändern kann. Das ist kein Nice-to-Have. Wenn ein Agent deine Deployment-Historie mit deinem Error-Spike korreliert und einem On-Call-Engineer sagt "das ist wahrscheinlich die Checkout-Service-Änderung", musst du genau nachvollziehen können, wie er da hingekommen ist, wenn es falsch ist - und es wird manchmal falsch sein.

Wir haben das gleiche Muster unter verschiedenen Namen gesehen: Wild Moose verspricht Root-Cause-Surfacing unter einer Minute, HolmesGPT diagnostiziert Cloud-Alerts durch die gleiche Detect-Korrelate-Explain-Schleife. Die Mechaniken konvergieren, weil das Problem überall die gleiche Form hat: Alert schießt, Agent liest Telemetrie, Agent schlägt eine Ursache vor, Mensch bestätigt oder überschreibt.

Es lohnt sich, wenn dein Team mehrmals pro Woche gepagt wird und deine Postmortems wiederholt "es hat zu lange gedauert, die tatsächliche Ursache zu finden" als Beitragsfaktor zitieren. Überspringe es, wenn deine Incidents selten genug sind, dass die Tuning-Zeit sich nicht amortisiert, bevor deine nächste Architektur-Änderung die Training-Daten des Models obsolet macht.

Der Kubernetes-Diagnostic-Agent: Ein engerer, sichererer Schnitt

Kubernetes-Debugging ist, wo viele dieser Tools angefangen haben, wahrscheinlich weil kubectl-Output genau die Art von dichtem, strukturiertem Text ist, bei dem LLMs gut zusammenfassen. k8s-GPT scannt einen Cluster und erklärt Fehler in Klartext: Warum ein Pod in CrashLoopBackOff steckt, warum ein PVC sich nicht bindet, warum ein Service keine Endpoints hat. Es handelt nicht, es erklärt. Das ist absichtliche Scoping und die richtige Entscheidung für ein Tool, das ein Junior Engineer gegen einen Cluster laufen könnte, den er noch nicht vollständig versteht.

Die nächste Stufe handelt dann, vorsichtig. Guardian-artige Agenten erkennen ein Problem, finden die Wurzelursache und öffnen einen Fix-PR, anstatt direkt in den Cluster zu pushen. Dieser eine zusätzliche Schritt, ein PR statt einer Live-Änderung, ist der gesamte Unterschied zwischen "nützlicher Automatisierung" und "das Ding, das Dienstag Abends Outage verursacht hat." Ein PR wird reviewed. Ein direktes kubectl apply von einem Agent nicht, es sei denn, du hast selbst einen Review-Schritt eingebaut - und die meisten Teams haben das nicht.

Die Dokumentations-Schicht zählt hier mehr, als Leute erwarten. Wenn ein Agent einen Kubernetes-Fehler erklärt oder einen Fix-PR öffnet, folgt er implizit einem Runbook, das entweder in deinem Team-Kopf lebt oder irgendwo, wo der Agent (und der nächste Engineer) es tatsächlich lesen kann. Teams, die Runbooks in einem Docs-as-Code-Tool mit einer abfragbaren KI-Schicht führen, sehen weniger "Moment, warum haben wir das so gemacht?" Threads sechs Monate später. Das ist keine Agent-spezifische Beratung, es ist einfach, dass Agent-Output veraltete Dokumentation offensichtlicher macht, als wenn ein Mensch sie läse.

Der Runbook-Executor: Was passiert, wenn du einen Agent die Prod berühren lässt

Das ist die Kategorie, die Leute meinen, wenn sie "vollständig autonomer SRE-Agent" sagen - und auch die mit der dünnsten Evidence Base. Die Argumentation: Ein Agent erkennt ein Memory Leak, triggert ein Rolling Restart während eines Low-Traffic-Fensters, bestätigt, dass der Service wieder healthy kam, und schließt die Schleife, ohne irgendjemanden zu pagen. Multi-Step-Remediation-Playbooks, ausgeführt ohne das Risiko eines Tippfehlers oder eines übersprungenen Schritts in einem 2-Uhr-Morgens-Runbook, das zuletzt im März getestet wurde.

Es funktioniert, wenn das Playbook eng ist und der Blast Radius klein. Ein Rolling Restart eines stateless Service während eines definierten Low-Traffic-Fensters ist etwas Vernünftiges zu automatisieren. Ein Database Failover während Business Hours nicht, egal wie gut der Agent-Track-Record in einer Demo aussieht. Die Teams, die hier brennen, sind nicht die, die Restarts automatisieren - das sind die, die einen frühen Erfolg dazu bringt, etwas mit echtem Datenverlust-Risiko zu automatisieren, bevor der Agent genug Prod-Reps hat, um dieses Vertrauen zu verdienen.

Unsere eigene Lesart, von Kunden, die AI Pilot in progressive Rollouts drahten: Starten Sie mit der Aktion, die am einfachsten rückgängig zu machen und am schwierigsten falsch zu machen ist. Restart vor Failover. Canary-Prozentsatz-Rollback vor Database-Schema-Änderungen. Lassen Sie den Agent-Error-Rate gegen Low-Stakes-Aktionen den Fall für die Higher-Stakes-Aktionen auf einem Timeline-Maßstab von Monaten, nicht der ersten guten Woche bauen.

General-Purpose Agenten erscheinen auch - und die haben die falsche Form dafür

Suche "KI-Agent-Beispiele" überall außerhalb eines Ops-Kontexts und du landest in einer ganz anderen Kategorie: Generalisten-Agenten, die zum Planen und Ausführen von Open-End-Tasks über einen virtuellen Browser, Terminal und Dateisystem gebaut sind.

Manus operiert innerhalb eines vollständigen virtuellen Computers und meldet mit fertigen Arbeitsergebnissen zurück, anstatt einer Chat-Antwort. Es ist wirklich fähig bei Forschung und Multi-Step-Web-Tasks. Es ist aber auch das falsche Werkzeug für eine Production-Rollout-Entscheidung, weil sein Wertangebot Breite ist: Es kann fast alles tun, gegeben genug Schritte und genug Zeit. Eine Rollback-Entscheidung braucht die gegensätzliche Eigenschaft. Sie muss schnell, eng und langweilig genug sein, dass du genau vorhersagen kannst, was sie tun wird, bevor sie es tut.

Lindy sitzt näher an der Ops-benachbarten Mitte: No-Code-Workflows, die Inbox-Triage, Meeting-Scheduling und wiederkehrende Follow-ups handhaben. Nützlich für die menschliche Seite eines On-Call-Rotation (niemand will um 6 Uhr morgens manuell einen Handoff neu planen), nutzlos für die echte Incident Response. Gleiche Geschichte mit Gensparks No-Code Super Agent, der browsed, anruft und auf Anfrage generiert, aber kein Konzept eines SLO-Budgets oder Canary-Prozentsatzes hat.

Keines von diesem ist ein Knockdown auf diese Produkte. Sie sind für einen anderen Job gebaut. Der Fehler, den wir ständig sehen: Teams, die einen General-Purpose Agent gegen ein eng Ops-Problem evaluieren, unbeeindruckt werden und concluden "KI-Agenten sind nicht bereit für Infra." Falsche Kategorie, falsche Conclusio.

Wo diese Agenten noch fehlschlagen - und warum das der interessante Teil ist

Der Ausfallmodus, den niemand in die Case Study schreibt: Agenten, die zu 94% präzise in der Root-Cause-Identifikation sind, haben immer noch einmal in siebzehn Unrecht - und die falsche Antwort ist normalerweise selbstbewusst-klingend und spezifisch genug, um einen On-Call-Engineer 20 Minuten lang dem falschen Service hinterherjagen zu lassen, bevor jemand merkt, dass die Korrelation, die der Agent fand, zufällig war, nicht kausal. Deploy-Zeitstempel-Korrelation ist ein echtes Signal. Es ist kein Beweis. Ein Agent, der trainiert ist, sicher zu klingen, wird über einen Zufall genauso sicher klingen wie über eine echte Ursache.

Der zweite Ausfallmodus ist stiller: Agent Sprawl. Sobald Triage-, Diagnostic- und Rollback-Agenten laufen, muss jemand die Agenten selbst monitoren. Early 2026 Deployments zeigen bereits, dass der größte operationelle Gewinn nicht die MTTR-Zahl ist, es ist der Aufbau von Observability für die Agent-Schicht selbst, weil ein Agent, der still aufhört zu triggern, schlimmer ist als kein Agent. Niemand bemerkt das Fehlen eines Alerts.

Überspringe volle Autonomie bei allem mit irreversibler Blast Radius, egal wie gut die letzten 20 Läufe aussahen. Zwanzig gute Läufe sind keine Verteilung, das ist eine Stichprobe.

Solltest du einen Agent in deinen Rollout drahten, oder eine Cycle abwarten?

Wenn dein Team mehr als ein paar Mal im Monat gepagt wird und deine Postmortems das gleiche Root Cause mit verschiedenen Service-Namen wiederholen, wird sich ein Triage-Agent schneller amortisieren, als du erwartest - größtenteils durch Verkürzung der "Was hat sich geändert?" Phase von jedem Incident. Wenn dein Deploy-Volume hoch genug ist, dass ein Mensch nicht bei jedem Rollout live zuschaut, entfernt ein SLO-gated Rollback-Agent das 3-Uhr-Morgens-Ermessensspielraum ganz, was eigentlich der Punkt ist: Du möchtest nicht, dass der On-Call-Engineer um 3 Uhr denkt, du möchtest, dass sie einen Knopf drücken, der bei Tageslicht konfiguriert wurde.

Wenn keines von beiden noch wahr ist, ist die ehrliche Bewegung, deine SLOs ordnungsgemäß zu instrumentalisieren. Ein Agent, der auf noisy, undefined Error Budgets sitzt, wird nur schlechte Entscheidungen schneller automatisieren, als ein Mensch sie gemacht hätte. Der Agent ist nicht die harte Partei. Zu wissen, genau was "schlecht genug zu handeln" bedeutet, in Zahlen, bevor du die Entscheidung an etwas abgibst, das nicht um 3 Uhr morgens müde wird, ist es.