Human-in-the-loop w przepływie agentowym to nie awaryjny wyjątek, tylko zaprojektowany z góry moment, w którym decyzja wraca do człowieka — z ustalonym progiem, konkretną osobą i pełnym kontekstem sprawy, zanim agent w ogóle zacznie działać.
Trzy tryby udziału człowieka
W praktyce projektowania przepływów powtarzają się trzy wzorce włączenia człowieka, różniące się momentem, w którym to następuje:
- Zatwierdzenie przed wykonaniem (approve-before) — agent przygotowuje decyzję, ale nie wykonuje jej, dopóki człowiek nie kliknie „zatwierdź". Stosowane tam, gdzie błąd jest kosztowny lub trudny do cofnięcia, np. wysyłka zwrotu powyżej pewnej kwoty.
- Nadzór po fakcie (monitor-after) — agent działa samodzielnie, a człowiek przegląda próbkę decyzji okresowo, nie w czasie rzeczywistym. Pasuje do decyzji odwracalnych i tanich w skutkach, np. standardowe odpowiedzi na pytania o status zamówienia.
- Eskalacja przy wyjątku (escalate-on-exception) — agent działa samodzielnie w typowych przypadkach i przekazuje sprawę człowiekowi tylko wtedy, gdy trafi na sygnał granicy. To tryb dominujący w większości przepływów agentowych — dokładnie ten, który opisuje diagram na stronie głównej Agent Flow.
Jak wybrać próg, przy którym człowiek zatwierdza
Wybór trybu i progu to w praktyce kompromis między dwoma kosztami: kosztem błędnej decyzji podjętej samodzielnie przez agenta i kosztem czasu człowieka, który musi ją zatwierdzać. Im droższa i trudniejsza do cofnięcia decyzja, tym bliżej trybu „zatwierdzenie przed wykonaniem". Im tańsza i bardziej odwracalna, tym bardziej uzasadniony „nadzór po fakcie" albo czysta eskalacja przy wyjątku. Dobrym punktem wyjścia jest policzenie, ile realnie kosztowałaby najgorsza pomyłka w danej kategorii decyzji — i porównanie tego z kosztem czasu osoby zatwierdzającej każdą sprawę z osobna.
W praktyce próg rzadko jest jedną liczbą — często to kombinacja kwoty i kontekstu, np. „zwrot do 300 zł zatwierdzany automatycznie, powyżej — zatwierdzenie przed wykonaniem, chyba że klient ma status VIP, wtedy każda kwota trafia do człowieka". Im więcej takich warunków, tym ważniejsze, żeby były spisane w jednym miejscu, a nie rozproszone w głowach kilku osób.
Co powinien dostać człowiek w momencie przekazania
Sam alert „wymagana decyzja człowieka" bez kontekstu przenosi na człowieka dokładnie tę pracę, którą agent miał wykonać — czytanie sprawy od zera. Skuteczny punkt przekazania zawiera: pełną historię sprawy, jednozdaniowe uzasadnienie, dlaczego agent nie mógł zdecydować sam, oraz — jeśli agent ma jakąś wstępną propozycję — tę propozycję razem z poziomem pewności. To skraca czas zatwierdzenia z minut do sekund.
Warto też zapisać, gdzie ten pakiet informacji fizycznie trafia — do tej samej kolejki co inne zgłoszenia, czy do osobnego widoku dla zatwierdzeń. Mieszanie zatwierdzeń z bieżącą obsługą zgłoszeń zwykle kończy się tym, że pilne decyzje giną w tej samej kolejce co rutynowe sprawy.
Human-in-the-loop w praktyce frameworków
Mechanizm zatrzymania procesu i przekazania go do zatwierdzenia jest dziś elementem architektury głównych frameworków agentowych, nie dodatkiem. LangGraph opisuje go jako punkt przerwania (interrupt), w którym stan przepływu jest zapisywany, a wykonanie wznawiane dopiero po decyzji człowieka. Kierunek ten pokrywa się z szerszymi wytycznymi dotyczącymi projektowania interakcji człowiek-AI — zbiór Guidelines for Human-AI Interaction (Amershi i in., konferencja CHI 2019, Microsoft Research) rekomenduje między innymi, by system jasno sygnalizował niepewność i ułatwiał szybką, tanią korektę swojej decyzji. To właśnie robi dobrze zaprojektowany punkt przekazania w przepływie agentowym.
Ryzyka nadmiernego lub zbyt rzadkiego zatwierdzania
Zbyt szeroki próg zatwierdzania prowadzi do zmęczenia decyzyjnego — człowiek klika „zatwierdź" bez czytania, bo widzi dziesiątki podobnych spraw dziennie, i cały mechanizm przestaje pełnić swoją funkcję. Zbyt wąski próg tworzy z kolei wąskie gardło: agent czeka na zatwierdzenia, które i tak są w praktyce zawsze pozytywne, a proces wolniej reaguje niż przed automatyzacją. Oba skrajne przypadki warto sprawdzać po fakcie — jeśli odsetek zatwierdzeń bez zmian przekracza, powiedzmy, 95%, próg prawdopodobnie jest zbyt ostrożny.
Dobrym nawykiem jest przegląd progu co kilka miesięcy, nie tylko raz przy uruchomieniu — zachowanie klientów i typy zgłoszeń zmieniają się w czasie, a próg ustalony trafnie na starcie po roku bywa albo zbyt szeroki, albo zbyt wąski względem nowej rzeczywistości procesu.
Powiązanie z przykładem triage'u zgłoszeń
Ten sam wybór trybu widać w praktycznym przykładzie triage'u zgłoszeń: standardowe pytania o status zamówienia obsługuje tryb „eskalacja przy wyjątku", a zwrot powyżej ustalonej kwoty wymaga zatwierdzenia przed wykonaniem. Krok po kroku, jak zaprojektować taki przepływ, opisaliśmy w Jak zaprojektować przepływ agenta AI dla obsługi zgłoszeń, a samo pojęcie przepływu agentowego — w Czym jest przepływ agentowy (agentic workflow)?.
Kto powinien zatwierdzać — jedna osoba czy zespół
Przy trybie „zatwierdzenie przed wykonaniem" warto z góry ustalić, czy decyzję podejmuje jedna, konkretna osoba (np. kierownik działu), czy dowolna osoba z określonej roli w danej zmianie. Pojedynczy właściciel decyzji przyspiesza proces, ale tworzy wąskie gardło, gdy jest nieobecny — dlatego w praktyce lepiej sprawdza się rola, a nie nazwisko: „osoba dyżurująca w dziale reklamacji", a nie „Kasia z księgowości". To pozornie drobne rozstrzygnięcie często decyduje o tym, czy przepływ przetrwa pierwszy urlop kluczowej osoby.
Czy human-in-the-loop spowalnia proces w porównaniu z pełną automatyzacją? Dla pojedynczej sprawy — tak, minuty zamiast sekund. Dla całego procesu — zwykle nie, bo dotyczy tylko wyjątków, a nie każdej sprawy. Jeśli okazuje się, że dotyczy większości spraw, to sygnał, że granice decyzji agenta są ustawione zbyt wąsko, a nie że sam mechanizm zatwierdzania jest zbędny.