Czy agent AI w n8n, Make albo Zapierze to dobre rozwiązanie?

Tak — jeśli pomyłka automatu kosztuje minutę czyjejś uwagi. Nie — jeśli kosztuje klienta, pieniądze albo zaufanie. Różnica nie leży w narzędziu. Leży w tym, kto odpowiada za proces i jak go zabezpieczył.

Formularz ze strony ma wpaść do arkusza. Nowy lead ma wywołać powiadomienie. Załącznik z maila ma wylądować w folderze. To zadania dla n8n, Make czy Zapiera — robimy je sami, szybko i tanio, i nie ma powodu, żeby pisać do tego kod.

Problem zaczyna się, gdy taki workflow dostaje etykietę „asystent AI dla firm" albo „wirtualny pracownik AI" i zaczyna obsługiwać procesy, w których błąd ma konsekwencje.

Jedno pytanie, które rozstrzyga wybór

Co się stanie, gdy automat się pomyli?

Jeśli odpowiedź brzmi „ktoś zauważy i poprawi" — bierz gotową platformę. Będzie dobrze.

Jeśli odpowiedź brzmi „klient dostanie ofertę z błędną ceną", „zapłacimy fakturę dwa razy", „handlowiec nie oddzwoni, bo system powiedział, że oddzwonił" — potrzebujesz czegoś więcej niż workflow. Potrzebujesz systemu, który został zaprojektowany z myślą o tym, że model językowy się myli, i który ma na to zabezpieczenia.

Uczciwie: taki system da się zbudować także w n8n. Platforma ma trwałe tabele danych, harmonogramy, możliwość dopisania własnego kodu, zatwierdzanie akcji przez człowieka i instalację na własnym serwerze. Kto twierdzi inaczej, nie zna n8n.

Dlaczego więc w naszych wdrożeniach wybraliśmy własny kod?

Trzy powody, dla których piszemy agentów w kodzie

1. Kontrakt „nie mów, że zrobiłeś, jeśli nie zrobiłeś".
Model językowy potrafi odpowiedzieć „wysłałem ofertę" bez wywołania narzędzia wysyłki. W naszym agencie model nie ma takiej możliwości: każda odpowiedź musi przejść przez wywołanie konkretnej akcji albo przez narzędzie „odpowiedz", które jawnie oznacza brak działania. Wdrożyliśmy to po realnym incydencie: „Zapisane" — odpowiedział agent. Sprawdziliśmy. Zapisu nie było. W n8n ten mechanizm (wymuszone wywołanie narzędzia) nie jest dziś ustawiany natywnie w węźle AI Agent — trzeba go budować ręcznie, omijając ten węzeł. To jedyna czysto techniczna różnica, którą podajemy. Reszta to kwestia projektu, nie narzędzia.

2. Logika, która ma testy, a nie tylko diagram.
Rabat per produkt per wykonawca, kolejność dokumentów, rozróżnienie „przełóż na jutro" od „zrobione", deduplikacja faktur po treści dokumentu, a nie po identyfikatorze maila. Da się to zrobić w węzłach Code. Ale wtedy piszesz kod wewnątrz platformy — bez repozytorium, bez testów regresyjnych, bez możliwości sprawdzenia, czy zmiana z wtorku nie zepsuła czegoś z marca. My mamy zestaw testów, który uruchamiamy przed każdym wdrożeniem. To decyduje o tym, czy system da się rozwijać przez lata, czy tylko postawić.

3. Mierzymy, zamiast obiecywać.
Router naszego agenta — moduł, który decyduje, jaką akcję wykonać na podstawie polecenia głosowego lub tekstowego — testujemy na 115 realnych poleceniach, każde uruchamiane pięciokrotnie — łącznie 575 prób. Ostatni wynik: 96,9% poleceń trafia do właściwej akcji. Mówimy wprost, co ta liczba mierzy: wybór akcji, nie poprawność całego zadania od początku do końca. Dlatego test rozumienia poleceń idzie u nas w parze z kontrolami wykonania — poprawnie rozpoznane „wyślij ofertę" to dopiero początek zadania. Pozostałe przypadki dokumentujemy jako znane ograniczenia i zamykamy w kolejnych wersjach. W tej branży prawie nikt nie publikuje takiej liczby, a jeśli publikuje — bez metody. Bez metody liczba nic nie znaczy.

Jak to wygląda w praktyce: od zapytania do oferty

Najlepiej pokazać to na jednym procesie, który działa u nas produkcyjnie u producenta bram.

Zapytanie przychodzi jako screenshot na Telegramie albo agent pobiera je sam ze strony producenta. Odczytuje parametry, uruchamia silnik konfiguracji, generuje wycenę, listę materiałów, rysunek techniczny i PDF oferty. Gotowa oferta czeka na potwierdzenie właściciela — dopiero po nim idzie mailem do klienta. Jeśli cena z wyceny nie zgadza się z ceną z silnika, wysyłka jest zablokowana niezależnie od potwierdzenia. Poprawki do oferty nakłada się kumulatywnie, bez liczenia od zera. Klient i zamówienie zapisują się w CRM bez ręcznego przepisywania.

Efekt, który widzi właściciel: między zapytaniem a gotową ofertą zostaje mu jeden ruch — potwierdzenie — i zasada, że agent woli nie wysłać, niż wysłać błędnie.

Ten sam agent obsługuje codzienną administrację: zadania i przypomnienia (także cykliczne, z odkładaniem i ochroną przed duplikatami), kalendarz głosem ze szkicem do potwierdzenia przed każdą zmianą, pocztę z kilku skrzynek, w której nic nie wychodzi bez słowa „wyślij", wieczorny brief z jutrzejszymi spotkaniami, codzienny skan faktur z PDF-ów tworzący zadania płatności, oraz propozycje tematów postów z bieżących wiadomości biznesowych i technologicznych — ze wskazaniem źródła — i szkic posta w Twoim stylu. Wszystko na Telegramie, głosówką lub tekstem.

Każdy klient ma własną, odizolowaną instancję na dedykowanym serwerze — własną bazę, własne klucze API, własne dane. Płaci za wdrożenie i opiekę nad swoim systemem, nie za dostęp do cudzej platformy, której cennik i limity mogą się zmienić. Agent odpowiada tylko właścicielowi. Logi domyślnie nie zawierają treści rozmów.

Ile to kosztuje

Workflow w n8n czy Make to setki złotych i kilka dni. Agent AI dla firmy zbudowany w kodzie, z testami i zabezpieczeniami, to inna półka cenowa — konkretne kwoty są w cenniku — i inna odpowiedzialność po naszej stronie. Dlatego nie zaczynamy od wyceny, tylko od pytania z początku tego tekstu. Jeśli po rozmowie okaże się, że wystarczy gotowa platforma, powiemy to i zbudujemy ją. Jeśli okaże się, że nie warto automatyzować w ogóle — też powiemy.

Masz proces, w którym pomyłka automatu kosztuje? Opisz go w wiadomości — odpowiem osobiście, czy to zadanie dla workflow, czy dla agenta, i dlaczego.