Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?

Deze studie analyseert systematisch de falen van LLM-agenten bij het bepalen van de oorzaak van cloudproblemen, identificeert twaalf veelvoorkomende valkuilen die voortkomen uit de gedeelde architectuur in plaats van modelbeperkingen, en toont aan dat het verrijken van communicatieprotocollen effectiever is dan prompt engineering om deze fouten te verminderen.

De kern

Stel je voor dat een groot, complex computersysteem (zoals een bank-app of een telefoonnetwerk) op een dag crasht. Er is een enorme paniek: geld stroomt weg, klanten zijn boos, en niemand weet waarom.

Vroeger moest een team van super-ervaren ingenieurs de "autopsie" uitvoeren. Ze keken naar duizenden logs, grafieken en foutmeldingen om de boosdoener te vinden. Vandaag de dag hopen we dat AI-agenten dit werk voor hen kunnen doen. Het idee is dat slimme computersystemen samenwerken om het probleem op te lossen, net als een team van detectives.

Maar dit artikel, geschreven door onderzoekers van de Hanyang Universiteit, vertelt een hardnekkig verhaal: deze AI-detectives falen systematisch. Zelfs met de allerbeste modellen is de kans dat ze het probleem écht vinden, slechts tussen de 4% en 12%.

Hier is wat er misgaat, vertaald in simpele taal met een paar creatieve vergelijkingen.

1. Het Probleem: De "Blinde" Detectives

De AI-agenten die de onderzoekers gebruikten, werken volgens een specifiek plan:

• De Chef (Controller): Deze AI denkt na, stelt hypotheses en geeft instructies.
• De Werknemer (Executor): Deze AI schrijft de code om de data te checken en geeft het resultaat terug.

Het probleem is dat ze niet goed samenwerken en vaak in de war raken. De onderzoekers keken niet alleen naar of het antwoord goed was, maar keken hoe de AI tot dat antwoord kwam. Ze ontdekten 12 soorten "valkuilen" (fouten).

2. De Drie Grootste Valkuilen (Met Vergelijkingen)

A. De Chef die fantaseert (Intra-Agent Falen)

De meest voorkomende fout (in 71% van de gevallen) is dat de "Chef" de data verkeerd interpreteert.

• De Vergelijking: Stel je voor dat je een detective bent die een spoor van modder ziet. Een goede detective zegt: "Er is iemand gelopen." De AI-Chef zegt echter: "Ah, dit is zeker een olifant die hier gelopen heeft!" Hij maakt er een verhaal van dat logisch klinkt, maar dat niet waar is. Hij "hallucineert" een betekenis die er niet is.
• Het Resultaat: De AI kijkt wel naar de data, maar trekt de verkeerde conclusies. Of ze kijken alleen naar de temperatuur en vergeten de motorolie te checken (onvolledig onderzoek).

B. De Telefoonlijn die te kort is (Inter-Agent Falen)

De Chef en de Werknemer communiceren alleen via korte, samengevatte berichten.

• De Vergelijking: Het is alsof de Chef de Werknemer belt en zegt: "Kijk naar die machine." De Werknemer belt terug: "Ik heb gekeken, alles lijkt oké." Maar de Chef heeft niet gehoord hoe de Werknemer keek, of welke foutmeldingen er waren.
• Het Gevolg: De Chef denkt dat de Werknemer het juiste ding heeft gedaan, terwijl de Werknemer eigenlijk een heel ander ding heeft gedaan. Ze blijven in een cirkel draaien ("Doe het nog eens!") zonder te beseffen dat ze vastlopen.

C. De Werkbank die instort (Agent-Environment Falen)

Soms is het probleem niet de AI zelf, maar de omgeving waarin ze werken.

• De Vergelijking: Stel je voor dat de AI werkt op een bureau dat steeds voller wordt met papieren. De AI vergeet oude papieren weg te gooien. Uiteindelijk is het bureau zo vol dat er geen ruimte meer is om te werken, en de hele sessie crasht. De AI merkt dit niet op voordat het te laat is.

3. Wat werkt (en wat niet)?

De onderzoekers probeerden verschillende dingen om dit op te lossen:

• Probeer 1: "Praat beter tegen de AI" (Prompt Engineering)
  Ze gaven de AI strengere instructies: "Kijk naar alles!" of "Fantaseer niet!"

  • Resultaat: Het hielp een beetje om de AI breder te laten kijken, maar het stopte het fantaseren niet. De AI bleef gewoon mooie, maar verkeerde verhalen bedenken. Het is alsof je een kind vertelt "niet te liegen", maar het kind blijft liegen omdat het zo is ingesteld.

• Probeer 2: "Geef meer details door" (Verbeterde Communicatie)
  Ze veranderden de manier waarop de Chef en de Werknemer praten. In plaats van alleen een samenvatting, stuurde de Werknemer nu ook de ruwe code, de foutmeldingen en de exacte resultaten door.

  • Resultaat: Dit werkte wonderbaarlijk goed. De Chef kon nu zien: "Oh, de Werknemer heeft een fout gemaakt in de code!" of "Oh, dit is een echte foutmelding, niet een verzonnen verhaal."
  • Het Effect: De fouten door slechte communicatie daalden met wel 15%. Bovendien werd het proces sneller, omdat ze niet meer in een cirkel hoefden te draaien.

• Probeer 3: "Een bewaker voor het geheugen"
  Ze voegden een automatische bewaker toe die ziet als het "bureau" (het geheugen) vol raakt, en stopt het proces voordat het crasht.

  • Resultaat: De crashes door vol geheugen verdwenen volledig.

4. De Grote Conclusie

De belangrijkste les uit dit onderzoek is: Het probleem zit niet in de "slimheid" van de AI-modellen.

Zelfs de slimste modellen (zoals Gemini 2.5 Pro) maken dezelfde fouten als de minder slimme modellen. Het probleem zit in hoe ze zijn gebouwd (het architectuur).

• Als je een slechte auto bouwt met een gebroken stuur, helpt het niet om een super-sportieve bestuurder (een slim AI-model) in de auto te zetten. De auto zal nog steeds van de weg raken.
• Je moet de auto repareren (de communicatie tussen de AI's verbeteren en de omgeving veiliger maken).

Kortom: Om AI-agenten echt goed te laten werken bij het oplossen van complexe computerproblemen, moeten we stoppen met alleen maar proberen ze "slimmer" te maken met betere instructies. We moeten hun samenwerking en werkomgeving opnieuw ontwerpen zodat ze eerlijk, duidelijk en veilig met elkaar kunnen praten.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?" in het Nederlands.

Probleemstelling

Grote schaal cloudsystemen zijn complex en storingen leiden tot aanzienlijke financiële verliezen en downtime. Geautomatiseerde Root Cause Analysis (RCA) is essentieel voor operationele stabiliteit. Hoewel er recent pogingen zijn gedaan om deze taak te automatiseren met Multi-Agent Systemen op basis van Large Language Models (LLM), zoals het OpenRCA-kader, presteren deze systemen in de praktijk slecht.

• Lage Detectie: De nauwkeurigheid voor het volledig correct identificeren van de oorzaak (component, tijdstip en reden) ligt tussen de 3,9% en 12,5% over verschillende LLM-modellen heen.
• Gebrek aan Inzicht: Bestaande evaluatiekaders beoordelen alleen het eindresultaat (juist of onjuist). Ze bieden geen inzicht in waarom het redeneringsproces van de agent faalt. Zonder dit procesniveau-inzicht kunnen ontwikkelaars niet bepalen of ze moeten investeren in sterkere modellen, betere prompts of een herontworpen agent-architectuur.

Methodologie

De auteurs voeren een systematische, procesgerichte foutanalyse uit om de oorzaken van de lage prestaties te diagnosticeren.

1. Experimentopzet: Ze voerden het volledige OpenRCA-benchmark uit (335 incidenten uit drie domeinen: Telecom, Bank en Market) over vijf verschillende LLM-modellen (Gemini 2.5 Pro, GPT-5 mini, GPT-OSS 120B, Solar Pro 2, en Claude Sonnet 4).
2. Datavolume: Dit resulteerde in 1.675 agent-runners, goed voor ongeveer 1,38 miljard tokens en 609,9 uur rekentijd.
3. Analyse Framework: In plaats van alleen het eindantwoord te kijken, classificeren ze elke fout in één van drie architecturale categorieën:
   • Intra-Agent Redenering: Fouten binnen het denken van één agent (Controller).
   • Inter-Agent Communicatie: Fouten in de uitwisseling tussen de Controller en de Executor.
   • Agent-Omgeving Interactie: Fouten bij de interactie met de uitvoeringsomgeving (telemetrie-data en runtime).
4. Taxonomie: Ze ontwikkelden een taxonomie van 12 specifieke "valkuilen" (pitfalls) en gebruikten een mens-in-de-lus pipeline (met Claude Code als analyse-agent) om deze fouten te classificeren.

Belangrijkste Bijdragen

• Procesniveau Analyse: Een nieuwe methodologie die verder gaat dan resultaatgebaseerde evaluatie en de interne redeneringsfouten van RCA-agenten diagnoseert.
• Taxonomie van 12 Valkuilen: Een gestructureerde lijst van fouttypes, variërend van hallucinaties tot communicatieproblemen.
• Architecturale Diagnose: Empirisch bewijs dat de dominante foutmodi niet liggen bij de beperkingen van individuele LLM-modellen, maar bij de gedeelde agent-architectuur zelf.
• Gestuurde Mitigatie-experimenten: Het testen van specifieke interventies (prompt engineering vs. architecturale wijzigingen) om te zien welke effectief zijn.

Resultaten en Bevindingen

1. Dominante Valkuilen (Ongeacht het Model)

Ongeacht het gebruikte model (van open-source tot geavanceerde gesloten modellen) treden dezelfde kritieke fouten op, wat wijst op een fundamenteel probleem in het framework:

• Hallucinatie in Interpretatie (71,2%): De agent verzon een interpretatie van de data die logisch leek maar feitelijk onjuist was. Dit kwam bij alle modellen voor (>66%).
• Incomplete Verkenning (63,9%): Agents negeerden vaak hele categorieën van KPI's of componenten (bijv. alleen CPU meten en netwerkdata negeren).
• Symptoom als Oorzaak: Agents stopten te vroeg en namen het eerste gevonden symptoom als de root cause, zonder de volledige causale keten te traceren.
• Codegeneratie Fouten: Variërend sterk per model (van 1,8% bij Gemini tot 65,5% bij Claude Sonnet 4), wat aangeeft dat code-generatie betrouwbaarheid nog steeds een onderscheidende factor is.

2. Communicatieproblemen

De communicatie tussen de Controller en Executor (via natuurlijke taal samenvattingen) leidt tot informatieverlies:

• Instruction-Code Mismatch: De Executor genereerde code die niet overeenkwam met de intentie van de Controller (20-26% van de stappen bij sommige modellen).
• Zinloze Herhaling: Agents bleven dezelfde mislukte instructies herhalen omdat ze geen gedeelde geschiedenis hadden.

3. Effectiviteit van Mitigatie

De auteurs testten verschillende oplossingen:

• Prompt Engineering (Intra-Agent): Het toevoegen van instructies om breder te zoeken of valkuilen te vermijden, had geen significante verbetering op de interpretatiefouten. Agents bleven data hallucineren ondanks betere prompts.
• Verrijkte Communicatie (Inter-Agent): Door de protocol te wijzigen zodat de Executor niet alleen een samenvatting, maar ook de gegenereerde Python-code, ruwe uitvoer en stacktraces terugstuurt:
  • Verminderde communicatiefouten met tot 15 procentpunten.
  • Verhoogde de "perfect detection" score voor alle modellen.
  • Verlaagde de totale uitvoeringstijd met 22,3% (door minder stappen nodig te hebben).
• Omgevingsbeheer: Een "memory watcher" die OOM (Out of Memory) crashes detecteerde en de agent dwong tot een efficiëntere implementatie, elimineerde alle OOM-fouten.

Betekenis en Conclusie

De studie concludeert dat de lage prestaties van AI-agenten bij cloud-RCA niet primair een probleem van de LLM-modellen zelf zijn, maar van de architectuur waarin ze opereren.

• Prompt engineering is onvoldoende: Het kan de verkenningssfeer verbreden, maar lost de fundamentele interpretatiefouten (hallucinaties) niet op.
• Architecturale wijzigingen zijn noodzakelijk: Het verbeteren van de communicatiekanalen (bijv. het delen van code en ruwe data tussen agents) en het toevoegen van verificatiemodules levert de grootste en meest consistente verbeteringen op.
• Toekomst: De ontwikkelde taxonomie en diagnose-methodiek vormen de basis voor het bouwen van betrouwbaardere autonome agenten en voor het ontwikkelen van monitoringssystemen die foutpatronen in real-time kunnen detecteren.

Kortom, voor succesvolle geautomatiseerde RCA moet de focus verschuiven van het kiezen van het "slimste" model naar het herontwerpen van de agent-interactie en -architectuur.