Agent to nie chatbot

Chatbot odpowiada na pytania. Jeśli odpowie źle, ktoś przeczyta złą odpowiedź i wzruszy ramionami. Agent robi coś więcej: wystawia fakturę, zmienia status zamówienia, wysyła maila do klienta, rezerwuje termin. Jeśli zrobi źle, faktura jest już u klienta.

Ta różnica zmienia wszystko, co trzeba przemyśleć przed wdrożeniem — a większość rozmów o agentach wciąż toczy się tak, jakby chodziło o lepszego chatbota.

Agent to nowy pracownik, nie nowa funkcja

Najprostszy test: czy dałbyś nowej osobie w pierwszym tygodniu pracy hasło do bankowości i prawo do wysyłania maili do wszystkich klientów bez sprawdzenia? Nie. Dostałaby wąski zakres, ograniczone uprawnienia i kogoś, kto patrzy jej na ręce, dopóki nie zaufasz jej wynikom.

Agent zasługuje na dokładnie to samo. Nie dlatego, że jest głupi — tylko dlatego, że jest nowy, a Ty nie wiesz jeszcze, gdzie się myli.

Cztery rzeczy, które agent musi mieć

Zakres. Jedno zadanie opisane tak, żeby dało się powiedzieć, co jest w nim, a co nie. „Obsługa reklamacji” to za dużo. „Klasyfikacja nowych reklamacji i przygotowanie odpowiedzi do akceptacji” — w sam raz na początek.

Uprawnienia. Agent dostaje dostęp tylko do tych systemów i tylko do tych operacji, których zadanie wymaga. Czytanie jest tanie, zapisywanie jest drogie, wysyłanie na zewnątrz jest najdroższe. Każde z tych uprawnień nadawaj osobno i świadomie.

Punkt akceptacji. Tam, gdzie błąd kosztuje — pieniądze, klient, zobowiązanie prawne — człowiek zatwierdza, zanim akcja wyjdzie z firmy. Z czasem, gdy wyniki są dobre, punkt akceptacji przesuwa się z „każda akcja” na „wyjątki i losowa próbka”.

Dziennik. Każda akcja zapisana razem z tym, co agent widział i dlaczego zdecydował tak, a nie inaczej. Bez dziennika nie da się poprawić błędu, wytłumaczyć decyzji klientowi ani odpowiedzieć na pytanie audytora.

Dlaczego to argument za własnym stackiem

Agent, który działa w Twoich systemach, musi mieć do nich dostęp. Jeśli te systemy to jedenaście produktów SaaS, agent dostaje jedenaście kluczy API z uprawnieniami, które definiuje dostawca, a nie Ty. Część z nich nie pozwala nadać „tylko odczyt tej jednej tabeli”. Część nie loguje, kto co zmienił przez API.

Gdy proces i dane są Twoje, granice agenta rysujesz Ty — na poziomie operacji, a nie na poziomie „ma dostęp albo nie ma”. To nie jest kwestia ideologii. To kwestia tego, czy w ogóle da się bezpiecznie dać agentowi coś do zrobienia.

Jak zacząć, żeby nie żałować

1. Wybierz proces, w którym ludzie dziś głównie przepisują i sortują.
2. Pierwsza wersja agenta niczego nie wysyła — przygotowuje, a człowiek klika.
3. Mierz, ile przygotowanych akcji człowiek zatwierdza bez poprawek.
4. Kiedy ten odsetek jest wysoki i stabilny, oddaj agentowi proste przypadki w całości, a trudne nadal kieruj do człowieka.
5. Przeglądaj dziennik co tydzień. Błędy agenta mówią Ci, gdzie Twój proces był niejasny.

Ostatni punkt to ukryta wartość: wdrożenie agenta zmusza firmę do opisania, jak naprawdę działa. Wiele zespołów odkrywa, że połowa „wiedzy plemiennej” nigdy nie była nigdzie zapisana. Barbarzyńcy też mieli reguły — tylko wyryte w kamieniu, a nie w czyimś regulaminie.