AI agent voorbeelden DevOps: wat werkt in productie

AI agent voorbeelden DevOps: wat werkt in productie

Elke lijst met "AI agent voorbeelden" die je nu vindt, voelt als een productcatalogus: chatbots, verkoopsassistenten, HR-bots. Geen daarvan beantwoordt de vraag die platform engineers in DevOps werkelijk hebben: hoe ziet een agent eruit wanneer je die dicht bij een deployment pipeline toelaat? Het eerlijke antwoord is smaller dan wat de marketingdecks suggereren. Werkende AI agent voorbeelden DevOps in productie-infrastructuur vallen in vier vormen: rollback-agenten, triage-agenten, diagnostische agenten en runbook-executors. Alles ander is een chatbot met een beter prompt.

We hebben deze uit openbare casestudy's, vendor-postmortems en ons eigen SLO-gated rollout-werk haald. Geen daarvan is volledig autonoom van begin tot eind. Allemaal zijn ze smal, auditeerbaar en ingedeeld op één taak.

Wat telt als een AI-agent in een deployment pipeline

Een dashboard dat een afwijking markeert, is geen agent. Een Slack-bot die je pingt wanneer p99 een drempel kruist, is ook geen agent, het is een cronjob met beter copywriting. Het onderscheid dat telt voor platformteams: een agent plant een reeks acties over meer dan één systeem, past dat plan aan op basis van wat het vindt, en voert uit zonder dat een mens elke stap bevestigt.

Op die maatstaf is veel "AI DevOps"-tooling nog steeds assistief, niet agentisch. Het oppervlakte informatie sneller. De vier categorieën hieronder kruisen de lijn naar werkelijk handelen, minstens binnen een bepaalde blast radius.

De Rollback-agent: Terugdraaien voor een mens het merkt

Dit is de vorm die het dichtst bij wat we bouwen ligt. Een agent bewaakt een SLO burn-rate tijdens een rollout en draait de deployment terug wanneer het budget een drempel kruist, voordat een mens een dashboard heeft geopend. Geen oordeel, geen 3uur Slack-gesprek waarin gevraagd wordt "is dit slecht genoeg om terug te draaien." De drempel wordt overdag bepaald, wanneer niemands adrenaline de wiskunde doet.

Een minimalistische versie van de gate ziet er zo uit:

type RolloutState = {
  errorBudgetBurn: number; // fractie van SLO-budget verbruikt dit venster
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14; // 14% van maandelijks budget in één venster = page
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}

Dat is de hele beslissing. Het agentgedeelte is alles eromheen: live foutpercentage en latentie van de observability-stack ophalen, vergelijken met de vooraf verklaard SLO, de rollout via de deployment-API uitvoeren, en een gestructureerde notitie naar het incident-kanaal schrijven met uitleg wat het getriggerd heeft en wat het gezien heeft. We hebben dit patroon in productie zien draaien bij een Series-C fintech die ongeveer 40 deployments per dag doet. Mediane tijd van burn-detectie naar teruggaan: onder 90 seconden. Het eigen mediane team, gemeten over zes maanden eerdere postmortems, was 11 minuten.

Sla dit patroon over als je deploy-frequentie laag genoeg is dat een mens al elke rollout live bewaakt. De agent verdient zijn brood met volume, niet met 2 deployments per week.

De Root-Cause Triage-agent: Van Alert tot Slack-gesprek in minuten

Dit is de categorie met de meeste openbare gegevens erachter op dit moment, omdat het gemakkelijkste te verkopen en gemakkelijkste te meten is. AWS's DevOps Agent wordt bijvoorbeeld geactiveerd door een CloudWatch-alarm of PagerDuty-pagina, vormt een hypothese over de oorzaak, bevraaagt logs en traces om het te testen, correleert de afwijking tegen recente deploy-timestamps, en plaatst bevindingen naar Slack met een aanbevolen beperking. AWS rapporteert tot 75% lager MTTR over zijn gedocumenteerde deployments, en Western Governors University's casestudy stelt specifiek dat de resolutietijd van ongeveer twee uur tot 28 minuten daalde (bron).

Het deel dat de moeite waard is op te merken, is niet het percentage. Het is de vereiste audittrail: elke stap van redenering die de agent onderneemt, wordt vastgelegd in een onveranderbare record die het niet zelf kan wijzigen. Dat is niet "nice-to-have". Als een agent je deploy-historie gaat correleren met je foutpiek en een on-call engineer vertelt "dit is waarschijnlijk de checkout-service wijziging," dan moet je exact kunnen achterhalen hoe het daar gekomen is wanneer het fout gaat, en het gaat af en toe fout.

We hebben hetzelfde patroon onder verschillende namen gezien: Wild Moose belooft root-cause surfacing in onder een minuut, HolmesGPT diagnosticeert cloudalerts door dezelfde detectie-correlatie-verklaar-lus. De mechanica convergeert omdat het probleem overal dezelfde vorm heeft: alert valt, agent leest telemetrie, agent stelt een oorzaak voor, mens bevestigt of overschrijft.

De setup-kosten waard als je team meer dan een paar keer per week pages en je postmortems houden citaat "duurde te lang om de werkelijke oorzaak te vinden" als bijdragende factor. Sla het over als je incidenten zeldzaam genoeg zijn dat de afstemmingstijd niet terugbetaalt voordat je volgende architectuurverandering de trainingsgegevens van het model stale maakt toch al.

De Kubernetes Diagnostic-agent: Een smallere, veiliger scheive

Kubernetes-debuggen is waar veel van deze tools zijn begonnen, waarschijnlijk omdat kubectl-uitvoer exact het soort dichte, gestructureerde tekst is waar een LLM goed in is samenvattingen. k8s-GPT scant een cluster en legt fouten uit in gewone taal: waarom een pod in CrashLoopBackOff zit, waarom een PVC niet bindt, waarom een service geen endpoints heeft. Het handelt niet, het legt uit. Dat is doelbewuste scoping, en het is de juiste keuze voor een tool die een junioringenieur tegen een cluster waar ze niet volledig mee bekend zijn, kan draaien.

De volgende laag handelt wel, voorzichtig. Guardian-stijl agenten detecteren een probleem, vinden de root cause, en openen een fix-PR in plaats van rechtstreeks naar het cluster te pushen. Die ene extra stap, een PR in plaats van een live-verandering, is het gehele verschil tussen "nuttige automatisering" en "het ding dat vorige dinsdag de outage veroorzaakte." Een PR wordt beoordeeld. Een direct kubectl-toepassing van een agent doet dat niet, tenzij je een beoordelingsstap in jezelf hebt gebouwd, en de meeste teams hebben dat niet.

De documentatie-laag telt hier meer dan mensen verwachten. Wanneer een agent een Kubernetes-fout uitlegt of een fix-PR opent, de runbook die het impliciet volgt, leeft in het hoofd van je team of ergens waar de agent (en de volgende ingenieur) het werkelijk kan lezen. Teams die runbooks in een docs-as-code tool houden met een querybare AI-laag, zien minder "wacht, waarom hebben we het zo gedaan" gesprekken zes maanden later. Dat is geen agent-specifiek advies, het is gewoon dat agent-uitvoer stale documentatie sneller duidelijk maakt dan een mens die het ooit las.

De Runbook Executor: Wat gebeurt er wanneer je een agent prod laat aanraken

Dit is de categorie waar mensen "volledig autonome SRE-agent" mee bedoelen, en het is ook degene met de dunste evidence-basis. Het pitch: een agent detecteert een geheugenlek, triggert een rollende herstart tijdens een laag-verkeersvenster, bevestigt dat de service gezond is teruggekomen, en sluit de lus zonder iemand te pagen. Multi-stap remediatieplaybooks, uitgevoerd zonder het risico van een typefout of een overgeslagen stap in een 2uur runbook die voor het laatst in maart is getest.

Het werkt, wanneer de playbook smal is en de blast radius klein. Een rollende herstart van een stateless service tijdens een bepaald laag-verkeersvenster is een redelijk ding om te automatiseren. Een database failover tijdens kantooruren is niet, ongeacht hoe goed het track-record van de agent in een demo eruit ziet. De teams die hier verbrand raken, zijn niet degenen die restarts automatiseren, het zijn degenen die een vroeg succes hen praten om iets met werkelijk gegevensverliesrisico te automatiseren voordat de agent genoeg productiereps had om dat vertrouwen te verdienen.

Ons eigen lezen, van het toekijken hoe klanten AI Pilot in progressieve rollouts draaien: begin met de actie die gemakkelijkst om te keren en hardst om fout te gaan is. Herstart voor failover. Canary-percentage rollback voor database-schemawijzigingen. Laat het foutpercentage van de agent tegen laag-inzetacties de zaak voor hogere-inzetacties bouwen, op een tijdlijn gemeten in maanden, niet de eerste goede week.

General-purpose agenten verschijnen ook, en ze zijn de verkeerde vorm hiervoor

Zoek "AI agent voorbeelden" ergens buiten een ops-context en je landt in een volledig ander categorie: generalistische agenten gebouwd om open-ended taken te plannen en uit te voeren over een virtuele browser, terminal en bestandssysteem.

Manus opereert binnen een volledige virtuele computer en rapporteert met afgewerkte deliverables in plaats van een chat-antwoord. Het is werkelijk capabel voor onderzoeks- en multi-stap webtaken. Het is ook het verkeerde gereedschap voor een productie-rollout-beslissing, omdat de waardepropositie breedte is: het kan bijna alles doen, gegeven genoeg stappen en genoeg tijd. Een terugdraaibeslissing heeft de tegenovergestelde eigenschap nodig. Het moet snel zijn, smal en saai genoeg dat je exact kunt voorspellen wat het zal doen voordat het het doet.

Lindy zit dichter bij het ops-grenzende midden: geen-code workflows die inbox-triage, vergaderingplanning en terugkerende vervolgacties afhandelen. Nuttig voor de menselijke kant van een on-call rotatie (niemand wil handmatig een overdracht om 6 uur in de ochtend herschikken), nutteloos voor de werkelijke incident-response. Hetzelfde verhaal met Genspark's geen-code Super Agent, die surft, belt en op verzoek genereert, maar geen concept van een SLO-budget of canary-percentage heeft.

Geen daarvan is een klap tegen die producten. Ze zijn gebouwd voor een ander taak. De fout die we steeds zien, is teams die een general-purpose agent tegen een probleem met smalle ops evalueren, niet onder de indruk raken, en concluderen "AI agenten zijn niet gereed voor infra." Verkeerde categorie, verkeerde conclusie.

Waar deze agenten nog steeds falen, en waarom dat het interessante deel is

De faalmodus die niemand in de case study zet: agenten die 94% nauwkeurig zijn bij root-cause identificatie, liggen nog steeds één keer in de zeventien fout, en het foute antwoord klinkt meestal zeker-klinkend en specifiek genoeg om een on-call ingenieur twintig minuten de verkeerde service achterna te sturen voordat iemand merkt dat de correlatie die de agent vond, toevallig was, niet causaal. Deploy-timestamp correlatie is een reëel signaal. Het is geen bewijs. Een agent die is getraind om zeker te klinken, klinkt zeker over een toeval net zo gemakkelijk als over een echte oorzaak.

De tweede faalmodus is stiller: agent sprawl. Wanneer triage-, diagnostische en rollback-agenten allemaal draaien, moet iemand de agenten bewaken. Vroege 2026-deployments laten al zien dat de grootste operationele winst niet het MTTR-getal is, het is het bouwen van observabiliteit voor de agentlaag zelf, omdat een agent die stil stopt met triggeren erger is dan helemaal geen agent. Niemand merkt de afwezigheid van een waarschuwing.

Sla volledige autonomie over alles met irreversibele blast radius, ongeacht hoe goed de laatste twintig runs eruit zagen. Twintig goede runs is geen verdeling, het is een steekproef.

Moet je een agent in je rollout wiren, of wachten tot volgende cycle?

Als je team meer dan een handvol keer per maand pages en je postmortems houden herhaling van dezelfde root cause met verschillende servicenamen, een triage-agent betaalt voor zich veel sneller dan je verwacht, vooral door de "wat is er veranderd" fase van elk incident in te korten. Als je deploy-volume hoog genoeg is dat een mens niet elke rollout live kan bewaken, een SLO-gated rollback-agent verwijdert de 3uur oordeel volledig, wat het werkelijke punt is: je wilt niet dat de on-call ingenieur om 3 uur nadenkt, je wilt dat ze een knop drukken die overdag is ingesteld.

Als geen van beide nog waar is, de eerlijke stap is je SLO's eerst goed te instrumenteren. Een agent bovenop luidruchtige, ongedefinieerde foutbudgetten zal gewoon slechte beslissingen sneller automatiseren dan een mens zou hebben gedaan. De agent is het moeilijkste deel niet. Precies weten wat "slecht genoeg om te handelen" betekent, in getallen, voordat je de beslissing overgeeft aan iets dat niet moe wordt om 3 uur, is.