Za elastyczność płacisz przewidywalnością, policzalnym kosztem i łatwością debugowania. Jeśli proces dało się narysować, płacisz za nic.
Dziewięć poprzednich artykułów opisywało, jak zbudować graf wykonania i czego przy tym pilnować. Ten jest o tym, kiedy nie budować go wcale — i jest napisany na końcu celowo, bo dopiero po przejściu przez stan współdzielony, awarie węzłów, granice uprawnień i logowanie widać, ile to naprawdę kosztuje.
Wniosek, który z tego wychodzi, jest prosty i niewygodny: większość procesów, które nazywamy dziś agentem AI, to deterministyczne przepływy z krokiem LLM w środku. Te nie potrzebują grafu wykonania. Potrzebują pętli albo schematu.
Co dokładnie płacisz
Nie „złożoność” w ogólnym sensie. Pięć konkretnych rzeczy.
Przewidywalność wyniku. Dwa uruchomienia tego samego zadania mogą pójść inną trasą i oba mogą być poprawne. To zmienia sens testowania: nie sprawdzasz ścieżki, tylko czy wynik spełnia kryteria — inna dyscyplina i inne narzędzia.
Policzalny koszt. Graf przepływu wycenisz przed uruchomieniem: tyle węzłów, tyle wywołań, tyle tokenów. Graf wykonania ma koszt zmienny z założenia, a każdy węzeł płaci własny kwadratowy rachunek za swój wycinek stanu.
Łatwość debugowania. Ścieżka nie jest narysowana, więc odtwarzasz ją z logu — który musisz najpierw zbudować tak, żeby dało się z niego cokolwiek odtworzyć. To jest praca, której przy jednym schemacie nie ma.
Powierzchnia awarii. Zakleszczenia, konflikty zapisu, zadania zajęte przez nieistniejących wykonawców, złączenia czekające na wejście, którego nikt nie wyprodukuje. Cała klasa problemów, która w pojedynczej pętli nie istnieje.
Powierzchnia ataku. Więcej procesów, więcej uprawnień do rozdania, panel orkiestracji z uprawnieniami administracyjnymi. Każdy z tych elementów jest czymś, czego wcześniej nie było.
Pięć sytuacji, w których graf jest złą odpowiedzią
Proces da się narysować. Jeśli potrafisz rozpisać go w całości, ze wszystkimi rozgałęzieniami, to autonomia w wyborze trasy jest kosztem bez korzyści. Wstaw agenta tam, gdzie potrzeba osądu, i zostaw resztę jako schemat.
Pojedynczy agent działa niestabilnie. To jest najczęstszy zły powód. Graf składa się z pętli i nie naprawia żadnej z nich — trzy niestabilne pętle będą się rozjeżdżać w trzech miejscach naraz, plus w miejscach styku. Najpierw ustabilizuj pętlę.
Zadań jest dużo, ale są niezależne. Cztery zadania to cztery uruchomienia tej samej pętli z różnym wejściem, nie cztery węzły. Graf potrzebny jest wtedy, gdy zadania muszą się między sobą dogadać.
Chcesz weryfikatora i tyle. Sprawdź najpierw wariant tańszy: ten sam agent, drugie wywołanie, inny prompt systemowy, bez dostępu do historii pierwszego. Osobny węzeł uzasadniają dopiero inne uprawnienia albo inny model.
Nie masz kto tego utrzyma. Graf wymaga rozumienia stanu współdzielonego, kolejek i idempotentności. To są kompetencje z systemów rozproszonych, nie z pracy z modelami — i jeśli w zespole nikt ich nie ma, dług narasta szybciej niż korzyść.
Trzy koszty, o których dowiadujesz się później
Warto je wymienić osobno, bo nie widać ich przy podejmowaniu decyzji.
Debug wymaga logu, który trzeba było zaprojektować wcześniej. Pierwsza niewyjaśniona trasa przychodzi zwykle w trzecim tygodniu, kiedy logowanie rozstrzygnięć krawędzi już powinno działać, a nie dopiero zaczynać powstawać.
Zmiana modelu zmienia trasę, nie tylko jakość kroku. W schemacie podmiana modelu wpływa na jeden węzeł. W grafie wykonania model współdecyduje o krawędziach, więc zmienia też, którędy graf pójdzie. To jest jeden z powodów, dla których coś, co działało wczoraj, dziś działa inaczej mimo braku zmian w kodzie.
Uwaga człowieka wyczerpuje się szybciej, niż zakładałeś. Węzeł zatwierdzenia postawiony w kilku miejscach naraz produkuje tyle próśb, że po dwóch tygodniach nikt ich nie czyta — i formalny nadzór zamienia się w zeszklone zatwierdzanie, którego nie widać w żadnej metryce poza odsetkiem odmów.
Co zrobić zamiast
Cztery rozwiązania pośrednie, w kolejności od najprostszego. Warto przejść je po kolei, zanim sięgniesz po graf.
Pętla z lepszymi narzędziami. Bardzo często to, co wygląda na potrzebę podziału ról, jest potrzebą lepszej definicji narzędzia albo ograniczenia ich liczby.
Pętla z kolejką. Rozwiązuje warunek pierwszy — pracę przerywaną. Zadanie zapisane, wznowione wyzwalaczem, stan w bazie. To jest znacznie mniej niż graf i wystarcza w większości przypadków, w których praca trwa dłużej niż jeden przebieg.
Schemat z jednym węzłem agentowym. Rozwiązuje większość przypadków, w których droga jest znana, a jeden krok wymaga osądu. Tania, przewidywalna, łatwa w utrzymaniu.
Dwie warstwy zamiast jednej. Deterministyczna obsługuje zdarzenia, integracje i zapisy. Decyzyjna to, co wymaga osądu. Granicę przeprowadź tam, gdzie kończy się przewidywalność — wszystko, co da się narysować, zostaw narysowane.
Test przed decyzją
Cztery pytania. Wszystkie muszą wyjść na „tak”, żeby graf się bronił.
Czy proces przerywa się i wraca później?
Czy wykonawcy różnią się uprawnieniami albo dostępem?
Czy potrzebujesz zatrzymać wykonanie przed przekroczeniem budżetu?
Czy jest kto to utrzyma za pół roku?
Pierwsze trzy sprawdzają, czy problem pasuje do rozwiązania. Czwarte sprawdza, czy rozwiązanie pasuje do ciebie — i jest tym, które najczęściej rozstrzyga, mimo że najrzadziej pada.
Na koniec toru
Dziesięć artykułów o czymś, co przez większość czasu nie jest ci potrzebne. To nie jest paradoks — to jest sens tego toru.
Inżynieria grafów dostała nazwę w lipcu 2026 i przez chwilę wyglądała jak następny konieczny krok po pętli. Nie jest. Jest odpowiedzią na konkretny zestaw problemów, który pojawia się rzadziej, niż sugeruje liczba tekstów na ten temat, a mechanizmy, które za nią stoją, pochodzą z systemów kolejkowych i rozproszonych sprzed dekad.
Wartość znajomości tych mechanizmów jest jednak realna i niezależna od tego, czy kiedykolwiek zbudujesz graf. Bo pytania, które graf zmusza cię zadać — kto jest właścicielem tego pola, co się dzieje przy awarii, gdzie stoi granica, skąd wiadomo, co się wydarzyło — są dobrymi pytaniami także o pojedynczą pętlę. Tam po prostu łatwiej je pominąć.
Jeśli po przejściu tego toru wracasz do jednej pętli, ale wiesz, kto zapisuje który kawałek stanu i co się stanie, gdy narzędzie nie odpowie — tor zrobił swoje.
Stan na sierpień 2026. Tor opisuje mechanizmy niezależne od narzędzi; konkretne rozwiązania orkiestrujące zmieniają się co kwartał, a część problemów opisanych wyżej jest w nich rozwiązana domyślnie, część nie. Warto sprawdzić, zanim założysz jedno albo drugie.
