Jedyna różnica, która naprawdę dzieli dwa podejścia do orkiestracji. Wszystko inne z niej wynika.
Porównania narzędzi orkiestrujących zwykle rozbijają się na listę cech: to ma czterysta integracji, tamto ma budżety, jedno jest dojrzalsze, drugie nowsze. Listy są prawdziwe i mało pomocne, bo nie mówią, skąd te różnice się biorą.
Biorą się z jednego rozstrzygnięcia. Kto ustala, którą krawędzią pójdzie wykonanie — ty, przed uruchomieniem, czy system, w trakcie.
Z tej jednej decyzji wynika koszt, przewidywalność, sposób debugowania i to, czego potrzebujesz, żeby całość w ogóle działała bezpiecznie.
Krawędź ustalona z góry
Rysujesz przejścia przed startem. Wszystkie. Rozgałęzienia to warunki, które ktoś zakodował wcześniej, a to, że jeden z węzłów prowadzi własne rozumowanie, niczego tu nie zmienia — decyzja o tym, dokąd dalej, i tak zapadła przy projektowaniu.
Co z tego wynika:
Koszt policzysz przed uruchomieniem. Tyle węzłów, tyle wywołań, tyle tokenów. Budżetowanie jest arytmetyką, nie prognozą.
Wynik jest powtarzalny. To samo wejście daje tę samą ścieżkę. Testowanie ma sens, bo test sprawdza to, co wydarzy się na produkcji.
Debug polega na przejściu ścieżki. Widzisz ją na ekranie, przechodzisz węzeł po węźle, znajdujesz miejsce, w którym dane wyglądają nie tak.
Zmiana wymaga edycji. Nowy przypadek to nowa gałąź, którą ktoś musi dorysować. Jeśli przypadków przybywa co tydzień, schemat rośnie i w pewnym momencie nikt nie ogarnia go w całości.
Krawędź rozstrzygana w trakcie
Definiujesz cel, obsadę i to, co komu wolno. Droga powstaje po drodze, na podstawie tego, co znaleziono.
Co z tego wynika:
Koszt jest zmienny z założenia. Nie jest to wada, tylko cecha — ale wymaga innego podejścia do budżetowania i trzeba to powiedzieć przed wdrożeniem, nie po pierwszej fakturze.
Wynik nie jest powtarzalny. Dwa uruchomienia tego samego zadania mogą pójść inaczej i oba mogą być poprawne. To zmienia sens testowania: nie sprawdzasz ścieżki, tylko czy wynik spełnia kryteria.
Debug wymaga śladu. Ścieżki nie ma na ekranie, bo powstała w czasie działania. Jeśli nie zapisałeś, dlaczego wybrano tę krawędź, nie odtworzysz tego później — o tym jest osobny artykuł w tym torze.
Nowy przypadek nie wymaga edycji. To jest cała korzyść i jedyny powód, żeby płacić za resztę.
Dwa narzędzia jako ilustracja
Warto zobaczyć to na czymś konkretnym, z zastrzeżeniem, że narzędzia zmieniają się co kwartał, a mechanizm nie.
n8n orkiestruje kroki. Rysujesz graf, trigger odpala, dane płyną po przewodach. Ma węzeł AI Agent zbudowany na LangChainie, wymienne modele, narzędzia, pamięć, RAG, obsługę MCP — autonomii jest tam sporo. Tyle że mieszka wewnątrz jednego węzła. Wszystko dookoła pozostaje schematem, który zaprojektował i utrzymuje człowiek.
Paperclip orkiestruje pracowników. Definiujesz cel i obsadę, a droga powstaje w trakcie. Zgłoszenia trwają między sesjami, agent budzi się cyklicznie z kolejki i wraca do przerwanej pracy. Zadania pobierane są atomowo, z blokadą — bo gdy kilku niezależnych wykonawców może sięgnąć po to samo, potrzebujesz gwarancji, że dwóch nie zrobi tego samego dwa razy.
Pełniejsze porównanie obu, razem z tym, gdzie n8n jest po prostu lepszym wyborem, jest w osobnym tekście: n8n czy Paperclip — i dlaczego to złe pytanie.
Tutaj wystarczy jedna obserwacja: to nie są konkurenci, tylko dwie warstwy tego samego stosu. Zdarzeniowe i deterministyczne należy do pierwszej. To, co wymaga osądu — research, synteza, przegląd, decyzja o tym, czy w ogóle jest o czym raportować — do drugiej.
Trzy rzeczy, które zmieniają się razem z krawędzią
Warto je wymienić osobno, bo w praktyce zaskakują.
Testowanie. Przy krawędzi ustalonej test sprawdza ścieżkę. Przy rozstrzyganej w trakcie ścieżka jest za każdym razem inna, więc test musi sprawdzać wynik względem kryteriów. To jest inna dyscyplina i inne narzędzia — bliżej ewaluacji niż testów jednostkowych.
Ponowienie. W grafie przepływu powtarzasz od miejsca awarii, bo wiesz, gdzie byłeś. W grafie wykonania powtórzenie może pójść inną ścieżką — więc pytanie brzmi nie „powtórz krok”, tylko „powtórz z jakiego stanu”.
Zmiana modelu. W grafie przepływu podmiana modelu w węźle AI zmienia jakość tego jednego kroku. W grafie wykonania zmienia też trasę, bo model współdecyduje o krawędziach. To jest jeden z powodów, dla których agent działający wczoraj dziś działa inaczej mimo braku zmian w kodzie.
Test, który rozstrzyga
Jedno pytanie, zadane o konkretny proces: czy potrafisz narysować go w całości, z góry, ze wszystkimi rozgałęzieniami?
Tak → krawędź ustalona. Nawet jeśli jeden z kroków wymaga osądu, wstaw tam agenta i zostaw resztę jako schemat. Nie potrzebujesz zespołu do procesu, który mieści się na jednym diagramie.
Nie, bo droga zależy od tego, co znajdziemy → dopiero teraz ma sens krawędź rozstrzygana w trakcie. I nawet wtedy sprawdź trzy warunki z poprzedniego artykułu, bo sama nieprzewidywalność drogi nie wystarcza.
Nie wiem, bo nigdy tego procesu nie opisałem → to jest najczęstsza odpowiedź i oznacza, że problemem nie jest wybór architektury. Zacznij od opisania procesu. Bardzo często okazuje się wtedy, że jest deterministyczny.
Wzorzec mieszany
Rozstrzygnięcie „albo–albo” jest w praktyce rzadkie, bo większość systemów ma w sobie oba rodzaje pracy.
Wzorzec, który z tego wychodzi i który da się złożyć z narzędzi dostępnych dziś:
zdarzenie w systemie źródłowym → warstwa deterministyczna wychwytuje je i normalizuje dane → tworzy zadanie w warstwie decyzyjnej → tam praca wymagająca osądu, w cyklach, z budżetem i śladem → wynik wraca do warstwy deterministycznej, która zapisuje go i rozsyła powiadomienia
Każda warstwa robi to, w czym jest dobra, i żadna nie udaje drugiej. Integracje, wyzwalacze i zapisy po jednej stronie, osąd po drugiej.
Praktyczna wskazówka projektowa: granicę między warstwami przeprowadź tam, gdzie kończy się przewidywalność. Wszystko, co da się narysować, zostaw narysowane — bo to jest tańsze, szybsze i łatwiejsze w utrzymaniu. Krawędź rozstrzyganą w trakcie zostaw dla tego fragmentu, którego narysować się nie da.
Co dalej
Krawędzie już są, węzły też. Zostaje to, co po nich płynie — i tu graf ma problem, którego pętla nie miała: kilku wykonawców czyta i zapisuje to samo, a niektórzy mogą sięgnąć po to samo zadanie w tej samej chwili.
O tym jest artykuł piąty: Stan między węzłami.
Stan na sierpień 2026. Opis mechanizmów obu narzędzi na podstawie ich publicznej dokumentacji; szczegółowe porównanie wraz z zastrzeżeniami znajduje się w osobnym tekście.
