Co kilka miesięcy branża tworzy nowy termin na oprogramowanie, które rzekomo myśli samodzielnie. Obecnie tym słowem jest „Agentic AI”. Dostawcy chętnie umieszczają je na stronach docelowych i w prezentacjach sprzedażowych. Jednak etykieta jest jedynie hasłem marketingowym, dopóki system nie przetrwa kontaktu z Twoim środowiskiem, Twoimi danymi i Twoimi trybami awarii. Samo słowo nie mówi nic o bezpieczeństwie, niezawodności czy dopasowaniu.

Czas przestać czytać listy funkcji i zacząć mierzyć możliwości.

Problem z etykietami

Inżynierowie sprzedaży będą pokazywać Ci pulpity nawigacyjne, rozwijane menu wielomodelowe i dostęp mobilny jako dowód na „agentową” architekturę. To wybory interfejsu, a nie gwarancje zachowania. Produkt może wyglądać nowocześnie, a mimo to rozsypać się w momencie, gdy musi zmienić plan po przekroczeniu czasu oczekiwania API (timeout).

Liczy się to, czy system faktycznie zachowuje się jak autonomiczny agent. Czy dzieli pracę na kroki? Czy wchodzi w interakcję z rzeczywistymi systemami w ramach ściśle określonych granic? Gdy coś ulega awarii, czy się adaptuje, czy po prostu zawodzi i czeka? Dopóki nie odpowiesz na te pytania, opierając się na dowodach specyficznych dla Twojego stosu technologicznego, kupujesz koncepcję, a nie produkt.

Pięć testów możliwości, które naprawdę mają znaczenie

Oceniam każde twierdzenie dotyczące „agentowości” pod kątem pięciu konkretnych możliwości. W przypadku każdej z nich zadaję proste pytanie selekcyjne: czy zachowanie jest udokumentowane, zweryfikowane w pilotażu, czy wciąż nieznane? „Nieznane” jest domyślnym stanem. To na produkcie spoczywa ciężar udowodnienia czegoś innego.

Planowanie. Czy system rozkłada niejednoznaczny cel na uporządkowane, weryfikowalne kroki? Każdy potrafi wygenerować listę zadań. Prawdziwym testem jest poradzenie sobie z chaotycznym celem, takim jak „zredukuj nasze wydatki na chmurę o piętnaście procent w tym kwartale”. Prawdziwy agent zaplanuje audyt obecnego zużycia, zidentyfikuje nieaktywne zasoby, przygotuje rekomendacje dotyczące optymalizacji rozmiaru (rightsizing) i zaplanuje żądania zmian w odpowiedniej kolejności. Jeśli poda Ci ogólny esej w pięciu punktach i uzna zadanie za wykonane, to nie jest planowanie. To streszczanie.

Narzędzia. Czy działa na rzeczywistych systemach w określonym zakresie? Wywołanie symulowanego (mock) API w dopracowanym demo jest łatwe. Uwierzytelnienie się w Twoim produkcyjnym systemie CRM przy użyciu poświadczeń z minimalnymi uprawnieniami, zapisanie rekordu i zarejestrowanie transakcji jest trudne. Musisz dokładnie wiedzieć, z jakimi systemami wchodzi w interakcję, jakie klucze posiada i gdzie kończy się promień rażenia (blast radius). Zakres musi być ograniczony. Jeśli agent domyślnie ma uprawnienia do zapisu na produkcji, nie masz agenta. Masz zagrożenie.

Korekta. Czy zmienia swój kolejny krok po awarii? To tutaj większość prototypów upada. Gdy trzeci krok zwraca błąd 503 lub niezgodność schematu, czy agent zapętla się w nieskończoność, halucynuje komunikat o sukcesie, czy dostosowuje swoją ścieżkę? Prawdziwa korekta oznacza zaobserwowanie awarii, ponowne zaplanowanie pozostałej części przepływu pracy i wykonanie nowej ścieżki bez naruszania ograniczeń. Pętla ponowień (retry loop) ubrana w optymizm to nie korekta.

Kontekst. Czy zachowuje ograniczenia aktywne na każdym kroku? Sama pamięć nie wystarczy. Jeśli pierwszy krok ustanawia sztywną regułę, taką jak „nie przekraczaj budżetu pięciuset dolarów” lub „wyklucz dane klientów z UE”, siódmy krok nie może zignorować tego limitu tylko dlatego, że kontekst promptu uległ zmianie. Dotyczy to reguł zgodności (compliance), głosu marki, hierarchii zatwierdzania i kontroli dostępu. Zachowanie kontekstu to miejsce, w którym modele z długim kontekstem muszą spotkać się z klasycznym zarządzaniem stanem.

Nadzór. Czy człowiek może zatrzymać lub wznowić proces? Potrzebujesz bezpieczników (circuit breakers), które są granularne, a nie tylko wyłącznika awaryjnego (kill switch) na maszynie wirtualnej. Czy ktoś może sprawdzić plan po drugim kroku i zatwierdzić trzeci? Jeśli zewnętrzna zależność zawiedzie, czy człowiek może to naprawić i wznowić przepływ pracy bez utraty stanu? Nadzór to nie log audytowy, który czytasz po wystąpieniu katastrofy. To żywy mechanizm interwencji.

Dowody są ważniejsze niż deklaracje

Demo to nie współczynnik niezawodności. „Ptaszka” przy pozycji w arkuszu porównawczym dostawcy nie jest dowodem. Gdy przedstawiciel handlowy mówi, że produkt „koryguje działania po niepowodzeniu testu”, Twoim kolejnym krokiem powinno być poproszenie o kartę dowodową.

Karta dowodowa zastępuje zwykłe zaznaczenie konkretami. Wygląda ona następująco:

  • Możliwość: Korekta
  • Twierdzenie: Koryguje działania po niepowodzeniu testu
  • Dowód: Oczekuje na kontrolowany zestaw testowy (controlled fixture)
  • Właściciel: Zespół ds. Developer Experience
  • Zatrzymaj, jeśli: Korekta zmienia zatwierdzony interfejs

Ten format wymusza klarowność. Oddziela obietnice marketingowe od dowodów. Przypisuje odpowiedzialność, dzięki czemu gdy agent uszkodzi zatwierdzony interfejs podczas próby poprawy, dokładnie wiesz, który zespół zostanie wezwany do działania. Bez właściciela nie ma rozliczalności. Bez warunków zatrzymania nie ma barier bezpieczeństwa.

Zanim uruchomisz jakikolwiek pilotaż, zdefiniuj trzy rzeczy na piśmie. Po pierwsze, zadania. Powinny one wynikać z rzeczywistej logiki biznesowej, a nie z syntetycznych benchmarków. Po drugie, testy awarii. Cofnij klucz API w trakcie działania, wstrzyknij błędną odpowiedź JSON lub podwój oczekiwane opóźnienie. Po trzecie, warunki zatrzymania. Muszą być one automatyczne, a nie stanowić ręcznego przycisku paniki, na który masz nadzieję, że ktoś zauważy.

Jak weryfikować obietnice dostawców

OpenAI sugeruje, że agenci wymagają pięciu komponentów: modeli, narzędzi, instrukcji, barier ochronnych (guardrails) i interwencji człowieka. Możesz potraktować tę listę jako zestaw pojęć do zadawania pytań dostawcom, nie przyjmując przy tym ich konkretnej architektury.

Zapytaj, który model odpowiada za planowanie, a który za samo generowanie. Zapytaj, które uprawnienia narzędzi są zakodowane na sztywno, a które są dynamiczne. Zapytaj, gdzie egzekwowane są bariery ochronne – w warstwie promptu czy w silniku orkiestracji. Zapytaj, czy interwencja człowieka to wbudowany punkt kontrolny, czy e-mail typu post-mortem wysłany po tym, jak agent zdążył już zniszczyć twoją bazę danych. Nie kupujesz stosu technologicznego OpenAI. Używasz ich ram (framework) do obnażenia luk u kogoś innego.

MonkeyCode oferuje ścieżkę open-source oraz darmową wersję chmurową. To połączenie sprawia, że rozpoczęcie pilotażu jest tanie. Jednak tani wstęp to nie to samo co zweryfikowany sukces. Nieznane części systemu pozostają nieznane, dopóki nie uruchomisz własnych zadań na własnej infrastrukturze. Nie daj się zwieść darmowemu biletowi, myśląc, że trudne pytania zostały już rozstrzygnięte.

Zasada zakupowa, która oszczędza budżet

Moja zasada dotycząca rozszerzania pilotażu agentowego do etapu produkcyjnego jest prosta. Zwiększam zakres i budżet tylko wtedy, gdy krytyczne możliwości mają dowód działania oraz jasnego właściciela w przypadku awarii. Nie slajd z mapą drogową. Nie kolejka zgłoszeń wsparcia. Dowód oznacza logi z twojego środowiska. Właściciel oznacza konkretną osobę, która odpowiada za dany tryb awarii.

Jeśli dostawca nie może przedstawić dowodów lub jeśli twój wewnętrzny zespół nie może wyznaczyć właściciela, nie jesteś gotowy na rozszerzenie projektu. Jesteś gotowy na dalsze testy.

O czym pamiętać: Słowo „Agentic” to strzał startowy dla twojej ewaluacji. To nie jest meta. Potraktuj je jako impuls do zadawania trudniejszych pytań, przeprowadzania surowszych pilotaży i żądania dowodów, które mają znaczenie w twojej organizacji. Jeśli produkt nie potrafi przejść pięciu testów możliwości na twoim terenie, przy twoich awariach, to nie jest on prawdziwie agentowy. To tylko kolejna demonstracja.

Źródło: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi