Przyklady agentow AI w DevOps - Cztery waskie kategorie

Przyklady agentow AI w DevOps ktorymi poszukuja engineers infrastruktury czytaja sie zwykle jak katalog: chatboty, asystenci sprzedazy, roboty HR. Nic z tego nie odpowiada na pytanie ktorego rzeczywiscie zadaje platform engineer: jak wyglada agent gdy jest dopuszczony blisko pipeline deployment? Uczciwa odpowiedz jest wezszej i mniej blyszczaca niz sugeruja slajdy marketingowe. Pracujace w produkcji przyklady agentow infrastruktury dziela sie na cztery kategorie: agenty autorevert, agenty triage przyczyn, agenty diagnostyczne i executory runbook. Wszystko inne to chatbot z lepszym promptem.

Wybralismy je z case studies publicznych, postmortemow vendorow i naszej pracy nad SLO-gated auto-rollback. Zaden z nich nie jest w pelni autonomiczny od konca do konca. Wszystkie sa waskie, audytowalne i ograniczone do jednego zadania.

Co naprawde oznacza agent w pipeline deployment

Dashboard ktorej wskazuje anomalie to nie agent. Bot Slack ktorzy wysyla ping gdy p99 przekracza prog to tez nie agent. To cronjob z lepsza kopia. Rozroznienie ktorej ma znaczenie dla platform teams: agent planuje sekwencje akcji w wiecej niz jednym systemie, dostosowuje ten plan na podstawie tego co znajduje, i wykonuje bez tego aby czlowiek zatwierdzal kazdy krok.

Zgodnie z tym kryterium wiekszosc narzedzi AI DevOps jest wciaz asystentami, nie agentami. Dostarcza informacje szybciej. Te cztery kategorie ponizej przekraczaja linie rzeczywistego dzialania, przynajmniej w okreslonym blast radiusie.

Agent autorevert: Automatyczne cofniecie przed zawiadomieniem czlowieka

To jest kategoria najblizsza temu co my budujemy. Agent obserwuje burn rate SLO podczas rollout i cofa deployment gdy budzet przekracza prog, przed tym zanim czlowiek otworzyl dashboard. Bez osadu, bez 3am watku Slack pytajacego czy to dosc zle by cofnac. Prog jest ustalany w dzien, gdy nikt nie ma adrenaliny w obliczeniach.

Minimalna wersja gate wyglada tak:

type RolloutState = {
  errorBudgetBurn: number;
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14;
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}

To jest cale rozroznienie. Czesc agenta to wszystko wokol: pobieranie live error rate i latency ze stacku observability, porownanie przeciwko pre-declared SLO, wykonanie revert przez API deployment, i napisanie strukturyzowanej notatki do kanalu incydentu wyjasniajacy co to wyzwolilo i co widzialo. Obserwowalismy ten pattern w produkcji u Series C fintech robiacy mniej wiecej 40 deployow dziennie. Mediana czasu od detektora burn do revert: ponizej 90 sekund. Mediana teamu samego - zmierzona w postmortemach z ostatnich szesc miesiecy - to byla 11 minut.

Pomij ten pattern jesli twoja deploy frequency jest niska wystarczajaco ze czlowiek juz obserwuje kazdy rollout na zywo. Agent zarabia swoje utrzymanie przy volumnie, nie przy 2 deployach tygodniowo.

Agent do root-cause triage: Od alertu do watku Slack w minutach

To jest kategoria z najwieksza iloscia publicznych danych za soba w tej chwili, bo jest najlatwiej sprzedawalna i najlatwiej mierzalna. AWS DevOps Agent na przyklad jest wyzwalany przez CloudWatch alarm lub strone PagerDuty, formuje hipoteze o przyczynie, queryuje logi i traces by ja testowac, koreluje anomalie przeciwako recent deploy timestamps, i robi posta do Slack z ustaleniami i rekomendowana mitigacja. AWS raportuje do 75% nizsze MTTR w swoich dokumentowanych deploymentach, a case study Western Governors University konkretnie cytuje czas rezolucji spadajacy z okolo dwoch godzin do 28 minut (zrodlo).

Czesc warta zauwazyenia to nie procent. To audit trail requirement: kazdy krok reasoning ktorej agent podejmuje jest logowany w immutable rekordzie ktorej agent nie moze sam zmodyfikowac. To nie nice-to-have. Jesli agent bedzie korelowac twoja historie deploy z error spike'iem i powiedziec on-call engineerowi to prawdopodobnie zmiana checkout service, musisz byc w stanie rekonstruowac dokladnie jak do tego doszlo gdy to bedzie bledne.

Widzielismy ten sam pattern pod innymi nazwami: Wild Moose obiecuje root-cause surfacing w ponizej minuty, HolmesGPT diagnozuje cloud alerty przez te sama detect-correlate-explain petle. Mechanika zbiegaja sie bo problem ma wszedzie ten sam kszlat: alarm palac sie, agent czyta telemetrie, agent proponuje przyczyne, czlowiek potwierdza lub overriduje.

Warte setup cost jesli twoj team page'uje wiecej niz pare razy tygodniowo i twoje postmortemach keep cytuja zajelo zbyt dlugo znalezc rzeczywista przyczyne. Pomij jesli incydenty sa rare wystarczajaco ze tuning time nie zwroci sie zanim zmiana architektury robi training data modelu niewieza.

Agent do diagnostyki Kubernetes: Wezszy, bezpieczniejszy slice

Kubernetes debugging to gdzie wiele z tych narzedzi zaczeol sie, bo kubectl output to dokladnie tego rodzaju gesty, structured tekst ktorym LLM jest dobry. k8s-GPT skanuje klaster i wyjasnia failury w zwyklym jezyku: dlaczego pod jest stuck w CrashLoopBackOff, dlaczego PVC sie nie binduje, dlaczego service nie ma endpoints. On nie dziala, on wyjasnia. To jest celowe scopowanie, i to jest wlasciwy call dla narzedzia ktorego junior engineer moze uruchomic przeciwako klasterowi ktorej nie do konca rozumie.

Nastepny tier dziala, ostrozniej. Agenty Guardian-style detektuja problem, znajduja root cause, i otwieraja fix PR zamiast pushowac bezposrednio do klastera. Ten jeden extra krok, PR zamiast live changeu, to cale roznica pomiedzy useful automation a rzecza ktorej spowodowala wtorek outage. PR dostaje review. Bezposredni kubectl apply od agenta nie robi, chyba ze sam zbudowales krok review.

Warstwa docs ma tu wiecej znaczenia niz ludzie oczekuja. Gdy agent wyjasnia Kubernetes failure'a lub otwiera fix PR, runbook ktorej implicitnie nastepuje albo zyje w glowie twojego teamu albo zyje gdzies gdzie agent i nastepny engineer moga rzeczywiscie czytac. Teamy ktorze trzymaja runbooki w docs-as-code narzedziy z queryable AI layerem widzą mniej czekaj dlaczego my to robimy w ten sposob watkow szesc miesiecy pozniej. Agent output robi stale dokumentacje oczywista szybciej niz czlowiek czytajacy to kiedys.

Executor runbook: Co sie dzieje gdy pozwolisz agentowi dotknacc prod

To jest kategoria ktorza ludzie maja na mysli gdy mowia w pelni autonomiczny SRE agent, i to jest tez ta ktorza ma najtensza baze evidencji. Pitch: agent detektuje memory leak, wyzwala rolling restart w low-traffic oknie, potwierdza ze service powrocil healthy, i zamyka petle bez pagowania nikogo. Multi-step remediation playbooki, wykonane bez ryzyka typo lub skokowego kroku w 2am runbooku ktorej ostatni raz byl testowany w marcu.

To dziala, gdy playbook jest wazki a blast radius maly. Rolling restart stateless service'u w zdefiniowanym low-traffic oknie to reasonable rzecz by automatyzowac. Database failover w business hours nie jest, bez wzgledu na jak dobrze agent track record wyglada w demo. Teamy ktorze sie pala tutaj nie sa tymi ktorze automatyzuja restarty.

Nasz read, z obserwacji customerow drut AI Pilot w progressive rollouts: zacznij z action ktorza jest najlatwiej do reversowania i najtrudniejsza by sie myllic. Restart przed failover. Canary percentage rollback przed database schema changes. Pozwol agentowi error rate przeciwako low-stakes actions budowac case dla higher-stakes jeden, na timeline mierzonym w miesiace.

Agenty general-purpose sie pokazuja, i sa zly kszlat na to

Szukaj AI agent examples gdziekolwiek poza ops kontekstem i wyladuj na zupelnie innej kategorii: generalist agenty zbudowane by planowac i wykonywac open-ended taski w wirtualnym browserze, terminalu i file systemie.

Manus operuje wewnatrz pelnego wirtualnego komputera i reporta z finished deliverables zamiast odpowiedzi chat. On jest genuinely capable przy research i multi-step web tasks. On jest tez zly tool dla production rollout decyzji, bo jego value proposition jest breadth: on moze zrobic prawie cokolwiek. Rollback decyzja potrzebuje opposite property. Potrzebuje byc szybki, wazki, i nudny wystarczajaco ze mozesz predict dokladnie co zrobi zanim to robi.

Lindy siedzi blizej ops-adjacent middle: no-code workflows ktorze obsługuja inbox triage, meeting scheduling, i recurring follow-ups. Useful dla human side on-call rotation (nikt nie chce manually reschedule handoff o 6am), useless dla actual incident response. Taka sama historia z Genspark no-code Super Agent, ktorej browses, calls, i generuje on request ale nie ma pojecia o SLO budzecie lub canary percentu.

Nic z tego to nie jest knock przeciwako tym produktom. Oni sa zbudowani dla innego joba. Blad ktorej ciagile widzimy to teamy oceniajace general-purpose agent przeciwako narrow ops problemowi, dostajacy unimpressed, i conclude AI agents nie sa ready dla infra. Zla kategoria, zla conclusion.

Gdzie te agenty wciaz sie nie sprawdzaja, i dlaczego to jest interesting czesc

Failure mode ktoraze nikt nie stawia w case study: agenty ktorze sa 94% accurate na root-cause identification wciaz myła sie jeden raz w siedemnascie, i zla odpowiedz zwykle brzmi confident i specyficna wystarczy by wyslac on-call engineera gonic zly service przez dwadziescia minut. Deploy timestamp correlation to real signal. To nie jest proof. Agent trained by brzmaiec certain bedzie brzmaiec certain o coincidence dokladnie tak latwo jak o real cause.

Drugi failure mode jest cichszy: agent sprawl. Po tym jak triage, diagnostic, i rollback agenty sa wszyscy running, ktos musi monitorowac agenty. Early 2026 deployments pokazuja juz ze biggest operational win nie jest MTTR numer, to building observability dla agent layer siebie, bo agent ktorej silently przestaje sie wzyzwalac jest gorszy niz zaden agent wcale. Nikt nie zauważa absencje alertu.

Pomij full autonomy na cokolwiek z irreversible blast radiusem, bez wzgledu na jak dobrze ostatnie dwadziescia runow wyglada. Dwadziescia dobrych runow to nie dystrybucja, to sample.

Drut agent w rollout, czy czekac na nastepny cykl?

Jesli twoj team page'uje wiecej niz handful czasami miesiecy i twoje postmortemach keep powtarzaja te sama root cause z innymi service nazwami, triage agent zwroci sie sobie szybciej niz oczekujesz, glownie shortening co sie zmieniło fazie kazedego incydentu. Jesli twoja deploy volume jest wysoka wystarczajaco ze czlowiek nie moze obserwowac kazdy rollout live, SLO-gated rollback agent usuwa 3am osad calkowicie, ktorzy to rzeczywisty point: ty nie chcesz ze on-call engineer mysli o 3am, ty chcesz ze oni press button ktorey byl configured w dzien.

Jesli zaden nie jest jeszcze true, honest move to instrument twoim SLOs prawidlowo najpierw. Agent siadanie na top of noisy, undefined error budgets bedzie po prostu automatyzowac zle decyzje szybciej niz czlowiek by je zrobil. Agent nie jest trudna czesc. Znanie dokladnie co zle wystarczajaco by dzialac oznacza, w liczbach, zanim ty handlujesz decyzje do cos ktorze sie nie zmecza o 3am, to jest.