Ostatnie rozmowy o automatyzacji sprowadza się do jednego pytania od klienta: skoro model językowy potrafi sam zdecydować, co zrobić dalej, to po co jeszcze rysować te wszystkie bloki w N8N?
Rozumiem, skąd to się bierze. Demo agenta wygląda spektakularnie – wpisujesz zdanie, on sam wybiera narzędzia, sam się poprawia, sam kończy robotę. Flow w N8N przy tym wygląda jak schemat instalacji elektrycznej. Tyle, że w pracy, którą wykonuję dla klientów, te dwie rzeczy nie konkurują ze sobą. One siedzą w jednym procesie, tylko na innych piętrach, po prostu uzupełniają się.
Dwa różne podejścia
Automatyzacja deterministyczna w N8N to odpowiednik zwykłego programu, tylko narysowanego. Przychodzi zdarzenie – webhook, nowy plik, uruchomienie z crona – i dalej idzie ustalona ścieżka. If/then, pętla, mapowanie pól, wywołanie API. Przy tym samym wejściu dostajesz ten sam wynik, dziś i za pół roku. N8N, Make, Zapier, ale też zwykły skrypt na cronie – to wszystko jest ta sama kategoria. Po prostu realizuje podobną logikę za każdym razem.
Automatyzacja agentowa działa inaczej. Dajesz modelowi cel, zestaw narzędzi i pozwalasz mu w pętli decydować, którego narzędzia użyć w następnym kroku, aż uzna, że skończył. Nie ma z góry narysowanej ścieżki – jest przestrzeń możliwych ścieżek i model, który po niej chodzi.
To nie jest różnica “gorsze i lepsze”. To różnica między “wiem dokładnie, co ma się stać” a “nie wiem, co przyjdzie na wejściu”. Z założenia pętla agenta AI działa inaczej, nie ma ustalonej ścieżki tylko wybiera jedną z wielu możliwych ścieżek, jest nieterministyczna. To jest ta podstawowa różnica.
Gdzie N8N po prostu wystarcza
Buduję taki flow, kiedy proces da się opisać zdaniem bez słowa “zależy”.
Nowe zgłoszenie z formularza ma trafić do CRM-u, odpalić mail potwierdzający i wpaść na kanał zespołu. Faktura ma się co miesiąc pobrać z panelu, wylądować w katalogu z odpowiednią nazwą i pojechać do księgowości. Baza ma się zrzucić o trzeciej w nocy, skopiować na drugą lokalizację i wysłać alert, jeśli plik jest podejrzanie mały. Nic z tego nie wymaga rozumienia. To jest przekładanie danych z jednego miejsca w drugie.
Trzy powody, dla których nie warto tu wsadzać modelu.
Koszt. Flow, który przełoży sto rekordów, kosztuje tyle, co utrzymanie instancji. Agent liczy tokeny przy każdym przebiegu i rachunek rośnie liniowo z ruchem. Przy stu przebiegach dziennie to jeszcze nie boli. Przy dziesięciu tysiącach – boli.
Przewidywalność. Jeżeli proces dotyka pieniędzy albo obowiązków wobec urzędu, nie chcesz, żeby cokolwiek “zdecydowało inaczej” w trzynastym przebiegu. Jeden nasz klient robi SaaS do gdzie silnik wyliczeń jest z premedytacją deterministyczny – normy, stawki, narzuty, współczynniki, VAT. Model nie ma tam czego szukać, bo wyliczenia mają się zgadzać co do grosza, a nie brzmieć wiarygodnie.
Debugowanie. Kiedy deterministyczny flow się wywali, otwierasz konkretny node, widzisz wejście, wyjście i błąd. Kiedy wywali się agent, dostajesz przebieg rozmowy i pytanie “dlaczego on w tym kroku wybrał akurat to”. Da się to prześledzić, ale to inna klasa problemu i inna klasa rachunku za czas.
Gdzie agent naprawdę daje przewagę
Przewaga zaczyna się dokładnie tam, gdzie kończy się struktura wejścia.
Wejście nieustrukturyzowane. Mail od klienta z załącznikiem i zdaniem “przesyłam za lipiec, ta druga faktura chyba jest z sierpnia”. Skan dokumentu, którego układ jest inny u każdego kontrahenta. Notatka z rozmowy. Nie da się tego rozparsować regexem, bo nie ma czego parsować – jest tekst, który trzeba zrozumieć.
Klasyfikacja z rozmytymi granicami. Do którego procesu należy ten dokument. Czy to reklamacja, czy pytanie przedsprzedażowe. Czy ten opis usterki pasuje do pozycji A czy B w cenniku. Można to napisać jako sto reguł if/then i po roku mieć sto pięćdziesiąt, z których nikt nie pamięta, po co jest czterdziesta trzecia.
Zmienna liczba kroków. Czasem odpowiedź jest w pierwszym dokumencie, czasem trzeba sprawdzić trzy inne i wrócić. Deterministyczny flow trzeba wtedy rozgałęzić na wszystkie warianty z góry. Agent po prostu robi kolejny krok.
Praca z językiem naturalnym na wyjściu. Streszczenie, przygotowanie odpowiedzi do akceptacji, wyciągnięcie z długiego wątku listy ustaleń.
W wewnętrznym systemie do prowadzenia procesów księgowych, granica biegnie dokładnie w tym miejscu. Terminy, statusy, uprawnienia, kolejność etapów zamknięcia miesiąca – to twarde reguły i tam model byłby ryzykiem, nie pomocą. Ale wstępne rozpoznanie tego, co przyszło w dokumencie od klienta biura, to już zupełnie inna historia.
Wzorzec, który działa: agent jako jeden krok w środku flow
I tu jest teza całego wpisu. Nie buduję “agenta, który obsługuje proces”. Buduję normalny flow i wsadzam do niego jeden krok, w którym pracuje model.
Wygląda to zawsze podobnie:
- Wyzwalacz i zebranie danych – deterministycznie. Webhook, poll skrzynki, nowy plik.
- Przygotowanie wejścia – deterministycznie. Wyciągnięcie tekstu, normalizacja, dorzucenie kontekstu z bazy.
- Krok decyzyjny – agent. Dostaje wąskie zadanie, ograniczony zestaw narzędzi i ma zwrócić ustrukturyzowaną odpowiedź: kategoria, pola, poziom pewności.
- Walidacja – deterministycznie. Czy odpowiedź ma właściwy kształt, czy wartości są ze słownika, czy pewność jest powyżej progu.
- Wykonanie – deterministycznie. Zapis, wysyłka, aktualizacja statusu. Jeśli walidacja nie przeszła albo pewność jest niska – do kolejki człowieka.
Trzy rzeczy, które to daje. Model odpowiada za jedną decyzję, a nie za cały proces, więc jak się pomyli, wiadomo gdzie. Cała integracja – autoryzacja, ponowienia, limity API, kolejność – zostaje w warstwie, którą umiesz debugować. I możesz ten jeden krok wymienić: dziś model, jutro reguła, pojutrze inny model, bez ruszania reszty.
Na konkretnym przykładzie: przychodzi mail z załącznikami od klienta. Flow odbiera wiadomość, wyciąga tekst z załączników i sprawdza, czy nadawca jest w bazie – to wszystko robi kod, bo tu nie ma czego rozumieć. Dopiero potem model dostaje jedno pytanie: co to za dokument, do którego okresu należy, czego dotyczy prośba w treści maila. Odpowiedź wraca jako kilka pól ze słownika, nie jako akapit. Kod sprawdza, czy typ dokumentu jest z listy, czy okres istnieje i czy nie jest zamknięty. Jeśli którykolwiek warunek nie przechodzi, sprawa ląduje w kolejce do człowieka z gotowym podsumowaniem, a nie znika. Jeśli przechodzi – dokument trafia w odpowiednie miejsce, a nadawca dostaje potwierdzenie z szablonu.
Zwróć uwagę, ile w tym opisie jest modelu. Jeden krok z pięciu. Cała reszta to zwykłe instalacje N8N i tak ma zostać – bo jak coś pęknie o drugiej w nocy, chcesz zobaczyć, który node zwrócił błąd, a nie czytać, co model sobie pomyślał.
Ryzyka, których nie można zapomnieć
Nie jest to rozwiązanie idealne bez kosztów.
Niedeterminizm. Ten sam dokument dwa razy może dać dwie różne odpowiedzi. Trzeba mieć zestaw przypadków testowych i przepuszczać je po każdej zmianie promptu albo modelu – inaczej “drobna poprawka” cicho psuje pięć procent przebiegów.
Koszt tokenów. Rośnie z ruchem i z długością kontekstu. Warto go liczyć od pierwszego dnia, per przebieg, a nie po fakturze na koniec miesiąca.
Halucynacje. Model potrafi zwrócić numer konta, którego nie było w dokumencie, w formacie, który wygląda idealnie. Dlatego krok czwarty – walidacja – nie jest opcjonalny. Wszystko, co da się sprawdzić słownikiem, sumą kontrolną albo zapytaniem do bazy, ma być sprawdzone kodem.
Operacje nieodwracalne. Wysłany mail, przelew, usunięty rekord, zmieniony status u kontrahenta. Tu wchodzi człowiek. Agent przygotowuje, człowiek zatwierdza jednym kliknięciem. Nie dlatego, że model jest głupi, tylko dlatego, że koszt pomyłki jest asymetryczny.
Od czego zacząć
Weź jeden proces, który już masz opisany, i zaznacz w nim miejsca, w których pracownik musi coś przeczytać i zrozumieć, zanim kliknie dalej. Zwykle jest ich jedno albo dwa. Reszta to przekładanie danych.
Jeśli chcesz przegadać, gdzie w Twoim procesie ta granica biegnie, umów bezpłatną rozmowę na 20-30 minut. Zwykle po niej wychodzi, że deterministycznego flow potrzeba więcej, niż się wydawało, a modelu mniej. I dobrze.
