Węzeł AI Agent w n8n: kiedy się opłaca, a kiedy wystarczy zwykły workflow

Węzeł AI Agent w n8n kusi, bo obiecuje, że zamiast rysować każde rozgałęzienie procesu, wystarczy dać modelowi narzędzia i cel. Na przykładzie kwalifikacji zgłoszeń od klientów pokazuję dwa projekty tego samego procesu: raz jako zwykły workflow o stałych krokach, raz z węzłem AI Agent i trzema narzędziami. Od razu zastrzeżenie: to są projekty, nie wyniki — w tym tekście nie publikujemy pomiarów z porównania, tylko pokazujemy, jak je przeprowadzić. Mój wniosek z samej konstrukcji obu wariantów: w podstawowej kwalifikacji zwykły workflow zazwyczaj wygrywa, bo ma stałą, znaną z góry sekwencję głównych wywołań modelu, łatwiej go sprawdzić i działa przewidywalnie. Agent może zacząć się opłacać tam, gdzie to, czego trzeba szukać dalej, zależy od tego, co przyniosło poprzednie wyszukiwanie. Rozstrzyga to test na 50 prawdziwych zgłoszeniach, który opisuję niżej — i którego wyników nie da się przenieść z cudzej firmy na Waszą.

Ogólne zasady wyboru między agentem a prostszą automatyzacją opisaliśmy na stronie o wdrożeniu agentów AI, a różnicę między agentem a chatbotem w tekście agent AI vs chatbot. Podstawy n8n — czym jest workflow, węzeł i wykonanie, ile kosztuje n8n Cloud i jak obsłużyć błędy — są w przewodniku po n8n. Tutaj zajmujemy się wyłącznie decyzją: agent czy stałe kroki.

Co umożliwia węzeł AI Agent w n8n

Workflow w n8n to zwykle ciąg kroków ustalonych z góry: odczytaj, sprawdź, przekaż dalej. Węzeł AI Agent dodaje w nim miejsce, w którym kolejny krok wybiera model językowy. Model dostaje zgłoszenie, stałe polecenie (w n8n: System Message) i listę narzędzi, a potem w pętli decyduje, po które narzędzie sięgnąć, czyta wynik i decyduje znowu — aż uzna, że ma odpowiedź, albo dojdzie do limitu.

Według dokumentacji n8n (stan na 12 października 2026 r., najnowsza stabilna wersja 2.42.7):

• do węzła trzeba podłączyć model i co najmniej jedno narzędzie; od wersji 1.82.0 każdy węzeł AI Agent działa jako Tools Agent, czyli agent korzystający z narzędzi;
• Max Iterations ogranicza, ile razy model może się uruchomić przy jednym zadaniu — domyślnie 10;
• Return Intermediate Steps dołącza do wyniku kroki, które agent wykonał po drodze — to podstawa dziennika działań;
• Require Specific Output Format wymaga wyniku w ustalonym formacie zamiast swobodnego tekstu; po włączeniu trzeba podłączyć do węzła parser, czyli element sprawdzający i porządkujący wynik;
• narzędziem może być m.in. wywołanie innego workflow (Call n8n Workflow Tool), zapytanie do zewnętrznego systemu albo narzędzia serwera MCP — MCP (Model Context Protocol) to standardowy sposób łączenia asystenta AI z narzędziami zewnętrznego systemu, wracamy do niego niżej;
• do węzła można podłączyć pamięć rozmowy, ale prosta pamięć nie przetrwa między sesjami — przy kwalifikacji zgłoszeń i tak jej nie potrzebujemy, bo każde zgłoszenie jest osobną sprawą.

Wariant A: zwykły workflow ze stałymi krokami

W wariancie A model pracuje w ściśle wyznaczonych miejscach, a o kolejności kroków decyduje schemat, nie model:

1. Wyzwalacz uruchamia workflow dla każdego nowego zgłoszenia — z maila albo z systemu zgłoszeń.
2. Information Extractor (węzeł AI) wyciąga z treści ustalone pola: numer zamówienia, adres e-mail klienta, czego dotyczy sprawa. Listę pól opisujemy sami, więc poprawny wynik ma zawsze ten sam układ; zgłoszenia z brakującymi lub podejrzanymi polami kierujemy do ręcznej oceny.
3. Text Classifier (węzeł AI) przypisuje kategorię z naszej listy. Każda kategoria ma nazwę i opis, z którego model korzysta. Ważne ustawienie: gdy model nie znajdzie pasującej kategorii, węzeł domyślnie usuwa zgłoszenie z dalszego przebiegu. Trzeba to zmienić na osobną gałąź „Other”, która kieruje sprawę do ręcznej oceny — inaczej część zgłoszeń po cichu znika.
4. Gałęzie kategorii: Text Classifier ma osobne wyjście dla każdej kategorii (i dla „Other”), a każde z nich łączymy na stałe z właściwą ścieżką wewnątrz workflow: przy sprawie o zamówienie następuje odczyt z systemu zamówień (z tą samą zasadą potwierdzonej tożsamości klienta co w wariancie B), reklamacja ma trafić do działu reklamacji, reszta do kolejki. Na tym etapie nic się jeszcze nie zapisuje — samo przypisanie zgłoszenia do działu albo kolejki to zapis, więc czeka na krok 6.
5. Szkic odpowiedzi przygotowuje model w jednym wywołaniu, na podstawie zgłoszenia, danych z poprzednich kroków i fragmentów bazy wiedzy wyszukanych dla danej kategorii — tej samej bazy, z której korzysta wariant B.
6. Zatwierdzenie przez człowieka (Send and Wait) przed jakimkolwiek zapisem w CRM (systemie z danymi klientów), przypisaniem zgłoszenia do działu lub kolejki albo wysłaniem odpowiedzi, a dopiero potem zapis.

Jak działa krok zatwierdzania i obsługa błędów, pokazaliśmy na przykładzie faktur w przewodniku po n8n — tutaj przebieg jest taki sam. Dlaczego kwalifikacja zgłoszeń to dobry pierwszy proces do automatyzacji, wyjaśniamy w tekście o przykładach automatyzacji AI.

Najważniejsza cecha wariantu A: liczba głównych wywołań modelu na zgłoszenie jest ustalona z góry — w opisanej ścieżce trzy (ekstrakcja, klasyfikacja, szkic). Ponowienia po błędzie i automatyczne poprawki formatu wyniku mogą dodać kolejne, więc przy pomiarze liczcie wszystkie. Gdy coś pójdzie źle, widać, w którym węźle.

Wariant B: węzeł AI Agent z trzema narzędziami

W wariancie B ten sam proces obsługuje jeden węzeł AI Agent. Dostaje zgłoszenie, stałe polecenie opisujące zasady kwalifikacji i trzy narzędzia:

1. Wyszukanie klienta i jego zamówień — podrzędny workflow wywoływany przez Call n8n Workflow Tool, który czyta z CRM i z systemu zamówień, wyłącznie do odczytu. Ten podrzędny workflow sam pilnuje granic, niezależnie od modelu: klienta ustala z tożsamości potwierdzonej przez system zgłoszeń (na przykład zalogowanego konta klienta), a nie z tego, co poda model — sam adres nadawcy maila łatwo podrobić, więc bez potwierdzonej tożsamości dane zamówienia nie trafiają do agenta, dopóki nie potwierdzi jej człowiek. Jeśli zgłoszenie podaje numer zamówienia, sprawdza, czy należy on do tego klienta, zanim cokolwiek zwróci; jeśli nie podaje, zwraca otwarte zamówienia tego klienta. W obu przypadkach zwraca wyłącznie potrzebne pola. Przy niezgodności nie zwraca danych zamówienia, a sprawa trafia do ręcznej oceny — inaczej zgłoszenie z cudzym numerem albo z ukrytym poleceniem dla modelu mogłoby wyciągnąć dane innego klienta.
2. Przeszukanie bazy wiedzy — procedury, regulaminy, odpowiedzi na typowe pytania.
3. Zapisanie wyniku — kategorii, znalezionych danych, decyzji, czy sprawa trafia do człowieka, i szkicu odpowiedzi; to jedyne narzędzie, które coś zapisuje, i dlatego objęte zatwierdzaniem przez człowieka. Dzięki temu oba warianty zostawiają do oceny te same pola, a zatwierdzenie obejmuje także kategorię — dopiero po nim zgłoszenie zostaje przypisane według niej do tych samych miejsc co w wariancie A.

n8n pozwala wymagać zgody człowieka przed użyciem wybranego narzędzia agenta. Workflow się zatrzymuje, osoba zatwierdzająca widzi, co agent chce zrobić i z jakimi danymi, a zatwierdzenie uruchamia narzędzie, odmowa je anuluje i model dostaje informację o odmowie. Prośbę o zgodę można wysłać m.in. przez wbudowany czat n8n, Slacka, Microsoft Teams albo e-mail (Gmail lub Outlook). Ten krok stoi przed zapisem, nie po nim — zapis, który ktoś ogląda po fakcie, nie jest zatwierdzaniem, tylko raportem. Co musi zobaczyć osoba zatwierdzająca i jak nie zamienić tego w odruchowe klikanie, opisaliśmy w tekście o nadzorze człowieka (human in the loop).

Liczba wywołań modelu w wariancie B jest zmienna: każdy przebieg pętli agenta to osobne wywołanie, a agent sam decyduje, ile ich potrzeba — aż do ustawionego limitu.

Porównanie obu wariantów

Rachunek za n8n wychodzi w obu wariantach podobnie: w n8n Cloud jedno wykonanie to jeden przebieg całego workflow, niezależnie od liczby kroków, a wykonania podrzędnych workflow — także tych, których agent używa jako narzędzi — nie zużywają limitu wykonań w planie. Jeżeli jednak projekt dzieli obsługę jednego zgłoszenia na kilka osobnych workflow uruchamianych niezależnie, każdy z nich liczy się osobno, więc jedno zgłoszenie nie zawsze oznacza jedno wykonanie. Różnica między wariantami leży gdzie indziej: w rachunku od dostawcy modelu i w czasie ludzi, którzy szukają przyczyn błędów.

Ile kosztuje jedno zgłoszenie: wzór zamiast zgadywania

Nie publikujemy tu tabeli z kosztem w złotych, bo takiego pomiaru nie przeprowadziliśmy na potrzeby tego tekstu — a szacunek przeniesiony z cudzego procesu wprowadza w błąd. Uczciwą liczbę daje dopiero pomiar na Waszych zgłoszeniach, Waszym modelu i Waszym opisie narzędzi. Zamiast tego wzór, który pozwala policzyć koszt użycia modelu po teście. Token to fragment tekstu, od którego dostawca modelu liczy opłatę:

koszt użycia modelu na zgłoszenie (przypadek prosty) = suma po wszystkich wywołaniach modelu (tokeny wejścia × cena wejścia za milion tokenów + tokeny wyjścia × cena wyjścia za milion tokenów) ÷ 1 000 000 × kurs waluty

Dostawcy zwykle podają ceny za milion tokenów, stąd dzielenie. Liczby pobierajcie z danych o zużyciu zwracanych przez dostawcę, a nie z założeń. Przed testem sprawdźcie, jak zapiszecie je dla każdego wywołania — na przykład z panelu lub dziennika zużycia u dostawcy modelu albo przez narzędzie do śledzenia wywołań — bo wynik węzła AI Agent nie musi ich zawierać; brakujących danych nie liczcie jako zerowego kosztu. Ceny dostawcy zapisujcie z datą odczytu, a kurs z datą i źródłem. Jeżeli dostawca liczy różne stawki dla różnych rodzajów tokenów (na przykład osobno dla wejścia odczytanego z bufora), każdą kategorię z raportu dostawcy mnoży się przez jej własną cenę. Sprawdźcie przy tym, czy raport podaje sumę i jej podział: jeśli tokeny z bufora są już wliczone do tokenów wejścia, zwykłą stawkę stosujcie tylko do pozostałych tokenów wejścia, a tokeny z bufora liczcie po ich własnej stawce. Abonament n8n, opłaty za inne usługi i czas ludzi to osobne pozycje.

Dlaczego wariant B może kosztować więcej na zgłoszenie? W wariancie A wywołań jest kilka i każde dostaje tylko to, czego potrzebuje. W wariancie B każde wywołanie w pętli dostaje stałe polecenie, opisy wszystkich narzędzi i to, co agent zebrał do tej pory, więc przy kilku przebiegach agent może zużyć więcej tokenów. Czy i o ile więcej — trzeba zmierzyć. Pełną listę pozycji na rachunku za agenta (integracje, nadzór, utrzymanie) rozpisaliśmy w tekście ile kosztuje agent AI.

Kiedy agent może zarobić na siebie

Agent ma szansę na przewagę tam, gdzie to, czego i gdzie trzeba szukać dalej, zależy od tego, co przyniosło poprzednie wyszukiwanie. Przykładowy, wymyślony na potrzeby tekstu przebieg obsługi zgłoszenia „paczka nie doszła”:

• klient podał numer zamówienia — wystarczy sprawdzić jego status;
• numeru nie ma, a klient, którego tożsamość potwierdził system zgłoszeń, ma dwa otwarte zamówienia — trzeba z treści wiadomości ustalić, którego dotyczy sprawa, i dopiero dla niego sprawdzić status;
• status pokazuje zwrot w toku, a nie wysyłkę — kolejnym krokiem jest procedura zwrotów w bazie wiedzy, a nie odpowiedź o dostawie;
• wiadomość w ogóle nie dotyczy zamówienia — trzeba przeszukać bazę wiedzy, i to innym zapytaniem niż to, które pasowałoby do systemu zamówień.

Każdą z tych ścieżek da się zapisać w wariancie A jako kolejne rozgałęzienie. Przy kilku systemach i wielu możliwych kolejnościach wyszukiwania drzewo warunków może jednak rosnąć szybciej niż proces, a jego utrzymanie — kosztować więcej niż różnica w tokenach. Wtedy agent, który sam wybiera następne wyszukiwanie, staje się kandydatem. Czy faktycznie wybiera dobrze, rozstrzyga test.

Trzecia odpowiedź: stałe kroki z agentem w jednej gałęzi

W praktyce wybór rzadko jest zero-jedynkowy. Wariant, od którego zaczynamy w ploch.ai, to połączenie: Information Extractor wyciąga pola, Text Classifier przypisuje kategorię z ustalonej listy, a każda kategoria ma własną, na stałe połączoną gałąź. Model przygotowuje też szkic odpowiedzi, a węzeł AI Agent dokładamy w jednej gałęzi — tej, w której naprawdę trzeba szukać w kilku systemach. Zapis w systemach i wysłanie odpowiedzi zawsze czekają na zatwierdzenie przez człowieka. W pierwszej wersji nie ma od tego wyjątków; które czynności mogą później działać bez zgody, rozstrzygają dopiero liczby z okresu zatwierdzania.

Test na 50 zgłoszeniach: jak podjąć decyzję

Decyzję „agent czy stałe kroki” podejmuje się na prawdziwych zgłoszeniach, nie na pokazie. Przepis:

1. Wybierzcie 50 prawdziwych zgłoszeń z ostatnich tygodni. Celowo dobierzcie trudne przypadki: bez numeru zamówienia, z dwoma tematami w jednej wiadomości, w innym języku, z załącznikiem zamiast treści (zamianę załącznika na tekst zróbcie jednym, wspólnym krokiem przed oboma wariantami, żeby nie mierzyć różnicy w odczycie plików). Dane osobowe zastąpcie zmyślonymi, ale konsekwentnie — ten sam zmyślony identyfikator klienta nadany przez system zgłoszeń w zgłoszeniu i w testowym rekordzie klienta — inaczej wyszukiwanie nie ma czego znaleźć; zgłoszenia bez potwierdzonej tożsamości mają jako oczekiwany wynik ręczną ocenę. Zanim wybierzecie tę pięćdziesiątkę, dopracujcie oba warianty — polecenia dla modelu, opisy kategorii, pola i narzędzia — na osobnym zestawie zgłoszeń i zamroźcie je; inaczej test mierzy, który wariant lepiej dopasowano do znanych przypadków. Zamiana danych na zmyślone ogranicza ich zakres, ale nie jest anonimizacją, dlatego zanim jakikolwiek tekst zgłoszeń trafi do n8n i do dostawcy modelu, ustalcie, gdzie jest przetwarzany, kto ma do niego dostęp i kiedy zostanie usunięty. Więcej o tym w tekście o RODO (ogólnym rozporządzeniu o ochronie danych) przy wdrożeniu modeli językowych.
2. Dla każdego zgłoszenia zapiszcie z góry oczekiwany wynik: kategorię, dane, które trzeba znaleźć, to, czy sprawa powinna trafić do człowieka, oraz które narzędzia są wymagane, dozwolone i zabronione. Dla zgłoszeń z dwoma tematami ustalcie zasadę z góry — na przykład kategoria ważniejszego tematu i notatka dla człowieka albo od razu ręczna ocena — i zapiszcie wszystkie oczekiwane miejsca docelowe.
3. Przepuśćcie przez oba warianty te same zgłoszenia na tych samych, niezmienianych danych testowych, z zapisami kierowanymi do miejsca testowego, a nie do prawdziwego CRM. Oba warianty kończą się w tym samym punkcie: zatwierdzonym szkicem odpowiedzi zapisanym w tym samym miejscu testowym; wysyłka do klienta jest poza porównaniem. Model i jego ustawienia ustalcie na czas testu na sztywno, a każde zgłoszenie przepuśćcie przez każdy wariant kilka razy i zapiszcie rozrzut wyników — model nie odpowiada za każdym razem tak samo, więc jeden przebieg może przypadkiem przesądzić o decyzji. Szkice z obu wariantów pokazujcie osobie sprawdzającej w losowej kolejności i bez informacji, z którego wariantu pochodzą, żeby ograniczyć wpływ kolejności i znajomości zgłoszenia na porównanie czasu sprawdzania. Workflow uruchamiajcie ręcznie z edytora — według dokumentacji n8n uruchomienia ręczne nie liczą się do limitu wykonań.
4. Przy każdym zgłoszeniu zapiszcie: czy wynik zgadza się z oczekiwanym, liczbę przebiegów pętli (w wariancie B) i osobno wszystkie faktyczne wywołania modelu, łącznie z ponowieniami i poprawkami formatu wyniku, tokeny wejścia i wyjścia, poprawność faktów w szkicu odpowiedzi, czas, którego człowiek potrzebuje na jego sprawdzenie i poprawienie, wywołania niewłaściwego narzędzia, zgłoszenia, które doszły do limitu Max Iterations, i czas potrzebny na znalezienie przyczyny każdego błędu.
5. Ustalcie próg przed testem, nie po nim. Na przykład: agent wchodzi tylko wtedy, gdy poprawnie obsługuje przypadki, z którymi stałe kroki sobie nie radzą, nie psuje tych, które działały, a koszt na zgłoszenie mieści się w budżecie. Koszt zmierzcie osobno, przepuszczając przez oba warianty tak samo próbkę odzwierciedlającą zwykły ruch, a nie tę celowo trudną pięćdziesiątkę.

Pięćdziesiąt zgłoszeń to celowo dobrany zestaw testowy, który nie pozwala oszacować trafności dla wszystkich przychodzących zgłoszeń. To tyle, ile da się przejrzeć ręcznie, sprawa po sprawie, i zobaczyć, dlaczego agent się pomylił. Mierzenie trafności klasyfikacji na większej liczbie zgłoszeń przed włączeniem automatycznego kierowania to osobny temat.

Narzędzia MCP w n8n

W n8n do podłączania narzędzi przez MCP służy węzeł MCP Client Tool: udostępnia agentowi narzędzia, które oferuje serwer MCP danego systemu. Najważniejsze ustawienie to Tools to Include: „All” udostępnia agentowi wszystkie narzędzia serwera, „Selected” tylko wybrane, a „All Except” wszystkie poza wykluczonymi. Wybierajcie „Selected” — agent powinien widzieć tylko narzędzia potrzebne w tym procesie, a nie wszystko, co system potrafi. Co oznacza podłączenie asystenta AI do Waszego systemu przez MCP, opisaliśmy na stronie o połączeniu asystenta AI z systemem.

Co zamówić u tego, kto to buduje

Jeżeli zlecacie budowę agenta w n8n, ta lista mieści się na jednej stronie umowy albo zamówienia:

• Wyniki testu na 50 zgłoszeniach dla obu wariantów, zgłoszenie po zgłoszeniu, z liczbą tokenów i datą odczytu cen modelu.
• Zatwierdzanie przed każdym zapisem: zgoda człowieka na narzędzia agenta, które coś zapisują lub wysyłają, i krok Send and Wait przed zapisem w stałych krokach.
• Zamkniętą listę narzędzi: tylko te potrzebne w procesie, żadnego narzędzia do usuwania danych, w MCP Client Tool ustawienie „Selected”, dostęp do systemów tylko do odczytu tam, gdzie wystarczy odczyt, a narzędzia odczytu ograniczone do danych klienta, którego dotyczy zgłoszenie. Zasady nadawania uprawnień agentom opisaliśmy na stronie o wdrożeniu agentów AI.
• Świadomie ustawiony limit Max Iterations, a nie domyślne 10 tylko dlatego, że takie było.
• Dziennik wywołań narzędzi: włączone Return Intermediate Steps i miejsce, gdzie te kroki są zapisywane.
• Workflow obsługi błędów z krokiem Error Trigger i świadomie ustalony czas przechowywania danych wykonań — oba opisaliśmy w przewodniku po n8n.

Jedna uwaga do zatwierdzania w agencie: dokumentacja n8n zaleca opisać w stałym poleceniu dla modelu narzędzia i kroki zatwierdzania. To polecenie jest instrukcją, nie zabezpieczeniem. Zabezpieczeniem jest tylko to, co działa niezależnie od modelu: krok zatwierdzania, lista narzędzi i uprawnienia w systemach.

Co dalej

Kwalifikacja zgłoszeń to jeden z procesów, które automatyzujemy w ploch.ai, zwykle jako pierwszy krok przed czymkolwiek, co rozmawia z klientami — dlaczego w tej kolejności, opisaliśmy na stronie o automatyzacji obsługi klienta. Jeżeli zastanawiacie się, czy w Waszym procesie agent się opłaci, napiszcie do nas — zacznijmy od jednego rodzaju zgłoszeń i testu na Waszych przypadkach. Jak wygląda taki projekt od wyboru zadania po zatwierdzanie, opisaliśmy na stronie o wdrożeniu agentów AI.

Źródła i stan na 12 października 2026 roku

• n8n Docs — węzeł AI Agent — wymagane co najmniej jedno narzędzie, Tools Agent od wersji 1.82.0; odczyt 12 października 2026 r.
• n8n Docs — Tools Agent — System Message, Max Iterations (domyślnie 10), Return Intermediate Steps, Require Specific Output Format z parserem, pamięć; odczyt 12 października 2026 r.
• n8n Docs — zatwierdzanie narzędzi agenta przez człowieka — zatwierdzenie i odmowa, kanały, zalecenie dotyczące polecenia systemowego; odczyt 12 października 2026 r.
• n8n Docs — Text Classifier i Information Extractor — kategorie z opisami, domyślne usuwanie zgłoszeń bez dopasowania, sposoby definiowania pól; odczyt 12 października 2026 r.
• n8n Docs — MCP Client Tool — ustawienie Tools to Include; odczyt 12 października 2026 r.
• n8n Docs — podrzędne workflow i wykonania — wykonania podrzędnych workflow i uruchomienia ręczne nie zużywają limitu; odczyt 12 października 2026 r.
• Kod źródłowy węzła Text Classifier w repozytorium n8n na GitHubie — osobne wyjście dla każdej kategorii; odczyt 12 października 2026 r.
• Cennik n8n — definicja wykonania i ceny planów; odczyt 12 października 2026 r.
• n8n na GitHubie — wydania — wersja 2.42.7 jako najnowsza stabilna 12 października 2026 r.