Agentic workflow 101. Kiedy agent, kiedy zwykły pipeline.
Połowa zapytań, które dostaję od klientów w 2026, zaczyna się od "chcę agenta AI do X". W siedmiu na dziesięć przypadków nie chcą agenta, chcą deterministycznego workflow w n8n. Poniżej opisuję, jak sam rozróżniam te dwa przypadki, z policzonymi kosztami i błędami, które kosztowały mnie albo klientów realne pieniądze.
Co robi agent, a czego nie robi zwykły pipeline
Zwykły workflow w n8n to graf węzłów z zdefiniowaną ścieżką. Wchodzi input, idzie po znanych krokach, wychodzi output. Jeśli na którymś węźle coś się nie zgadza, workflow pęka albo idzie na alternatywną ścieżkę, którą też rozrysowałem z góry.
Agent LLM jest inny. Dostaje cel ("sklasyfikuj ten email i zareaguj"), listę narzędzi (search CRM, pobierz historię wiadomości, wyślij Slack ping) i decyduje w trakcie runu, których narzędzi użyć, w jakiej kolejności i kiedy skończyć. Nie rozrysowuję ścieżki z góry, bo nie znam kontekstu, który agent zobaczy za godzinę.
Różnica kosztu: deterministyczny workflow n8n kosztuje 0.0001 PLN za run (pobieranie RAM, CPU, odrobina latency). Agent LLM na Gemini 3.5 Flash kosztuje mnie w mojej infrastrukturze od 0.03 do 0.06 PLN za run, na Gemini 3.1 Pro od 0.16 do 0.32 PLN. Przy 500 runach dziennie to 45 PLN vs 600 PLN miesięcznie. Różnica realna, nie kosmetyczna.
Agent to nie zamiennik pipeline'u, tylko narzędzie do przypadków, w których nie da się zdefiniować ścieżki z góry.
Trzy scenariusze, w których agent daje realną przewagę
1. Klasyfikacja plus działanie w jednym ruchu
Klient dostaje 80 do 200 wiadomości dziennie w inboxie sprzedaży. Każda jest inna. Lead? Support? Spam? Pytanie od istniejącego klienta, które trzeba przekierować? Zwykły klasyfikator z regułami regex wyłapuje 40% ruchu, LLM classifier sam w sobie 85%. Ale realny problem to nie sama klasyfikacja. Problem to co dalej.
Agent dostaje wiadomość, klasyfikuje (to pierwsza decyzja), a potem sam decyduje: czy wyszukać kontakt w CRM (Clearbit + Pipedrive), czy zapytać model o draft odpowiedzi, czy eskalować do Adiego przez Slack. Na podstawie klasyfikacji wybiera dalsze narzędzia. Robi to w jednym runie, nie potrzebuję pięciu węzłów i trzech warunkowych rozgałęzień w n8n.
Sens jest w tym ostatnim kroku: agent nie tylko etykietuje wiadomość, ale od razu robi następny ruch (lookup, draft, eskalacja), więc czas pierwszej reakcji spada z godzin do minut. Nie rzucam tu twardym procentem, bo trafność i oszczędność zależą od jakości danych wejściowych i progów, które ustawisz u siebie.
2. Research klienta przed odpowiedzią
Zapytanie ofertowe od nieznanej firmy. Zanim odpowiesz, chcesz wiedzieć: kto to, co robią, czy już z nimi rozmawialiśmy, jakie są ich approx. obroty. Człowiek spędza nad tym 8 do 15 minut, zanim usiądzie do draftu. Workflow n8n z 12 predefiniowanymi krokami lookup (Clearbit, Apollo, LinkedIn scrape, GitHub org, Google search, internal CRM) też to zrobi, ale zawsze wykonuje wszystkie 12 kroków nawet gdy pierwsze trzy dają pełną odpowiedź.
Agent zaczyna od tanich lookupów, sprawdza czy ma wystarczający kontekst, i dopiero gdy confidence jest poniżej progu, odpala droższe narzędzia. Zamiast sztywnych dwunastu kroków za każdym razem robi ich tyle, ile naprawdę trzeba, więc research jest tańszy i szybszy bez utraty trafności. Ile dokładnie zyskasz, zależy od tego, jak często pierwsze źródła już wystarczają.
3. Decision tree z niepewnymi inputami
Faktura przychodzi jako PDF. OCR wyciąga pola (NIP, kwota, data, numer), ale z różną confidence per pole. Klasyczny workflow ma dwie opcje: albo accept wszystko co confidence > 80%, albo wszystko do ręcznej weryfikacji. Oba wybory są złe.
Agent patrzy na całokształt faktury: jeśli NIP jest pewny (confidence 0.98) i data pewna (0.95), ale numer faktury niepewny (0.62), sprawdza historię dostawcy w systemie. Gdy dostawca jest znany i numeracja ma format ciągły, agent wyciąga brakujący numer z formatu. Gdy dostawca nowy, eskaluje do człowieka. Dzięki temu znika wybór zero-jedynkowy (accept wszystko powyżej progu albo wszystko do ręki): automatycznie wchodzą faktury, które realnie są pewne, a do ręcznej kolejki trafia tylko to, co naprawdę niepewne.
Trzy scenariusze, w których agent to drogie udziwnienie
1. Liniowy ETL z jasnymi regułami
Import CSV z faktur do Pipedrive. 5000 rekordów dziennie. Mapping pól jest znany: kolumna A to email, B to firma, C to wartość oferty. Walidacja: email musi pasować regex, kwota > 0, data w przeszłości. Dla takiego zadania agent LLM jest 100x droższy od zwykłego Python script w Docker albo workflow n8n z 3 węzłami. I 20x wolniejszy.
Moja zasada: jeśli mogę opisać zadanie jednym flow diagramem bez pytania "a co, jeśli...", pipeline wygrywa. Agent dodaj tylko jako fallback, gdy pipeline wyrzuci rekord do kolejki ręcznych.
2. Walidacja formatów i struktur
Walidacja NIP, IBAN, email. Agent LLM to zrobi, ale po co. Python re match w mikrosekundach za 0 groszy. LLM za 0.06 PLN i 200 ms latency. Dla 10000 walidacji dziennie różnica: 20 groszy vs 600 PLN miesięcznie.
3. Scheduled jobs z przewidywalnym wynikiem
Raport sprzedaży za wczoraj wyłamany o 7:00 do Slacka. Pull z bazy, aggregate, render do markdown, push. Jeden cron, 50 linii kodu w n8n. Agent tu nie ma co robić. Jedyna decyzja to "czy dzisiaj jest poniedziałek" i to kalendarz rozstrzygnie.
Ile kosztuje jeden run w praktyce
Szacunkowe koszty per jeden run agenta (w pełni zakończony: sukces albo eskalacja), policzone z aktualnego cennika Vertex AI dla typowej liczby wywołań narzędzi. To rzędy wielkości do własnej kalkulacji, nie pomiar z konkretnego wdrożenia:
| Use case | Model | Avg tool calls | Koszt per run (USD) | Koszt per run (PLN) |
|---|---|---|---|---|
| Klasyfikacja + draft email | Gemini 3.5 Flash | 2.1 | 0.011 | 0.044 |
| Research klienta (B2B lookup) | Gemini 3.1 Pro | 4.3 | 0.058 | 0.23 |
| OCR plus decyzja o akceptacji | Gemini 3.5 Flash | 1.8 | 0.009 | 0.036 |
| Agent pełny RAG + CRM write | Gemini 3.1 Pro | 6.7 | 0.092 | 0.37 |
Przy 500 runach dziennie miesięczny budżet LLM: od 660 PLN (Flash, 2 tool calls) do 5500 PLN (Pro, 6-7 tool calls). Do tego dochodzi infrastruktura (Vertex AI endpoint, n8n, Postgres): 340 PLN miesięcznie w moim standardowym setupie.
Jeśli bez agenta koszt operacji (czas człowieka × stawka) jest poniżej 2 PLN per run, agent się nie opłaca. Powyżej 5 PLN agent niemal zawsze się zwraca w trzy miesiące. Pomiędzy zależy od skali.
Stack, który wybrałem i dlaczego
Po trzech latach eksperymentowania z różnymi kombinacjami, mój domyślny stack produkcyjny dla agentic workflows wygląda tak:
- Vertex AI (Gemini 3.5 Flash/Pro): stabilne latency, dobry tool calling, rozsądne pricing per token. Region europe-central2 dla klientów z wymogami GDPR o przetwarzaniu w UE.
- n8n self-hosted na Hetznerze: orchestracja, kolejki, retry logic, widoczne logi per run. Self-hosted, bo kontrola nad kosztami i danymi.
- PostgreSQL + pgvector: baza wiedzy dla RAG, embeddings klienta, historia runów. Dzielony instance na Cloud SQL.
- Cloud Run dla niestandardowego kodu: jeśli narzędzie potrzebuje więcej niż się wciska w n8n, wrzucam do Cloud Run.
- Secret Manager + Workload Identity: żadnych API keys w repo ani w zmiennych środowiskowych kontenera.
Co świadomie pomijam: LangChain, AutoGPT, CrewAI. Każdy z nich jest abstrakcją, która w moich testach albo dokłada bugi, albo zamyka w ekosystem utrudniający debug. Prostszy tool-calling loop napisany ręcznie w n8n Code node daje mi pełną widoczność i kontrolę.
Pięć błędów, które widzę u nowych zespołów
Każdy z tych błędów kosztował kogoś pieniądze albo wiarygodność u klienta. Piszę z obserwacji na audytach po poprzednikach.
- Brak guardraili na agencie, który ma write access do CRM. Agent usunął 800 rekordów bo błędnie zinterpretował "clean up duplicates". Nigdy nie daj agentowi DELETE bez preview step i limitu.
- Brak timeout na tool calls. Agent utknął w pętli, bo jedno narzędzie (zewnętrzny API) odpowiadało w 45 sekundach. Wprowadź hard timeout per tool call (ja stawiam 15 s) i max iterations per run (ja stawiam 8).
- Log tylko ostatniej odpowiedzi. Gdy agent się pomyli, nie wiesz, dlaczego. Loguj każdy tool call z inputem i outputem. Ja używam Sentry + Postgres JSONB tabela, jedno miejsce, searchable.
- Testy tylko na happy path. Agent działa na czystych danych. W produkcji dostaje brudne, niekompletne, z literówkami. Buduj eval set z 50 realnych przypadków i re-run go przy każdej zmianie promptu.
- Prompt wersjonowany w pamięci developera. Prompt jest produktem. Trzymaj w git, review'uj, wersjonuj. Zmiana promptu bez eval to taki sam błąd jak deploy bez testów.
Checklist: kiedy agent jest gotowy na produkcję
Przed pierwszym deployem agenta do produkcji przechodzę przez tę listę. Każdy punkt musi być na "tak", inaczej zostaje na stagingu.
- Eval set z minimum 30 realnych przypadków, z oznaczonym oczekiwanym wynikiem. Przechodzi co najmniej 90%.
- Guardraile na każdym tool call z write access (preview, limit, human approval dla batch > X).
- Hard timeout per tool call (15 s domyślnie) i max iterations per run (8 domyślnie).
- Logowanie każdego tool call z inputem, outputem, czasem, kosztem tokenów. Searchable z poziomu Sentry albo jsonb query.
- Fallback do człowieka, gdy agent wyrzuci error albo przekroczy max iterations. Nie "retry 3 razy i padaj", tylko "retry 1 raz, potem Slack ping".
- Budżet miesięczny zdefiniowany i alert gdy 70% wykorzystania. Ja ustawiam alert przez GCP Billing budgets.
- Prompt w git z version tag, przetestowany na eval set przed merge do main.
- Runbook w dokumentacji: co robić, gdy agent nagle wyrzuca błędy, kogo pingować, jak wyłączyć.
Większość zapytań, które słyszę jako "chcę agenta AI", rozwiązuje się w 3 węzły n8n z prostym LLM classifier node. Agent to dodatek na przypadki, w których deterministyczny flow nie daje rady. Jeśli nie potrafisz opisać dlaczego agent jest potrzebny w twoim konkretnym przypadku, prawdopodobnie nie jest.
Najczęstsze pytania
Czym różni się agent LLM od deterministycznego workflow n8n?
Deterministyczny workflow ma zdefiniowaną ścieżkę i reguły. Agent LLM decyduje w trakcie runu: które narzędzie użyć, czy pytać dalej, kiedy zakończyć. Agent opłaca się gdy reguł nie da się wpisać z góry, bo kontekst jest zmienny. Dla stałych reguł pipeline jest tańszy i szybszy.
Ile kosztuje jeden run agenta LLM w produkcji?
Zależy od modelu i liczby narzędzi. Przy cenniku Vertex AI dla Gemini 3.5 Flash jeden run wychodzi rzędu 0.008 do 0.015 USD. Gemini 3.1 Pro dla bardziej złożonych decyzji: 0.04 do 0.08 USD. Przy 500 runach dziennie miesięczny koszt LLM to z grubsza 120 do 1200 PLN.
Kiedy nie używać agenta AI?
Kiedy reguły biznesowe są stałe i deterministyczne. Przykłady: import CSV do bazy, walidacja NIP, scheduled raporty, ETL między dwoma znanymi API. Dla tych zadań agent LLM jest 10 do 100 razy droższy od zwykłego workflow n8n i wolniejszy o rząd wielkości.
Jakiego modelu LLM używać do agenta produkcyjnego?
Mój domyślny wybór w 2026: Gemini 3.5 Flash dla klasyfikacji i prostych decyzji, Gemini 3.1 Pro dla złożonych agentów z wieloma tool calls. W specyficznych przypadkach (długi kontekst, analiza dokumentów) sięgam po modele Anthropic przez API. GPT-4.1 trzymam jako fallback, rzadziej używam w produkcji ze względu na mniej przewidywalne latency.
Zastanawiasz się, czy agent to dobry wybór u Ciebie?
Darmowy warsztat otwierający, 90 minut. Rozrysujemy Twój proces, powiem wprost czy agent ma sens, czy wystarczy zwykły workflow.
Zamów warsztat →