AX. Agentic Experience

Ponieważ w tym nowym obszarze jakości nie ma pełnej spójności nazewnictwa, to podkreślamy, że na potrzeby tego artykułu Agentic Experience, czyli AX, opisuje:

• jak człowiek doświadcza współpracy z agentem,
• jak agent zachowuje się w trybie autonomicznym,
• jak agent podejmuje decyzje, eskaluje, tłumaczy się i koryguje swoje błędy.

Testy nie są tu tylko sprawdzeniem poprawności odpowiedzi (jak w testach LLM), ani tylko przejściem przez proces w interfejsie (jak w UX). Jest to zupełnie nowe podejście do prowadzenia testów, przy użyciu znanych nam już narzędzi i technik. 

Jak wygląda AX?

Przedstawmy sobie współpracę Agenta z Użytkownikiem na przykładzie realizacji prostej rezerwacji wizyty u fryzjera. Użytkownik wydaje agentowi (np. w przeglądarce agentowej) polecenie zarezerwowania mu wizyty u fryzjera na najbliższy czwartek w godzinach między 10:00 a 13:00. Dodatkowo dokłada parametry: w odległości nie większej niż 15 minut pieszo oraz oceniany na 4,5 i wyżej. W odpowiedzi Agent przez przetworzenie tekstu dokonuje przeszukania miejsc spełniających wymagania i następnie wchodzi do systemu rezerwacji, by sprawdzić dostępność miejsc. Jeśli znajdzie więcej niż jedno spełniające kryteria miejsce, powinien zapytać użytkownika o jego preferencje. Z drugiej strony, jeśli już wspólnie przechodzili przez ten proces i użytkownik już dokonał wyboru, to Agent może zasugerować, że ostatnio wybrano jedną z opcji. Po dokonaniu wyboru Użytkownik zostaje zapisany na wizytę, a potwierdzająca informacja zostaje mu przekazana. Jak widać w takim procesie może pojawić się wiele wyjątków, jak np. brak dostępnych terminów spełniających wymagania, czy brak wsparcia dla obsługi Agentów po stronie usługi rezerwacji (A2M). Obsługa tych zdarzeń to szeroki kontekst konwersacji, jaką prowadzi Agent z Użytkownikiem i zakres, który wymaga zbadania w ramach AX. 

Główne wymiary testowania Agentic Experience

Testowanie Agentic Experience wymaga zmiany perspektywy w porównaniu do klasycznej kontroli jakości. Nie skupiamy się już wyłącznie na poprawności odpowiedzi czy stabilności interfejsu, lecz na tym, w jaki sposób agent zachowuje się w relacji z użytkownikiem i jak ta relacja ewoluuje w czasie. Kluczowe staje się zrozumienie, gdzie kończy się autonomia agenta, a gdzie zaczyna potrzeba kontroli i przewidywalności realizowana po stronie człowieka. Podstawowym wymiarem AX jest więc balans pomiędzy autonomią agenta a kontrolą użytkownika. Agent, który podejmuje decyzje samodzielnie, może znacząco przyspieszyć realizację celów, ale tylko wtedy, gdy użytkownik rozumie zakres tej autonomii i ma możliwość jej ograniczenia. Z perspektywy testowej oznacza to konieczność sprawdzania, czy agent działa proaktywnie tylko tam, gdzie jest to uzasadnione, oraz czy potrafi w odpowiednim momencie poprosić o zgodę lub potwierdzenie do dalszego działania. Równie istotna jest możliwość przerwania działania agenta, zmiany jego decyzji lub przejęcia kontroli bez utraty kontekstu. Brak takich mechanizmów bardzo szybko prowadzi do utraty zaufania, nawet jeśli sam wynik końcowy jest poprawny.

Przykład. Agent zmienia wymogi Użytkownika bez pytania go o zdanie i rezerwuje wizytę na 14:00.

Drugim obszarem jest przewidywalność zachowania agenta. Inteligencja systemu nie może być odbierana jako losowość. Użytkownik musi mieć poczucie, że w podobnych sytuacjach agent zachowa się w podobny sposób i że jego decyzje wynikają z określonych zasad, a nie z chwilowego „humoru” modelu. W testach AX oznacza to weryfikację spójności decyzji w czasie, zarówno w obrębie jednej sesji, jak i pomiędzy różnymi interakcjami. Szczególną uwagę należy zwracać na regresję zachowań po zmianach komend, modeli lub konfiguracji narzędzi, ponieważ nawet drobne modyfikacje mogą prowadzić do niezamierzonych zmian w stylu i logice działania agenta.

Przykład. Agent za każdym razem zmienia miejsce wizyty „nie pamiętając” o wcześniejszych preferencjach Użytkownika.

Kolejnym wymiarem, który bezpośrednio wpływa na jakość Agentic Experience, jest transparentność oraz zdolność agenta do wyjaśniania swoich decyzji. Agent, który podejmuje działania bez uzasadnienia, szybko staje się niegodny zaufania, nawet jeśli działa poprawnie. Testowanie w tym obszarze polega na sprawdzaniu, czy agent potrafi jasno komunikować, dlaczego wybrał daną ścieżkę, z jakich danych lub założeń skorzystał oraz jakie ma ograniczenia. Równie ważna jest forma tych wyjaśnień — muszą być zrozumiałe dla użytkownika i dostosowane do kontekstu, a nie sprowadzać się do technicznego lub nadmiernie rozbudowanego opisu.

Przykład. Agent podejmuje decyzję o wizycie, bazując na opłaconej przez usługodawcę reklamie, nie informując o tym użytkownika. 

Najbardziej krytyczne momenty dla Agentic Experience pojawiają się jednak w sytuacjach błędów i przypadków granicznych. To właśnie wtedy ujawnia się rzeczywista jakość zachowania agenta. Testy AX muszą obejmować scenariusze niepełnych lub sprzecznych danych, błędnych założeń użytkownika, konfliktów celów oraz awarii narzędzi, z których agent korzysta. W takich sytuacjach ważne jest, czy agent potrafi przyznać się do niepewności lub błędu, zamiast generować pozornie pewne, ale nieprawdziwe odpowiedzi. Dobrze zaprojektowany agent powinien umieć zatrzymać się, eskalować problem lub zaproponować alternatywne rozwiązanie, zamiast brnąć w nieprawidłowy tok działania.

Przykład. Użytkownik podaje sprzeczne dane o wizycie u fryzjera i zabiegu na paznokcie. Jak Agent poradzi sobie z taką sytuacją?

Wszystkie te wymiary składają się na spójne doświadczenie współpracy z agentem. Testowanie AX nie polega więc na izolowanym sprawdzaniu pojedynczych funkcji, lecz na ocenie relacji pomiędzy użytkownikiem a systemem jako całości. To relacja, w której zaufanie, przewidywalność i poczucie kontroli są równie ważne jak skuteczność samego agenta.

Testowanie AX ≠ testowanie promptów

Często mylimy pojęcie testowania AI rozumianego jako odpowiedzi na prompty od testowania współpracy z agentami. Pomimo niemalże identycznych mechanizmów podejmowania decyzji wewnątrz te dwa obszary różnią się od siebie znacząco. 

Widać czytelnie, że AX wymaga testów scenariuszowych i eksploracyjnych, a nie tylko zestawów danych wejście–wyjście. Okazuje się, że tak jak w przypadku wielu innych testów AI, dużo skuteczniejsze od samego automatyzowania będzie testowanie ręczne przy użyciu narzędzi przetwarzania danych. 

Typy testów w AX

Jakie możemy wyróżnić typy testów w odniesieniu do weryfikacji AX?

1. Testy ścieżki agenta – czyli jak agent zachowuje się w standardowych warunkach
   1. pełna ścieżka: od celu → plan → akcje → wynik,
   2. testy długiej pamięci współpracy z użytkownikiem i rozumienia kontekstu.
2. Testy eksploracyjne – czyli jak agent odpowie na „zabawy” i niestandardowe zachowania użytkownika w trakcie interakcji
   1. prowokowanie agenta,
   2. zmiana celu w trakcie,
   3. niejednoznaczne polecenia.
3. Pierwiastek chaosu – czyli obsługa różnego rodzaju zdarzeń w czasie pracy A2M (współpraca agenta z zewnętrznymi systemami) i umiejętność obsłużenia wyjątków
   1. opóźnienia,
   2. niepoprawne odpowiedzi zewnętrznych narzędzi,
4. brak odpowiedzi API.

Oczywiście testów będzie dużo więcej i silnie będą zależały od kontekstu użycia agentów.

Defekty specyficzne dla AX

Poniżej kilka defektów, jakich będziemy spodziewać się przy pracy nad AX. 

• over-agency – agent robi za dużo bez zgody
• under-agency – agent ciągle pyta i frustruje
• false confidence – agent deklaruje, że wykonał zadanie choć niczego nie udało mu się osiągnąć
• silent failure – agent „nic nie zrobił” i nie powiedział dlaczego
• goal drift – agent zmienia cel w trakcie

Każdy z nich z osobna można zakwalifikować jako klasa defektów AX. Warto zauważyć, że większość z nich jest specyficzna tylko dla pracy z agentami. Mamy więc nowy typ oprogramowania, który może popełniać błędy. W tym kontekście warto zrobić małą dygresję i zwrócić uwagę, że w ISTQB® błędy mogą popełniać jedynie ludzie, ale jak widać na przykładzie agenci AI też mogą popełniać błędy i ciężko mówić tutaj o defektach oprogramowania.

Błędy czy defekty agentów podpowiadają nam też potencjalne miary jakości. Będzie to oczywiście proste kryterium pass/fail dla testu, ale możemy sobie wyobrazić cały zbiór ciekawych metryk:

• poziom zaufania do agenta przez użytkownika (wartości procentowe - ankiety po sesji) – czyli testy zbliżone do badania UX,
• wskaźnik wtrąceń - jak często użytkownik musi poprawiać agenta,
• recovery success rate – z ilu „opresji” agent potrafi samodzielnie wybrnąć,
• współczynnik wyjaśnialności – w jakim stopniu działania agenta są zrozumiałe dla użytkownika,
• czas do zbudowania zaufania - jak szybko user zaufa agentowi
• Itd.

Oczywiście lista jest bardzo długa i może uwzględniać znacznie więcej różnego rodzaju metryk przypisanych do różnych cech oprogramowania. Dobór metryk silnie zależeć będzie od kontekstu projektu i produktu. 

Czy warto zainteresować się AX?

Wraz z rosnącą popularnością systemów agentowych pojawia się pytanie, czy Agentic Experience to jedynie chwilowa moda, czy może nowy obszar kompetencji. Odpowiedź nie jest zero-jedynkowa, ale wszystko wskazuje na to, że właśnie teraz AX zaczyna odgrywać rolę podobną do t.j. jaką kilkanaście lat temu odegrał UX - z tą różnicą, że stawka jest znacznie wyższa.

Zmienia się bowiem sam charakter interakcji z systemami. Użytkownicy coraz rzadziej będą obsługiwać aplikacje, a coraz częściej będą delegować cele agentom, którzy samodzielnie planują działania i wykonują je w tle. W takim modelu doświadczenie nie wynika już głównie z ergonomii interfejsu, lecz z zachowania agenta: tego, czy potrafi zrozumieć intencję, kiedy podejmuje inicjatywę, a kiedy prosi o potwierdzenie, oraz jak radzi sobie z błędami. 
 
Co istotne, AX jest dziś wyraźną luką kompetencyjną. Rynek skupia się na modelach, frameworkach i narzędziach, natomiast znacznie rzadziej pojawia się refleksja nad tym, jak agent powinien się zachowywać z perspektywy użytkownika i jak to zachowanie testować. W efekcie wiele zespołów mierzy się z problemami, które intuicyjnie rozpoznają, ale nie potrafią nazwać: brakiem zaufania do agenta, nieprzewidywalnością jego decyzji czy lękiem przed zwiększeniem autonomii systemu. Są to wprost problemy Agentic Experience, nawet jeśli jeszcze niewiele osób używa tego terminu.

Nie oznacza to jednak, że AX jest ścieżką dla każdego. To obszar, który nie oferuje dziś prostych certyfikatów ani jasno nazwanych ról rynkowych. Wymaga pracy na nieostrych definicjach, łączenia perspektywy technicznej z rozumieniem użytkownika oraz gotowości do kwestionowania utartych schematów testowania i projektowania. Dla osób szukających szybkiego, narzędziowego skilla może to być rozczarowujące.

Z drugiej strony AX wyjątkowo dobrze pasuje do osób, które mają doświadczenie w testach eksploracyjnych, jakości produktu, UX lub pracy z systemami złożonymi. Dla nich jest to raczej naturalna ewolucja niż radykalna zmiana kierunku. Zamiast porzucać dotychczasowe kompetencje, mogą je rozszerzyć o nowy wymiar: ocenę zachowania autonomicznych systemów w czasie i w relacji z człowiekiem.

Najrozsądniejszym sposobem zainteresowania się AX nie jest dziś gwałtowny zwrot ścieżki zawodowej, lecz stopniowe budowanie wrażliwości na ten obszar. To oznacza zaczęcie od nazywania problemów agentowych w obecnych projektach, testowanie agentów jako partnerów w realizacji celu, a nie tylko źródeł odpowiedzi, oraz dokumentowanie momentów, w których użytkownik traci zaufanie lub kontrolę. Z czasem to właśnie język i zdolność opisu tych zjawisk stają się największą wartością.

Na tym etapie rozwoju technologii AX jest jednym z niewielu obszarów, w których wciąż można współtworzyć definicje i dobre praktyki, zamiast jedynie je konsumować. I właśnie dlatego dziś jest dobry moment, by się nim zainteresować.

Podsumowanie 

Tester AX będzie testował zachowanie agenta, a nie tylko weryfikował wartości wyjściowe. Będzie to aktywne uczestniczenie w całym procesie E2E. W ramach tych testów, które w większości będą eksploracją tester przyjmie różne role od użytkownika – wcieli się w usera by uruchomić agenta; do partnera agenta, gdzie będzie nie tylko weryfikował jego skuteczność, ale pomagał mu jednocześnie być lepszym w realizacji celów. 

Możemy prześledzić scenariusz pracy testera z agentem, by lepiej zrozumieć specyfikę pracy: 

1. Krok 1. Tester widzi każdy krok, który wykonuje AI w panelu bocznym. Może ocenić, czy działania realizowane są optymalnie.
2. Krok 2. Sprawdza punkty decyzyjne (np. finalizacja płatności lub wejście na stronę banku) i określa, czy system prosi o potwierdzenie.
3. Krok 3. Tester weryfikuje scenariusze brzegowe oraz obsługę wyjątków w działaniu systemu. 
4. Krok 4. Tester przygotowuje zgłoszenia defektów, raport i zbiór rekomendacji dla usprawnień agenta. 

Wynika z tego, że do głównych wymagań względem osoby na stanowisku testera AX będą należały: praca z LLM-ami, znajomość system designu i psychologii użytkownika. To rola bliżej quality engineering i product thinking niż klasycznego kontrolowania jakości. Na ten moment ciężko również wskazać, gdzie i w jakiej formie pojawi się potrzeba automatyzacji. Silną rolę będzie tu na pewno odgrywać eksploracja.

Czy to rola dla Ciebie?