Granica nie leży tam, gdzie zadanie robi się trudne. Leży tam, gdzie jedna historia przestaje mieścić całą pracę.
Najczęstsza odpowiedź na pytanie „kiedy potrzebuję kilku agentów” brzmi: gdy zadanie jest skomplikowane. Jest fałszywa i kosztowna.
Skomplikowane zadania prowadzi się jedną pętlą i zwykle wychodzi to taniej, szybciej i łatwiej w debugowaniu. Agent, który wykonuje dwadzieścia kroków, sprawdza pięć źródeł i podejmuje po drodze kilkanaście decyzji, jest wciąż jedną pętlą. Nic w nim nie woła o graf.
Granica leży gdzie indziej i da się ją wskazać dokładnie.
Trzy warunki, nie jeden
Graf wykonania zaczyna mieć sens dopiero wtedy, gdy spełnione są wszystkie trzy poniższe. Nie „któryś z nich” — wszystkie.
Praca trwa dłużej niż jeden przebieg. Nie chodzi o liczbę kroków, tylko o to, czy między nimi coś się kończy. Jeśli zadanie zaczyna się rano, czeka na cudzą odpowiedź i wraca po południu — nie mieści się w jednym uruchomieniu pętli. Pętla nie umie czekać: kończy się albo trwa, kosztując przez cały ten czas.
Wymaga więcej niż jednej roli. Rola to nie to samo co krok. Kroki wykonuje jedna pętla po kolei. Rola oznacza inny mandat: co wolno, do czego jest dostęp, kto odpowiada za wynik. Jeśli ten sam wykonawca z tym samym zestawem uprawnień robi wszystko, nie masz ról, tylko listę zadań.
Potrzebujesz budżetu i śladu audytowego. To brzmi jak wymaganie korporacyjne, a jest wymaganiem technicznym. Przy jednej pętli koszt widzisz na końcu i możesz ją zabić w każdej chwili. Przy kilku niezależnych wykonawcach, z których każdy może się obudzić sam, potrzebujesz mechanizmu, który powie „nie” przed uruchomieniem, i zapisu, który pozwoli odtworzyć, kto co zrobił.
Jeśli na którykolwiek z tych trzech warunków odpowiadasz „nie”, prawdopodobnie wystarczy pojedynczy agent — czasem nawet bez orkiestratora.
Dlaczego akurat te trzy
Bo każdy z nich jest miejscem, w którym pętla ma strukturalne ograniczenie, a nie tylko niewygodę.
Pętla jest epizodyczna. Odpala się, wykonuje, kończy. Stan znika, chyba że sam zadbasz o jego zapisanie — a wtedy budujesz maszynę stanów na bazie danych i wyzwalaczach czasowych, czyli piszesz sobie graf, tylko bez nazwy.
Pętla jest jednorodna. Ma jeden zestaw narzędzi, jedną konfigurację, jedno środowisko. Możesz w prompcie napisać, że teraz zachowuje się jak recenzent — ale to nadal ten sam proces z tymi samymi uprawnieniami. Instrukcja „nie sięgaj do produkcji” jest życzeniem, nie granicą.
Pętla jest pojedyncza. Nie konkuruje o pracę sama ze sobą, więc nie potrzebuje rozstrzygania, kto pierwszy wziął zadanie. W momencie, gdy niezależnych wykonawców jest dwóch, pojawia się problem, którego wcześniej nie było.
Zauważ, co z tego wynika: graf nie jest ulepszeniem pętli, tylko odpowiedzią na inne pytanie. Pętla pyta, czy ten wykonawca ma kontynuować. Graf pyta, który wykonawca zadziała następnie, z jakim stanem i pod jakimi warunkami. Pierwsze to iteracja lokalna. Drugie to koordynacja.
Czego graf nie naprawia
To jest część, którą większość materiałów o wieloagentowości pomija, a jest najważniejsza przy podejmowaniu decyzji.
Graf składa się z pętli. Każdy węzeł, który wykonuje jakąkolwiek pracę wymagającą osądu, prowadzi własną pętlę — z tymi samymi problemami, które opisuje główna seria: kwadratowym kosztem kontekstu, warunkami zakończenia, obsługą zawodzącego narzędzia.
Jeśli twoja pętla gubi wątek po piętnastu krokach, trzy takie pętle zestawione w graf będą gubić wątek w trzech miejscach naraz — i dodatkowo w miejscach styku. Graf zawodnych pętli to schemat organizacyjny zawodnych pracowników.
Praktyczny wniosek: jeśli rozważasz graf, bo pojedynczy agent działa niestabilnie, to jest zły powód. Najpierw ustabilizuj pętlę. Graf rozwiązuje problemy koordynacji, nie problemy jakości.
Trzy sytuacje z pogranicza
„Mam cztery różne zadania, więc potrzebuję czterech agentów.” Zwykle nie. Cztery niezależne zadania to cztery uruchomienia tej samej pętli z różnym wejściem. Graf jest potrzebny, gdy zadania muszą się między sobą dogadać — przekazać wynik, poczekać na siebie, rozstrzygnąć konflikt.
„Chcę, żeby jeden agent sprawdzał pracę drugiego.” To jest realny przypadek i najczęstszy sensowny powód sięgnięcia po graf. Ale sprawdź najpierw wariant tańszy: ten sam agent, drugie wywołanie, z innym promptem systemowym i bez dostępu do historii pierwszego. Jeśli weryfikacja wymaga innych uprawnień albo innego modelu — wtedy tak, to osobny węzeł.
„Proces trwa trzy dni, bo czeka na akceptację klienta.” Warunek pierwszy spełniony, ale sprawdź pozostałe. Jeśli poza czekaniem wszystko robi jeden wykonawca, wystarczy pętla plus kolejka — zadanie zapisane, wznowione wyzwalaczem. Graf potrzebujesz, gdy po akceptacji pracę przejmuje ktoś inny niż przed nią.
Jak sprawdzić u siebie
Weź konkretny proces, który rozważasz, i wypełnij trzy wiersze. Bez pisania kodu.
| Warunek | Twoja odpowiedź |
|---|---|
| Czy praca przerywa się i wraca później? | |
| Czy wykonawcy różnią się uprawnieniami albo dostępem? | |
| Czy potrzebujesz zatrzymać wykonanie przed przekroczeniem budżetu? |
Trzy razy „tak” — czytaj dalej ten tor. Dwa — prawdopodobnie wystarczy pętla z kolejką i zapisanym stanem. Jedno lub zero — zostań przy pętli i wróć tu, gdy coś się zmieni.
I zapisz odpowiedzi, nawet jeśli wyszło „nie”. Za pół roku, gdy proces urośnie, będziesz wiedział, który warunek zmienił się pierwszy — a to jest dokładnie moment, w którym warto wrócić do tej decyzji.
Co dalej
Jeśli trzy razy padło „tak”, zostaje pytanie, z czego taki graf się właściwie składa. Odpowiedź „z agentów” jest niepełna i myląca — bo węzłem bywa też zwykła funkcja, router, złączenie i punkt zatrzymania na decyzję człowieka.
O tym jest artykuł trzeci: Węzeł, krawędź, stan — z czego składa się graf wykonania.
Stan na sierpień 2026. Warunki opisane wyżej są uogólnieniem z praktyki i z dokumentacji narzędzi orkiestrujących, nie ustaloną normą — traktuj je jako punkt wyjścia do własnej decyzji, nie jako regułę.
