AI-agent för triage av CI-fel och incidenthantering

En driftsättning som misslyckas mitt i natten borde inte längre väcka någon. Ändå är det i många team fortfarande en jourhavande ingenjör som öppnar loggarna helt kallt, letar upp det skyldiga committet och skriver Slack-meddelandet som varnar de andra. En autonom AI-agent kan ta hand om det här första steget, utan att någonsin ersätta det mänskliga omdömet kring grundorsaken eller rättningen.

Problemet

Siffrorna kring tillförlitligheten i CI/CD-pipelines är inte bra. Enligt CircleCI:s rapport 2026 State of Software Delivery har andelen lyckade builds på huvudgrenen sjunkit till 70,8 procent, den lägsta nivån på fem år och klart under de 90 procent som leverantören rekommenderar (CircleCI, 2026). Konkret misslyckas ungefär tre av tio merge-försök redan innan de når produktion.

På incidentsidan konstaterar Runframes rapport State of Incident Management, publicerad i början av 2026, att andelen ingenjörstid som går åt till rutinmässigt driftarbete (svara på larm, sortera fel, eskalera information) har stigit tillbaka till 30 procent, en ökning för första gången på fem år trots investeringarna i AI (Runframe, 2026). Samma rapport uppger att ungefär två tredjedelar av alla larm som genereras varje dag ignoreras i brist på tid att sortera dem korrekt. Det är en storleksordning att ta med en nypa salt: rapporten samlar flera externa studier och kvalitativa intervjuer, det är inget direkt och enskilt mått.

DORA-rapporten 2025 om AI-assisterad mjukvaruutveckling drar åt samma håll i en grundläggande fråga: AI förstärker det som redan finns i en organisation, den fixar inte en dålig triageprocess, den gör den bara mer synlig, snabbare (DORA, 2025). En dåligt övervakad pipeline förblir dåligt övervakad, med eller utan AI, så länge ingen bevakar felen kontinuerligt.

Den här sista punkten spelar särskilt stor roll för team som kör med en liten jourgrupp, där en enda person bevakar flera tjänster samtidigt. Ett byggfel som dyker upp klockan tre på natten väntar sällan på att någon ska vakna för att klassas: antingen ignoreras det till morgonen, eller så väcker det någon för ett problem som, när det väl sorterats, visar sig vara mindre allvarligt. Båda utfallen kostar, det ena i längre lösningstid, det andra i jourtrötthet som byggs upp över tid.

Vad agenten gör, steg för steg

Hos Atako triggas den här agenten inte bara en gång för att sedan tystna: den körs kontinuerligt i sin egen isolerade miljö. Två ingångsmekanismer förser den med information, en inkommande webhook som teamet konfigurerar för att ta emot CI/CD-händelser, och ett cron-schema som agenten själv sätter upp för att periodiskt kontrollera status på arbetsflödena om webhooken skulle missa en händelse.

När ett fel väl inträffar läser agenten loggarna och jobbets stack trace för att klassificera typen av problem (kompilering, test, beroende, driftsättning), och korrelerar sedan felet med de senaste committen och pull requesterna för att identifiera den troliga upphovspersonen och den misstänkta ändringen. Den postar därefter en strukturerad sammanfattning på Slack i jourkanalen, med direktlänkar till jobbet och det aktuella committet, och öppnar samtidigt ett Jira-ärende kopplat till bygget. Om allvarlighetsgraden överstiger en tröskel som teamet har definierat (blockerad driftsättning, flera tjänster påverkade) går en extra eskalering ut till rätt personer. Slutligen skriver den en första version av incidentrapporten: tidslinje, påverkade tjänster, relevanta loggar, misstänkt orsak, medvetet lämnad öppen för mänsklig granskning i stället för att presenteras som en slutgiltig slutsats.

Integrationerna som används

Varje integration beviljas via ett precist grant, som begränsar exakt vad agenten får göra, aldrig en generell åtkomst till hela verktyget.

GitHub och GitLab ger läsåtkomst till pipelines, jobb och commits, med valfri skrivåtkomst för att skapa eller kommentera ett issue om grantet täcker det omfånget. På GitHub är de konkreta åtgärderna list_workflow_runs och get_job_logs_download_url på läsidan, create_issue och add_issue_comment på skrivsidan.

Slack tar emot triagesammanfattningarna via post_message, i den kanal teamet har valt, med möjlighet att schemalägga en påminnelse via schedule_message om en incident förblir öppen för länge.

Jira bär själva incidentärendet: create_issue vid öppning, update_issue och transition_issue under lösningens gång, ända fram till avslut.

Datadog, när teamet har anslutit det, gör det möjligt för agenten att korsa prestandamått och applikationsspår med CI-felet för att förfina sin hypotes om grundorsaken. PagerDuty har ingen egen integrationssida på Atako för närvarande, men går fortfarande att använda som larmdestination via en utgående webhook konfigurerad på Jira- eller Slack-sidan.

Det som är kvar för människan

Agenten beslutar aldrig själv om att fusionera en rättning, och det är ingen designdetalj, det är hur Atako strukturerar autonomin. Varje åtgärd agenten kan utföra på GitHub, GitLab, Jira eller Slack beror på ett explicit grant: vilka precisa åtgärder som är tillåtna, med vilket omfång (enbart läsning eller läsning och skrivning). Det omfånget gäller även om en skrivåtgärd av misstag skulle hamna i en lista över åtgärder tillåtna för läsning, och ingenting beviljas någonsin per automatik bara genom att koppla in ett verktyg.

Det lämnar tre saker tydligt på människans sida. Först, utredningen av grundorsaken och det tekniska beslutet om rättningen: agenten ger en utgångspunkt (loggar, misstänkt commit, historik), ingen slutgiltig diagnos. Sedan, skrivandet och sammanslagningen av koden, en åtgärd som till sin natur är mänsklig, utanför ramen för vad agenten kan göra. Slutligen post-mortem: justera allvarlighetströsklarna, se över runbooken, förbättra triagereglerna, ett teamarbete som agenten inte ersätter.

Den här uppdelningen är precis det som kallas human-in-the-loop: agenten absorberar den repetitiva och tidskrävande delen av triagen, människan behåller kontrollen över de beslut som verkligen räknas. För att kontrollera vad agenten faktiskt har gjort loggas varje integrationsanrop, med den berörda agenten, åtgärden, statusen (godkänd och utförd, nekad av en grant-kontroll, eller misslyckad hos leverantören) och latensen. Den här spårningen syns i agentens aktivitetstidslinje och, för en administratör, i hela företagets integrationslogg, som går att exportera till CSV.

Mätbart resultat

Den mest direkta vinsten är tiden mellan byggfelet och det ögonblick då rätt person har fullständig information för att agera. Inget behov längre av att vänta på att en människa märker larmet, öppnar loggarna och manuellt jämför med de senaste committen: agenten gör det kontinuerligt, även klockan tre på natten, utan att någonsin sova eller ändra humör beroende på veckans belastning. Det ersätter inte de klassiska DORA-måtten som driftsättningsfrekvens eller återställningstid efter fel, men det minskar den del av dessa mått som enbart beror på mänsklig tillgänglighet vid ett givet ögonblick.

Kostnaden följer Atakos Standard-plan: 20 euro per månad per agentplats (slot), med 1 000 krediter ingående varje månad för att täcka modellanropen som används för resonemang, klassificering och textframställning. För att räkna på avkastningen innan du sätter igång finns detaljerna på prissidan.