Dlaczego nie ufam agentom AI, chociaż buduję z nich systemy

Jeśli coś jest niedeterministyczne, to znaczy, że jest złe.

Wiem, jak to brzmi w połowie 2026 roku, kiedy cała branża idzie w autonomię, a każda konferencja opowiada o agentach, które same decydują, co zrobić w następnym kroku.

Ja w systemach produkcyjnych idę dokładnie w odwrotną stronę. Agentów używam jak najmniej i jak najostrożniej. I to jest ta część mojej pracy, za którą klienci naprawdę płacą.

Z tego artykułu dowiesz się:

• co firma naprawdę kupuje, kiedy zamawia automatyzację (a nie kupuje autonomii),
• co dokładnie znaczy "deterministyczny" na przykładzie stu produktów w sklepie,
• jak wygląda realna awaria spowodowana przez agenta,
• jaką regułę stosuję przy decyzji "agent czy zwykła logika" — i kiedy agent naprawdę wygrywa,
• dlaczego nie każda awaria zasługuje na tę samą obsługę błędów,
• co dokładnie wpinam w workflow, zanim oddam go klientowi.

Firma nie kupuje autonomii

Kupuje powtarzalność. Audytowalność. Brak zaskoczeń.

Ten sam input ma dać ten sam przebieg — dzisiaj, jutro i za pół roku, gdy nikt już nie pamięta, kto to budował. To jest produkt. Nie "inteligencja", tylko przewidywalność.

Liczby są tu bezlitosne i nie pochodzą ode mnie:

• 88% pilotaży agentowych nigdy nie trafia na produkcję (Anaconda + Forrester).
• 95% pilotaży generatywnego AI nie daje mierzalnego zwrotu w wyniku finansowym (MIT Project NANDA — 150 wywiadów, 350 ankiet, 300 wdrożeń).
• Mediana time-to-value wdrożeń agentowych: 5,1 miesiąca. Dla finansów i operacji — 8,9 miesiąca.
• Główne blokery: braki w ewaluacji (64% liderów), tarcie governance (57%), niezawodność modelu (51%).

To nie jest hejt na agentów. To wyceniony w kwartałach koszt niedeterminizmu.

Firma, która wdraża automatyzację obsługi zamówień, nie ma ośmiu miesięcy na eksperyment. Ma pytanie: "czy w poniedziałek zamówienia same trafią do producenta?". Odpowiedź "zazwyczaj tak" jest odpowiedzią negatywną.

Co znaczy "deterministyczny" — na konkrecie

Słowo brzmi akademicko, więc rozłóżmy je na sto produktów w sklepie.

Deterministyczne rozwiązanie wygląda tak: otwórz produkt, zmień cenę, zapisz produkt. Potem następny. Zawsze ta sama metoda, zawsze ta sama kolejność, sto razy pod rząd. Nudne jak flaki z olejem i dokładnie o to chodzi.

Niedeterministyczne wygląda tak: model dostaje zadanie "zaktualizuj ceny" i zaczyna tworzyć własny sposób. Otworzy sobie kilka produktów w takiej kolejności, jaka mu wyjdzie. Zapisze pięć. Potem zrobi coś innego, bo tak mu się ułoży kontekst.

Oba podejścia mogą skończyć się poprawnym wynikiem. Tylko przy pierwszym wiesz, dlaczego wynik jest poprawny — i wiesz, co sprawdzić, kiedy nie będzie.

I od razu zastrzeżenie, żeby nie zrobić z tego dogmatu: determinizm nie zawsze jest potrzebny. Jeśli piszesz teksty, jest wręcz niepotrzebny — powtarzalność byłaby tam wadą, nie zaletą. Mówię o konkretnym zastosowaniu: o systemach pracujących na danych firmy, gdzie ktoś ma o ósmej rano zobaczyć poprawny stan magazynu.

Skąd u mnie ta ostrożność

Zanim był n8n, był ZennoPoster. Automatyzacja bez cienia AI — same reguły, same ifki, wszystko rozpisane ręcznie.

n8n wszedł mi do pracy mniej więcej w czasach ChatGPT 3.5. Wtedy agent nadawał się wyłącznie do drobnicy: wygeneruj tytuł, streść tekst, przypisz kategorię, przeanalizuj stronę i zrób streszczenie. Cała logika procesu i tak musiała być deterministyczna, bo model nie udźwignąłby niczego większego.

To była zresztą wtedy ogromna przewaga. Czaty były kiepskie, ale pojedyncze, wąskie rzeczy robiły całkiem nieźle — a podpięcie ich do workflow było nieporównywalnie łatwiejsze niż pisanie tego samego w kodzie.

I tu jest rzecz, którą warto zauważyć: okazało się, że tak jest po prostu lepiej. Nie tylko taniej i nie tylko dlatego, że modele były słabe.

Modele urosły ogromnie. Zasada się nie zmieniła.

Realna awaria: jedna literówka

Najczęstsze pytanie, jakie dostaję, brzmi "no dobra, ale co konkretnie może pójść nie tak". Więc konkret.

Agent ma pobrać dane ze strony, przetworzyć je do formatu JSON i odesłać dalej. W JSON-ie pojawia się literówka — jeden znak nie na swoim miejscu. Struktura się rozjeżdża. Kolejny node dostaje coś, czego się nie spodziewa. Workflow się wysypuje.

To nie jest historia o halucynacji ani o tym, że model "nie zrozumiał zadania". Model zrozumiał doskonale. Po prostu raz na jakiś czas postawi przecinek tam, gdzie nie trzeba.

Wniosek jest niewygodny: w systemie, który zbudowałem, najbardziej zawodnym elementem nie jest API klienta ani serwer. Jest ten jeden node z agentem.

Zabezpieczenie jest banalne i prawie nikt go nie robi: pętla naprawy JSON-a. Nie udało się sparsować — wracamy do modelu z informacją o błędzie i prosimy o poprawną strukturę. Dopiero potem lecimy dalej.

I tu ciekawostka, która najlepiej pokazuje skalę problemu: n8n ma tę funkcję wbudowaną. Naprawę niepoprawnie zwróconego JSON-a z użyciem agenta dostajesz w standardzie, nie trzeba jej budować od zera. Wystarczy ją włączyć.

Tylko że w demo ten mechanizm nigdy się nie odpali — bo demo puszcza się trzy razy i za każdym razem wychodzi. Dlatego nie ma go w kursach.

Reguła decyzyjna

Zawsze staram się używać jak najmniej agentów i w jak najbardziej konkretnych zadaniach, ściśle określonych.

W praktyce sprowadza się to do trzech warunków wejścia. Agent wchodzi do systemu tylko wtedy, gdy spełnione są wszystkie trzy:

1. Logiki naprawdę nie da się napisać ifami. Nie "nie chce mi się" i nie "byłoby szybciej" — tylko realnie nie da się. Klasyfikacja treści maila po intencji: nie da się. Sprawdzenie, czy kwota przekracza próg: da się, i to bez AI.
2. Output ma weryfikowalny format. Zawsze JSON o znanej strukturze. Nie akapit swobodnego tekstu, który potem ktoś próbuje parsować regexem.
3. Istnieje ścieżka naprawcza. Wiadomo, co się dzieje, gdy format się nie zgadza. Pętla naprawy, limit prób, a na końcu powiadomienie do człowieka.

Nie spełniasz któregoś? To nie jest miejsce na agenta.

Kiedy agent naprawdę wygrywa

Skoro tyle miejsca poświęcam ograniczeniom, należy się uczciwy przykład z drugiej strony. Bo są zadania, w których agent nie jest wygodą — jest jedynym sensownym rozwiązaniem.

Załóżmy, że szukasz mieszkania. Chcesz, żeby system wszedł na stronę z ogłoszeniami, przejrzał ją i wybrał te, które Cię interesują.

Klasycznie musiałbyś napisać kilkanaście ifów i kilkanaście parametrów parsujących całą stronę. Najpierw pobrać wszystkie mieszkania do postaci tabelki, znormalizować pola, potem je przefiltrować. A gdy serwis zmieni układ HTML, zaczynasz od nowa.

Z agentem ten krok wygląda inaczej: mówisz mu "znajdź mieszkanie poniżej 50 metrów w cenie do 250–300 tysięcy" i sprawa jest załatwiona.

To jest dokładnie ten przypadek, w którym reguła z poprzedniej sekcji działa na korzyść agenta: logiki faktycznie nie da się rozsądnie napisać ifami, output da się wymusić w JSON-ie, a gdy struktura się nie zgadza — jest pętla naprawcza.

Różnica między tym a "wsadźmy agenta, bo to modne" jest taka, że tutaj potrafię powiedzieć, dlaczego go tam wsadziłem.

"Czyli świadomie wpuszczasz zło do systemu"

Tak. I dlatego otaczam je kordonem.

Skoro twierdzę, że niedeterminizm jest zły, a jednocześnie sam wstawiam agenta tam, gdzie logika jest za trudna, to trzeba to powiedzieć wprost: robię to świadomie i z pełną kalkulacją.

Agent jest elementem systemu, nigdy jego głównym bohaterem. Niedeterminizm jest dopuszczalny wyłącznie tam, gdzie jest odizolowany i sprawdzalny — czyli tam, gdzie wiem, że może się wysypać, i mam na to przygotowaną reakcję.

I jeszcze jedno, bo to nie jest dogmat. Przy projekcie bazy pytań do quizów wiedzy niedeterminizm okazał się zaletą. Poległem na tabelach danych w n8n, a Claude Code zrobił to lepiej właśnie dlatego, że za każdym razem generował coś innego — ładniej grupował wiedzę i lepiej wymyślał pytania. Zadanie było twórcze, nie powtarzalne.

To nie jest religia. To dobór narzędzia do zadania.

Nie każda awaria jest równa

Zanim przejdę do listy mechanizmów, jedna rzecz, której nie mówi się w kursach — bo psuje prostą narrację "zawsze rób obsługę błędów".

Nie każda awaria kosztuje tyle samo, i to powinno decydować, ile pracy w nią wkładasz.

Odczytujesz maile i je segregujesz. Skrypt się wysypie, jeden mail zostanie nieposegregowany. I co? Wchodzisz, poprawiasz ręcznie, koniec tematu. Ten problem da się przeżyć i naprawdę nie warto budować wokół niego fortecy.

A teraz drugi przypadek. Wysyłasz trzy maile do klientów i workflow wysypuje się po pierwszym. Masz przerwaną ścieżkę i — co gorsza — raczej nie sprawdzisz, gdzie się to stało. Dwóch klientów nie dostało odpowiedzi, a Ty się o tym nie dowiesz.

Różnica nie polega na tym, że drugi błąd jest "większy". Polega na tym, że pierwszy jest widoczny i odwracalny, a drugi cichy i nieodwracalny.

Reguła jest prosta: im mniej widoczna awaria, tym więcej obsługi błędów jej się należy. Wszystko, co dotyka klienta końcowego albo pieniędzy, jest domyślnie w kategorii drugiej.

Co wpinam, zanim oddam workflow

Tu jest liczba, która robi największe wrażenie: z ponad 2000 przeanalizowanych realnych automatyzacji n8n 97% nie ma podstawowej obsługi błędów.

Uczciwe zastrzeżenie: to statystyka z workflowów dostępnych publicznie w internecie, nie z systemów produkcyjnych. Ale to właśnie z nich ludzie się uczą — i uczą się robić rzeczy bez obsługi błędów. Nawet w kursach ten temat jest konsekwentnie pomijany, choć według mnie jest jednym z kluczowych, jeśli ktoś chce z tego żyć.

Moja lista, z nazwy, żeby nie było wątpliwości:

• Error workflow — osobny workflow uruchamiany, gdy główny się wywali. Bez tego awaria jest cicha.
• Retry On Fail — ponawianie kroku, który padł, z ustawianą liczbą powtórzeń i odstępem między nimi. Połowa awarii to chwilowy timeout API i nic więcej.
• Always Output Data — node zwraca coś nawet przy pustym wyniku, dzięki czemu następny krok nie dostaje pustki i nie kończy przebiegu po cichu.
• Execute Once — kiedy krok ma się wykonać raz, a nie tyle razy, ile przyszło rekordów.
• Pole On Error — decyzja podejmowana per node: przerwać przebieg czy iść dalej inną gałęzią.
• Powiadomienia o błędach — mail albo wiadomość, natychmiast. Awaria, o której nie wiesz, jest gorsza niż awaria.
• Notatki w workflow — nie są obsługą błędów, ale za pół roku to one decydują, czy ktoś w ogóle zrozumie, co ten węzeł miał robić.

Wszystkie te mechanizmy są wbudowane w n8n. Nie trzeba niczego instalować. Ludzie ich po prostu nie włączają.

Warto też wiedzieć, na czym to realnie pada, bo lista przyczyn jest dłuższa i głupsza, niż się wydaje. Skończyły się środki na kluczu API i agent przestał odpowiadać. Przekroczony limit wysyłki na SMTP. Dostawca modelu z niestabilnym API. Zewnętrzne API, które wywala się co kwadrans. Awaria rzadko wygląda jak awaria — częściej wygląda jak cisza.

Cała ta konfiguracja to razem godzina, może dwie pracy między testami a wejściem na produkcję. Na workflow, na którym dopiero testuję, nie robię tego w ogóle — to byłaby strata czasu. Robi się to raz, świadomie, w momencie przejścia na produkcję.

Bez tego wysyłasz klientowi połowę maili i nie wiesz o tym. Dowiadujesz się miesiąc później, gdy ktoś zapyta, dlaczego nie dostał odpowiedzi na zapytanie ofertowe.

Podsumowanie

• Agent to nie system. To najbardziej podatny na awarię element systemu, który zbudujesz wokół niego. Kto tego nie odwróci, dołącza do 88%.
• Determinizm to nie ideologia, tylko zakres. Przy danych firmy jest obowiązkowy, przy pisaniu tekstów zbędny. Problem zaczyna się wtedy, gdy ktoś nie widzi różnicy.
• Trzy warunki wejścia dla agenta: logiki nie da się napisać regułą, output ma weryfikowalny format, istnieje ścieżka naprawcza. Wszystkie trzy, nie dwa.
• Wymuszaj JSON i sprawdzaj go. Literówka w strukturze wywali workflow równie skutecznie, jak padnięty serwer — a zdarza się częściej. Naprawę masz w n8n w standardzie.
• Skaluj obsługę błędów do widoczności awarii. Nieposegregowany mail poprawisz ręcznie. O niewysłanym mailu do klienta nie dowiesz się wcale.
• Godzina na obsługę błędów przed produkcją. Error workflow, Retry On Fail, Always Output Data, Execute Once, On Error, powiadomienia. To jest cała różnica między demem a wdrożeniem.

Firma nie płaci za to, że system jest inteligentny. Płaci za to, że w poniedziałek rano nie musi sprawdzać, czy zadziałał.

P.S. Świadomie nie podaję tu własnego wskaźnika skuteczności, bo do tej pory operowałem szacunkiem ("praktycznie sto procent"), a nie pomiarem. Jest w tym jeszcze jeden haczyk, o którym warto wiedzieć: darmowa wersja n8n pokazuje w zakładce Executions tylko jeden dzień wstecz, więc rzetelna statystyka wymaga zbierania jej po drodze, a nie odtwarzania z pamięci systemu. Zrobię to i wrócę z konkretem — jedna prawdziwa liczba jest warta więcej niż cały akapit deklaracji.