Agent AI nie jest mądrzejszym chatbotem — to inne urządzenie

Chatbot odpowiada. Agent wykonuje.

Klasyczny chatbot — nieważne czy to widget na stronie sklepu, czy bot obsługi klienta w banku — działa według jednego schematu: dostajesz zapytanie, zwracasz odpowiedź. Koniec. Następna wymiana to zupełnie nowa rozmowa, model nie pamięta poprzedniej (chyba że ktoś specjalnie zadbał o historię), nie sprawdza niczego na zewnątrz i nie podejmuje żadnej decyzji poza sformułowaniem kolejnego zdania. To nie jest wada projektu — to świadomy wybór. Chatbot ma być szybki, przewidywalny i tani w utrzymaniu.

Agent AI działa inaczej, bo ma cel do osiągnięcia, nie tylko zapytanie do obsłużenia. Dostajesz zadanie: 'Znajdź mi trzech dostawców opakowań z województwa śląskiego, sprawdź czy mają certyfikat FSC i wyślij do każdego wstępne zapytanie ofertowe.' Chatbot powie ci jak to zrobić. Agent zrobi to — wywoła wyszukiwarkę, przejdzie przez wyniki, wejdzie na strony, skonstruuje treść maila, wyśle go przez podłączone konto. Albo stwierdzi w połowie, że dane z jednej strony są nieaktualne i sam spróbuje alternatywnego źródła.

Różnica jest więc w architekturze, nie w inteligencji. Agent ma dostęp do narzędzi (narzędzia to tu słowo techniczne: może to być API, przeglądarka, baza danych, skrzynka mailowa, arkusz kalkulacyjny). Ma pętlę — planuje krok, wykonuje go, sprawdza wynik, planuje następny. Ma pamięć kontekstu przez całe zadanie. I — to jest ten fragment, który ludzi najbardziej zaskakuje — może sam zdecydować, że pierwotny plan nie działa i obrać inną ścieżkę.

Pętla, która wszystko zmienia

Żeby nie zostać przy abstrakcji: w środku agenta działa coś, co roboczo nazywa się pętlą ReAct albo jej wariantami (Reason + Act). Model językowy najpierw myśli na głos — dosłownie generuje wewnętrzny monolog w stylu 'żeby znaleźć dostawców, muszę najpierw zrobić wyszukiwanie, potem przefiltrować wyniki' — potem wywołuje odpowiednie narzędzie, dostaje odpowiedź z zewnętrznego systemu i znowu myśli, co z tym zrobić. Cykl powtarza się, aż cel jest osiągnięty albo model stwierdzi, że nie jest w stanie go osiągnąć.

To brzmi elegancko na slajdzie, ale w praktyce bywa kłopotliwe. Model może się zapętlić. Może zinterpretować wynik narzędzia błędnie i pójść w złym kierunku przez kilka kroków. Może też — i to mi się zdarzyło obserwować u kilku klientów — wykonać coś, co brzmiało jak pół zadania, a potem spokojnie oznajmić, że skończył. Stąd tak ważne jest, żeby agent miał jasno zdefiniowane kroki weryfikacji i żeby człowiek nie wychodził z założenia, że jak puszczono agenta to można spokojnie pić kawę przez godzinę.

Nawiasem mówiąc, to jest coś, czego nikt głośno nie mówi przy zachwalaniu agentów: im bardziej autonomiczny agent, tym bardziej potrzebujesz dobrze zaprojektowanego systemu nadzoru. Automatyzacja nie zwalnia cię z myślenia o procesie — ona przenosi to myślenie na wcześniejszy etap.

Tomek z Gliwic i trzy tygodnie na eksport danych

Konkretny przypadek: firma logistyczna z Gliwic, właściciel Tomasz P., 28 pracowników, marzec 2024. Postanowili wdrożyć agenta do obsługi zapytań ofertowych — miał czytać maile od klientów, wyciągać z nich dane o trasach i wagach, sprawdzać dostępność aut w ich wewnętrznym systemie i wstępnie wyceniać zlecenia. Idea dobra, oszczędność realna — właściciel liczył na to, że wyeliminuje dwa etaty w biurze.

Wdrożenie utknęło na eksporcie danych przez trzy tygodnie, bo ich system do zarządzania flotą miał API z 2019 roku, nieudokumentowane w połowie i zwracające daty w trzech różnych formatach jednocześnie. Potem okazało się, że połowa zespołu i tak przepisywała wyceny 'bo agent czasem się myli i lepiej sprawdzić'. Co do zasady mieli rację — agent mylił się przy niestandardowych zleceniach, gdzie klient pytał ogólnikowo. Ostatecznie wdrożenie zadziałało, ale nie dla dwóch etatów, tylko dla jednego i pół, i zajęło nie sześć tygodni jak planowano, tylko cztery miesiące.

Morał jest ten sam co przy każdym oprogramowaniu: pilot działa lepiej niż wyobrażony przez szefa scenariusz idealny. I nie, agent nie jest od razu w stanie zrozumieć twojego legacy systemu — on jest tak dobry, jak dobre jest połączenie z narzędziami, które mu dajesz.

Wróćmy na chwilę do chatbota, bo myślę, że za szybko go odpuściłem. Chatbot jest przereklamowany jako narzędzie do obsługi klienta w firmach, które mają skomplikowane przypadki brzegowe — i tyle razy byłem świadkiem chatbotów, które bardziej frustrowały klientów niż pomagały, że nie zamierzam udawać, że to dojrzała technologia do wszystkiego. Ale do prostych, powtarzalnych zapytań — godziny otwarcia, status zamówienia, najczęstsze pytania z FAQ — chatbot jest tańszy, prostszy do utrzymania i nie skręca w nieoczekiwanym kierunku. Agent do takich zadań to armata na muchy.

Kiedy agent ma sens, a kiedy to przepalanie budżetu

Agent zaczyna mieć sens wtedy, gdy zadanie wymaga przynajmniej kilku kroków z podejmowaniem decyzji po drodze, gdy te kroki korzystają z różnych źródeł danych albo systemów i gdy powtarza się to wystarczająco często, żeby uzasadnić koszt wdrożenia i utrzymania. Badanie rynku, przygotowywanie raportów z wielu systemów naraz, kwalifikacja leadów z połączeniem CRM i danych zewnętrznych, monitoring dokumentów prawnych — to są obszary, gdzie agent daje realną wartość.

Jeśli masz jedno proste powtarzalne zapytanie i chcesz tylko żeby ktoś (coś) na nie odpowiadało 24/7 — chatbot. Jeśli chcesz żeby coś wykonało za ciebie sekwencję czynności rozłożoną w czasie i opierającą się na danych z kilku miejsc — agent. Jeśli nie wiesz dokładnie czego chcesz — żadne z tych dwojga nie pomoże, bo najpierw trzeba zrozumieć proces, który chcesz zautomatyzować.

Jedno zastrzeżenie, które rzadko pojawia się w rozmowach o agentach: koszt błędu rośnie razem z autonomicznością. Chatbot, który źle odpowie, da złą informację. Agent, który źle wykonuje zadanie, może wysłać maila do złego klienta, zmienić rekord w bazie albo złożyć zamówienie, którego nie chciałeś. To nie jest argument przeciwko agentom — to argument za tym, żeby pierwsze wdrożenie było na małym zakresie zadań z jasno zdefiniowanymi granicami tego, co agent może zrobić samodzielnie, a co wymaga zatwierdzenia przez człowieka.

Agenci AI jako kategoria produktowa są teraz w tym dziwnym miejscu, gdzie narzędzia są naprawdę użyteczne, ale literatura wokół nich jest w większości napisana przez ludzi, którzy albo sprzedają konkretne rozwiązanie, albo nie wdrażali niczego poza demo na laptopie. Moje przeczucie — oparte na rozmowach z kilkunastoma właścicielami firm w ubiegłym roku — jest takie, że realne wdrożenia, które działają bez ciągłego pilnowania, dotyczą zazwyczaj jednego konkretnego, dobrze ograniczonego zadania, nie wielofunkcyjnego 'asystenta do wszystkiego'. Ten drugi wariant ładnie wygląda na prezentacji i regularnie wywala się w środę o 14:00, gdy ktoś wyśle zapytanie w formacie, którego twórcy nie przewidzieli.

Zacznij od kartki papieru i narysuj dokładnie jakie kroki wykonuje człowiek w tym zadaniu, z jakich danych korzysta i gdzie musi podjąć nietrywialną decyzję. Jeśli potrafisz to narysować — masz już połowę specyfikacji agenta.