Orkiestracja agentów AI: kiedy jeden agent nie wystarczy

Zarząd dużej sieci handlowej z kilkudziesięcioma punktami podjął decyzję, która miała przyspieszyć sprzedaż. Kierownicy punktów dostali większą swobodę w negocjowaniu warunków umów z klientami, a dział prawny przestał zatwierdzać każdą z nich. Sprzedaż faktycznie ruszyła. Po kilku miesiącach ruszyło też coś innego. Problemy z realizacją kontraktów, więcej reklamacji, spory o terminy i kary. Na posiedzeniu zarządu padło pytanie, które brzmiało niewinnie. "Czy nasze umowy nie odbiegają zbyt daleko od wytycznych firmy?" Kilkanaście tysięcy umów, z których znaczna część była negocjowana indywidualnie, i dział prawny, który potrzebowałby na ich przeczytanie miesięcy.

Jeden agent AI tego nie zrobi, i nie dlatego, że jest za głupi. Zrobił to system kilkunastu agentów z nadzorcą, bramką w kodzie, głosowaniem i sędzią. Opisujemy go w połowie tego artykułu, bo żeby go zrozumieć, trzeba najpierw wiedzieć, czym jest orkiestracja agentów AI, kiedy jest potrzebna, a kiedy tylko podnosi rachunek, i z jakich wzorców się składa. Przejdziemy przez to na przykładzie prostszej firmy, producenta mebli na wymiar, od pierwszego maila klienta po reklamację. Potem wrócimy do sieci handlowej i jej umów, pokażemy, co się w takich systemach psuje i kto tego pilnuje, co mówią dane o opłacalności, a na końcu opiszemy własny orkiestrator, w którym agent nadzoruje maszynę zarządzającą innymi agentami, bo to najuczciwszy dowód, jaki mamy.

Rynek nazywa to różnie. Mówi o systemie wieloagentowym (multi-agent systemMulti-agent systemSystem, w którym kilka agentów opartych na modelach językowych pracuje nad jednym zadaniem. Każdy ma własny kontekst, własne narzędzia i własną rolę, a wynik składa agent prowadzący albo kod.), o rojach agentów, o rojach botów, o systemach agentowych i o subagentach, a sprzedawcy dorzucają do tego słowo "orkiestracja" przy każdej okazji. Ten tekst jest kontynuacją artykułu Agent AI, asystent czy chatbot?, w którym ułożyliśmy drabinkę od jednego wywołania modelu, przez przepływ narysowany przez człowieka, po agenta w pętli. Tam drabinka kończyła się na roju. Tu zaczynamy od tego szczebla.

Co to jest orkiestracja agentów AI i po co ją robić

System wieloagentowy w kilku zdaniach

Orkiestracja agentów AI to sposób organizacji pracy, w którym zadanie jest dzielone między kilka agentów opartych na modelach językowych, każdy pracuje w osobnym kontekście z własnymi narzędziami i uprawnieniami, a ktoś, kod albo agent prowadzący, pilnuje kolejności, składa wyniki i sprawdza, czy praca jest skończona. Taki układ nazywa się systemem wieloagentowym, po angielsku multi-agent system, a potocznie rojem agentów. Orkiestracja to nie sam fakt, że agentów jest kilka. Orkiestracja to to, co dzieje się między nimi, czyli podział pracy, komunikacja, kontrola i scalanie.

Najprostsza analogia to biuro, w którym kierowniczka zna klienta, dzieli paczkę umów między trzech asystentów, każdy czyta swoją część, a ona odbiera notatki, sprawdza je i pisze odpowiedź. Asystenci nie muszą znać całej historii klienta. Kierowniczka nie musi czytać wszystkich umów. Każdy ma tyle kontekstu, ile potrzebuje do swojej części, i tyle uprawnień, ile ta część wymaga. W świecie agentów to samo robi agent prowadzący z agentami roboczymi, a cała sztuka orkiestracji polega na tym, żeby ten podział był świadomy.

Najpierw jeden agent

Najciekawsza rzecz w dokumentacji narzędzi do orkiestracji jest taka, że każda zaczyna od odradzania orkiestracji. OpenAI w poradniku budowy agentów pisze, że ich ogólna rekomendacja to "najpierw zmaksymalizować możliwości jednego agenta", a dzielić system dopiero wtedy, gdy agent przestaje wykonywać skomplikowane instrukcje albo uparcie wybiera złe narzędzia. Microsoft w dokumentacji Agent Framework stawia regułę jeszcze ostrzej. "Jeśli możesz napisać funkcję, która załatwi zadanie, zrób to zamiast używać agenta AI." Anthropic w tekście o budowie skutecznych agentów radzi "znaleźć najprostsze możliwe rozwiązanie i zwiększać złożoność tylko wtedy, gdy to konieczne", a w dokumentacji Copilot Studio Microsoft dopisuje, że orkiestracja wielu agentów "może być potężna, ale nie zawsze jest potrzebna". Rzadko zdarza się, żeby instrukcja obsługi odradzała zakup, a nasze doświadczenie z pracy z rojami mówi to samo.

Powód jest prosty. Każdy dodatkowy agent to dodatkowe wywołania modelu, dodatkowe miejsce, w którym informacja może zginąć w przekazie, i dodatkowy rachunek. Jeden agent z dobrze opisanymi narzędziami i porządnym kontekstem załatwia w firmie więcej, niż się wydaje. Weźmy naszego producenta mebli. Od wiosny ma agenta, który sortuje maile klientów i odpowiada na pytania o status zamówienia. Każdy mail trafia do modelu osobno, z tym samym promptem i tymi samymi zasadami, więc przy każdej wiadomości agent zaczyna z czystą pamięcią. Działa w chmurze, jest podpięty do skrzynki, ma zabezpieczenia, które nie pozwalają mu wysłać niczego poza ustalonym wzorem, i jest dostrojony do jednej roboty. W poniedziałek główny dostawca płyt przysyła paczkę. Sto czterdzieści umów, nowy regulamin rozliczeń i pytanie, które umowy trzeba aneksować przed końcem roku i ile to będzie kosztować.

Pierwszy odruch to wrzucić paczkę agentowi od maili. To zły pomysł. Został zbudowany i zabezpieczony do innej pracy, a analiza paczki umów to wiele kroków, czytanie, porównywanie z regulaminem, liczenie i sprawdzanie, z których każdy wymaga innej kontroli. Przerobienie agenta mailowego pod nowe zadanie oznacza zmianę promptu, narzędzi i zabezpieczeń, a każda taka zmiana może zepsuć to, co dziś działa dobrze. Agent obsługujący skrzynkę to zresztą zwykle konfiguracja chmury, integracji i uprawnień, której nie rusza się bez potrzeby. Bardziej opłaca się uruchomić na komputerze elastycznego agenta ogólnego przeznaczenia, na przykład Claude Code albo Codex, przejść z nim jedną czy dwie umowy, pokazać, czego szukać i jak ma wyglądać wynik, a potem zlecić mu całość. Taki agent lokalny nie potrzebuje chmury ani skrzynki. Uruchamia się, robi swoje i kończy. Zanim pomyślisz o roju, sprawdź, czy nie wystarczy lepszy prompt albo dobrze poinstruowany agent ogólnego przeznaczenia.

I tu zaczyna się temat tego artykułu. Sto czterdzieści umów to za dużo, żeby jeden agent czytał je w jednej sesji, bo każda przeczytana umowa zostaje w jego kontekście, a po kilkudziesięciu robi się tłoczno i agent zaczyna mylić dostawców. Agent prowadzący, który zna regulamin i cel, rozdziela więc paczkę między pomocników. Każdy dostaje kilka umów, instrukcję wypracowaną na pierwszych dwóch przykładach i tylko narzędzie do czytania plików. Wracają krótkie notatki, prowadzący je sprawdza i składa raport. Producenci podają też praktyczne progi, przy których jeden agent przestaje wystarczać. Microsoft pisze, że jakość wyboru narzędzi spada, gdy główny agent ma do wyboru więcej niż trzydzieści do czterdziestu akcji, licząc narzędzia, tematy i innych agentów. OpenAI dodaje, że problemem nie jest sama liczba narzędzi, tylko ich podobieństwo, bo niektóre wdrożenia radzą sobie z piętnastoma dobrze rozróżnionymi narzędziami, a inne gubią się przy mniej niż dziesięciu nakładających się na siebie. Zapier radzi, żeby jeden agent główny wywoływał mniej niż pięciu innych agentów. Dokumentacja Claude Code mówi, żeby zespół agentów zaczynać od trzech do pięciu członków, i dodaje zdanie, które warto zapamiętać. "Trzech skupionych członków zespołu często wypada lepiej niż pięciu rozproszonych."

Cztery powody, żeby zorkiestrować pracę

Skoro jeden agent załatwia tak wiele, po co w ogóle orkiestrować? Powody, dla których sięgamy po kilku agentów, wynikają z tego, czego chcesz od procesu, a nie z tego, że model jest za słaby. Są cztery i w praktyce zwykle występują razem.

Wszystkie cztery powody łączy jedno. Orkiestracja daje elastyczność, która pozostaje powtarzalna, bo procedurę, nawet z głosowaniem i kilkoma modelami, można zaprogramować, czyli właśnie zorkiestrować. Można też pójść w drugą stronę i puścić agentów samopas, licząc na dobry wynik. Tak pracuje się czasem w badaniach i bywa to owocne, ale na powtarzalność trudno wtedy liczyć.

Cztery powody, żeby zorkiestrować pracę agentów

Jakość, czas, procedura i kontekst. Rzadko chodzi o to, że model jest za słaby

Słownik: pięć rzeczy, które nazywa się orkiestracją

Zanim pójdziemy dalej, musimy posprzątać słownik, bo pod hasłami "orkiestracja AI" i "system wieloagentowy" w wyszukiwarce kryje się pięć różnych rzeczy. Pierwsza to klasyczne systemy wieloagentowe z informatyki, badane od lat osiemdziesiątych w robotyce, symulacjach i teorii gier. Polska Wikipedia pod hasłem "system wieloagentowy" opisuje właśnie je i nie wspomina o modelach językowych, a na tę frazę wychodzą sylabusy i prace z politechnik. Druga to orkiestracja kontenerów, czyli Kubernetes i Docker Swarm, która z agentami AI nie ma nic wspólnego poza słowem "rój" w nazwie, choć zdarza się blogom wrzucić ją do jednego worka z agentami. Trzecia to orkiestracja robotów RPA, czyli zarządzanie botami, które klikają po ekranach według sztywnych reguł. Czwarta to orkiestracja modeli, czyli dobieranie tańszego albo droższego modelu do każdego kroku, i o niej też napiszemy, bo w praktyce zawsze idzie w parze z orkiestracją agentów. Piąta to ta, o której jest ten artykuł, czyli koordynacja wielu agentów opartych na modelach językowych, pracujących nad jednym zadaniem w firmie.

Orkiestracja ma pięć znaczeń, ten artykuł dotyczy jednego

To samo słowo opisuje pięć różnych rzeczy. Wyszukiwarka je miesza, oferty też

Jest jeszcze szóste znaczenie, które pojawia się w ogłoszeniach o pracę. "AI Orchestrator" bywa stanowiskiem dla człowieka, który zarządza zespołem cyfrowych agentów. To nie jest oprogramowanie, choć w tym artykule zobaczysz, że granica między człowiekiem na tym stanowisku a agentem, który je zajmuje, robi się cienka.

Jedna firma, osiem etapów: wzorce orkiestracji od maila do reklamacji

W artykule o chatbotach i agentach oparliśmy wszystko na jednym rozróżnieniu z tekstu Anthropic. Przepływ pracy (workflowWorkflowPrzepływ, w którym kolejność kroków jest zapisana z góry w kodzie albo na diagramie. Model wypełnia luki, ale o następnym kroku decyduje autor ścieżki, nie model.) to system, w którym "modele i narzędzia są orkiestrowane przez z góry zdefiniowane ścieżki kodu", a agent to system, w którym "modele dynamicznie kierują własnymi procesami i użyciem narzędzi". To samo rozróżnienie działa piętro wyżej. Orkiestracja też może być zapisana w kodzie, gdy człowiek z góry ustala, który agent po którym, albo może być dynamiczna, gdy agent prowadzący sam decyduje, kogo powołać i co mu zlecić. Pierwsza jest przewidywalna, tania i łatwa do przetestowania. Druga jest elastyczna i radzi sobie z zadaniami, których nie dało się rozpisać z góry. Większość prawdziwych wdrożeń miesza obie, bo kod trzyma szkielet, a model wypełnia go decyzjami. Figura poniżej pokazuje to na naszym producencie mebli. Prowadzi klienta przez osiem etapów, od pierwszego maila po reklamację, a na każdym etapie pracuje inny układ agentów. Wzorce, które w dokumentacjach występują pod różnymi nazwami, omawiamy poniżej w kolejności od najprostszego, za każdym razem wskazując etap, na którym go widać.

Od maila do reklamacji: orkiestracja agentów w jednej firmie

Producent mebli na wymiar prowadzi klienta przez osiem etapów. Na każdym pracuje inny układ agentów, od jednego wywołania modelu po loop z nadzorcą. Aktywny etap: 1. Zapytanie

1. Zapytanie 2. Potrzeby 3. Oferta 4. Umowa 5. Realizacja 6. Produkcja 7. Wydanie 8. Posprzedaż

Dwa pierwsze etapy: zanim zacznie się orkiestracja

Pierwsze dwa etapy to szczeble z poprzedniego artykułu, jeszcze bez roju. Zapytanie mailem sortuje klasyfikator, czyli jedno wywołanie modelu z tym samym promptem dla każdej wiadomości. Nowe zapytanie trafia do systemu sprzedaży, reklamacja do swojej kolejki, faktura do księgowości, a kontekst za każdym razem zaczyna się od zera. Analizę potrzeb prowadzi już agent w pętli. Dopytuje klienta o wymiary, styl, budżet i termin, sprawdza katalog i konfigurator, liczy dostępność i oddaje profil potrzeb z dobranymi parametrami produktu. Jeden agent, własne narzędzia, limit tur. Orkiestracja zaczyna się dopiero wtedy, gdy ten profil trafia do etapu oferty i jeden agent przestaje wystarczać.

Potok: zamówienie przechodzi przez kolejne stanowiska

Najprostszy wzorzec to potok, czyli łańcuch wywołań (prompt chainingPrompt chainingZadanie podzielone na stałe kroki, w których każde wywołanie modelu przetwarza wynik poprzedniego. Kolejność ustala człowiek, a między krokami można wstawić sprawdzenie w kodzie.). Na figurze widać go na etapie przygotowania produkcji. Pierwszy krok przygotowuje dane na produkcję, drugi sprawdza dostępność materiałów w magazynie, trzeci składa zamówienia wewnętrzne na brakujące komponenty, czwarty pisze wytyczne dla działu projektowego. Każdy krok dostaje wynik poprzednika i nic więcej. Google nazywa to linią montażową, w której "agent A kończy zadanie i przekazuje pałeczkę agentowi B", Microsoft ma na to wzorzec sequential, a w n8n albo Make jest to po prostu kilka węzłów agentowych połączonych strzałkami. Potok płaci opóźnieniem za trafność, bo każdy krok czeka na poprzedni, ale w zamian między krokami można wstawić sprawdzenie w kodzie, na przykład czy każda pozycja zamówienia ma przypisany rysunek, zanim trafi na produkcję.

Prowadzący i pomocnicy: oferta skrojona pod klienta

Drugi wzorzec to ten, który widzieliśmy przy stu czterdziestu umowach dostawcy. Agent prowadzący dzieli zadanie, deleguje części pomocnikom i składa wyniki. Na figurze to etap oferty. Prowadzący dostaje profil potrzeb i powołuje trzech pomocników. Jeden uzupełnia z systemów firmy dane klienta i warunki ustalone przez handlowca, drugi pisze treść oferty językiem klienta i z naciskiem na to, co dla niego ważne, trzeci przygotowuje wizualizacje dopasowane do jego gustu. Nad nimi stoi agent nadzorujący warunki, który sprawdza, czy nikt nie obiecał czegoś, czego handlowiec nie ustalił. Klient dostaje ofertę skrojoną pod siebie, nie tylko w parametrach, ale też w tekście i w wyglądzie. Ten wzorzec rozkładamy na części w dużym przykładzie z umowami, bo tam pracuje w pełnej skali.

Zapytać specjalistę czy oddać mu klienta

Kolejny wzorzec nie dotyczy tego, kto dzieli pracę, tylko tego, kto trzyma ster, i to jest podział, który najczęściej umyka w opisach. Prowadzący może wywołać specjalistę jak narzędzie (agents as toolsAgents as toolsUkład, w którym agent główny wywołuje innego agenta jak funkcję, dostaje z powrotem jego wynik i sam dalej prowadzi rozmowę. Agent główny nie traci kontroli, a specjalista nie widzi całej historii.). Zadaje mu pytanie, dostaje odpowiedź i sam decyduje, co dalej. Klient przez cały czas rozmawia z tym samym agentem. Alternatywą jest przekazanie rozmowy (handoffHandoffJednokierunkowe przekazanie całej rozmowy innemu agentowi, który od tej chwili staje się aktywnym agentem i sam odpowiada użytkownikowi. Używane na infoliniach i w systemach z wieloma działami.), w którym specjalista przejmuje całą rozmowę i od tej chwili to on odpowiada. OpenAI opisuje to na przykładzie infolinii, gdzie agent przyjmujący zgłoszenie przekazuje klienta do agenta sprzedaży, zamówień albo reklamacji, a ten "staje się aktywnym agentem na resztę tury". Microsoft ma na to wzorzec handoff, Google transfer. Pierwszy układ oszczędza kontekst szefa i utrzymuje jeden ton rozmowy. Drugi pozwala specjaliście pracować z pełną historią i własnymi uprawnieniami, ale klient może poczuć, że rozmawia z kimś innym. Na figurze przekazanie rozmowy widać trzy razy. W realizacji agent projektu, który odpowiada klientowi z bazy wiedzy firmy, oddaje pomysł na roboty dodatkowe handlowcowi. Przy wydaniu powiadomienie z magazynu zaprasza klienta do agenta dostaw, który przejmuje rozmowę o terminie i montażu. W obsłudze posprzedażnej agent przyjmujący rozpoznaje sprawę i oddaje ją specjaliście od reklamacji, serwisu albo części. W firmach obie rzeczy się łączy. Agent przyjmujący zgłoszenie przekazuje sprawę do działu, a agent działu wywołuje specjalistów jak narzędzia.

Kto trzyma ster: agent jako narzędzie i przekazanie rozmowy

Ten sam specjalista, dwa sposoby włączenia go do rozmowy. W pierwszym wraca streszczenie, w drugim wraca cała rozmowa

Narada przy tablicy

Następny wzorzec to rozmowa kilku agentów na jednym kanale, którą Microsoft nazywa group chat, a w wersji z menedżerem planującym pracę Magentic. Jego pierwowzór, system Magentic-One z 2024 roku, prowadził dwie księgi. Księga zadania zawierała "fakty, przypuszczenia i plan", a księga postępu zapisywała, co już zrobiono i kto nad czym pracuje. Menedżer wybierał, kto ma mówić następny, a gdy praca stawała w miejscu, układał plan od nowa. Na figurze to etap umowy. Agent prawny, agent finansowy i agent grający adwokata diabła dyskutują nad projektem umowy i uwagami klienta, moderator prowadzi tablicę ryzyk, a każda uwaga kończy się jednym z trzech werdyktów, przyjęta, złagodzona nowym zapisem albo odrzucona z uzasadnieniem. Decyzję zatwierdza handlowiec. Trzeba jednak uczciwie dodać, że badania nad debatą agentów studzą zapał. Kilka prac z lat 2024 i 2025 pokazało, że debata zwykle nie bije prostszych metod, w których jeden model odpowiada kilka razy i głosuje, a Microsoft w dokumentacji Magentic sam pisze, że "nie zbadano, jak dobrze ta orkiestracja działa poza pierwotnym projektem". Narada jest cennym wzorcem wtedy, gdy agenci mają naprawdę różne role i różne dane, a nie wtedy, gdy ten sam model udaje trzech ekspertów.

Sieć, rój i hierarchia

Jest też wzorzec bez stałej centrali, w którym każdy agent może oddać pałeczkę każdemu. Dokumentacja LangGraph nazywa to swarm, OpenAI w swoim starym, eksperymentalnym frameworku o tej samej nazwie oparło na tym cały pomysł, a dziś mówi o wzorcu zdecentralizowanym. To właśnie stąd rynek wziął określenia "roje agentów" i "roje botów", choć w praktyce używa ich dziś dla każdego systemu wieloagentowego, także z prowadzącym. Czysty rój bez centrali jest najtrudniejszy do kontrolowania, bo nie ma miejsca, w którym ktoś widzi całość, i najłatwiej w nim o pętlę bez końca, gdy dwaj agenci odbijają sobie zadanie w nieskończoność. Dlatego w tym artykule, gdy piszemy "rój", mamy na myśli system wieloagentowy w ogóle, a tam, gdzie chodzi o sieć bez centrali, piszemy to wprost.

Ostatni wzorzec w dokumentacjach pojawia się najrzadziej, a w firmach najczęściej. To hierarchia, czyli szef szefów. Koordynator konta klienta ma pod sobą zespół sprzedaży i zespół wsparcia, a każdy zespół ma własnego agenta prowadzącego. Na figurze widać ją na etapie produkcji, gdzie nad potokiem punktów stoi agent nadzorujący przebieg. Claude Agent SDK pozwala domyślnie na trzy poziomy takiego zagnieżdżenia, n8n pozwala "zagnieżdżać węzły agentów w wiele warstw", a nasz własny orkiestrator, o którym piszemy w dalszej części, buduje drzewo przebiegów na kilku maszynach.

Wszystkie wzorce naraz: kilkanaście tysięcy umów pod lupą zarządu

Wróćmy do sieci handlowej z początku artykułu. Każdy z kilkudziesięciu punktów miał po kilkaset umów, a znaczna część z nich była negocjowana indywidualnie, więc do sprawdzenia zostało kilkanaście tysięcy dokumentów. Ręczna analiza w dziale prawnym pochłonęłaby ogromną liczbę roboczogodzin drogich prawników. Zbudowaliśmy więc narzędzie, które robi to automatycznie, a prawnikom zostawia tylko sprawy naprawdę wątpliwe. Składa się z wzorców, które już znasz, tylko ułożonych w jeden system.

Na górze pracuje jeden agent nadzorujący w pętli. To wzorzec prowadzącego z pomocnikami, ten sam co przy ofercie producenta mebli, tylko w znacznie większej skali. Anthropic nazywa go orkiestrator z wykonawcami (orchestrator-workersOrchestrator-workersWzorzec, w którym centralny model dzieli zadanie na części, deleguje je modelom roboczym i syntetyzuje ich wyniki. Od zwykłej równoległości różni się tym, że podziału nie da się przewidzieć z góry, decyduje model.) i opisuje jako układ, w którym "centralny model dynamicznie rozbija zadanie, deleguje je modelom roboczym i syntetyzuje ich wyniki". W dokumentacji LangChain ten sam układ nazywa się supervisor, w OpenAI manager, w CrewAI proces hierarchiczny, a w Microsoft Agent Framework Magentic. Agent nadzorujący dzieli zbiór umów na paczki, na przykład według punktu i rodzaju umowy, i dla każdej paczki układa zestaw kroków. Sam nie czyta umów. Pilnuje kolejności, limitów i postępu, a gdy któraś paczka utknie albo jej wyniki odstają od reszty, przydziela ją od nowa. Różnica wobec zwykłego podziału jest taka, że to nadzorca decyduje, na ile części podzielić zbiór i co komu zlecić, więc radzi sobie także z umowami, których nie dało się skategoryzować z góry.

Paczki czytają subagenci (subagentsSubagentsPomocnicy powoływani przez agenta prowadzącego do jednego zadania, z własnym oknem kontekstu i własnymi uprawnieniami. Po wykonaniu pracy oddają tylko podsumowanie i znikają.), czyli agenci powoływani na jedno zadanie, którzy pracują we własnym kontekście i oddają nadzorcy tylko streszczenie. Anthropic podaje, że taki pomocnik potrafi zużyć dziesiątki tysięcy tokenów na czytanie, a oddaje zwykle tysiąc do dwóch tysięcy tokenów notatki. Nadzorca nie zapycha więc sobie pamięci kilkunastoma tysiącami umów, tylko dostaje krótkie raporty z paczek. Paczki idą przy tym naraz, i to jest kolejny wzorzec, czyli równoległość (parallelizationParallelizationKilka wywołań modelu uruchomionych naraz, a wyniki zebrane w kodzie. Dwie odmiany: podział zadania na niezależne części albo kilkukrotne wykonanie tego samego zadania i głosowanie.). Ma dwie odmiany, a ten system korzysta z obu. Pierwsza to podział materiału na kawałki, z których każdy agent czyta swój, co Google nazywa fan-out i gather. Tak właśnie kilkanaście tysięcy umów rozchodzi się po paczkach i wraca jako jeden raport. Druga odmiana to kilkukrotne wykonanie tego samego zadania i głosowanie, o którym za chwilę.

Każdą umowę zespół subagentów przeprowadza przez te same etapy, czyli przez potok. Pierwszy agent analizuje intencję, czyli to, co strony naprawdę chciały ustalić i czym umowa różni się od wzoru. Drugi rozbija umowę na zapisy i tworzy listę punktów zgodnych z wytycznymi, niezgodnych i podejrzanych. Trzeci do każdego punktu niezgodnego przypisuje regułę albo grupę reguł zarządu, które ten zapis narusza, na przykład limit kar umownych, termin płatności albo zakres gwarancji. Czwarty przygotowuje rekomendację, czy umowę zostawić, aneksować, czy oddać prawnikowi.

Między etapami stoją kontrole, bez których taki system nie byłby wiarygodny. Pierwsza to suma kontrolna. Liczba punktów na listach musi się zgadzać z liczbą zapisów w umowie, więc żaden zapis nie może zniknąć po drodze. Druga to bramka w kodzie, która sprawdza, czy cytat każdego punktu na liście jest dosłownie taki sam jak tekst w oryginale umowy. To zwykłe porównanie dwóch ciągów znaków, ale właśnie ono potwierdza, że agenci niczego nie przeinaczyli ani nie dopisali. Punkt, w którym agent zamienił na przykład dziesięć procent kary na pięć, nie przejdzie bramki i wraca do poprawki. Trzecia kontrola to głosowanie. O tym, czy umowa jest zgodna z wytycznymi zarządu, decydują trzy niezależne oceny tej samej umowy, a werdykt wybiera większość. Głosowanie ma rodowód naukowy. Metoda zwana samospójnością (self-consistencySelf-consistencyTechnika, w której model generuje kilka niezależnych ścieżek rozumowania do tego samego pytania, a odpowiedź wybiera się przez głosowanie. Opisana w 2022 roku, poprawiła wyniki na zadaniach matematycznych o kilkanaście punktów.) polega na tym, że model rozwiązuje to samo zadanie kilka razy różnymi drogami, a odpowiedź wybiera się większością głosów. To dobry sposób na decyzje, w których pomyłka kosztuje, a przeoczona klauzula sprzeczna z polityką zarządu kosztuje reklamacje i spory z klientem. Gdy oceny się różnią, rozstrzyga sędzia, który dostaje oceny z uzasadnieniami i porównuje je z regułami. Wynikiem jest odpowiedź na pytanie zarządu, którzy klienci i w których punktach mają w umowach zapisy niezgodne z polityką firmy, z cytatem, regułą i rekomendacją przy każdym z nich.

Kilkanaście tysięcy umów pod lupą zarządu

Agent nadzorujący dzieli pracę, zespół subagentów czyta każdą umowę, a kod i sędzia pilnują, żeby nikt niczego nie przeinaczył

W jednym systemie pracuje tu prowadzący z roboczymi, potok kroków na każdej umowie, rozwidlenie z głosowaniem, sędzia i bramka w kodzie. Model robi to, w czym jest dobry, czyli czyta i ocenia język. Kod robi to, w czym jest niezawodny, czyli liczy i porównuje. A prawnik dostaje do przejrzenia nie kilkanaście tysięcy umów, tylko listę tych, przy których system podniósł rękę. Zwróć uwagę, ile w tym systemie jest kontroli w stosunku do pracy. Suma kontrolna, bramka, głosowanie, sędzia, nadzorca. To nie jest przesada, tylko konieczność, i następna sekcja tłumaczy dlaczego.

Co się psuje w roju i kto tego pilnuje

Głuchy telefon i mnożenie błędów

Najczęstszy błąd ma nazwę z podwórka. LangChain, testując architekturę z agentem prowadzącym, odkrył, że prowadzący streszczał odpowiedzi specjalistów i po drodze gubił fakty, "jak w grze w głuchy telefon". Gdy kazali mu przekazywać odpowiedzi dosłownie, wynik poprawił się o prawie połowę. Cognition opisało drugi mechanizm na przykładzie gry. Zadanie "zbuduj klon Flappy Bird" rozbito na dwóch agentów, jeden zrobił tło w stylu Super Mario, drugi ptaka, który nie zachowywał się jak w oryginale, a agent końcowy musiał skleić dwa niepasujące kawałki. Wniosek autorów brzmi "działania niosą niejawne decyzje, a sprzeczne decyzje dają złe wyniki", a w aktualizacji z 2026 roku dodali, że "agenci zakładają, że dzielą stan z dziećmi, choć go nie dzielą". Google zmierzył, jak to się składa. Bez centralnej weryfikacji błędy agentów niezależnych wzmacniają się około siedemnastokrotnie, z koordynacją centralną około czterokrotnie. Prosta arytmetyka to pokazuje. Jeśli każdy z dziesięciu kroków ma dziewięćdziesiąt pięć procent skuteczności i nikt nie sprawdza po drodze, całość przechodzi bez błędu w sześćdziesięciu procentach przypadków. To uproszczenie, bo błędy nie są niezależne, ale dobrze tłumaczy, dlaczego bramka i sędzia z przykładu z umowami nie są dodatkiem, tylko warunkiem.

Głuchy telefon: jak jeden fakt ginie w trzech przekazaniach

Subagent przeczytał wszystko, prowadzący streścił, raport dostał ogólnik. Każde przekazanie to okazja do zgubienia faktu

Czternaście sposobów na awarię

Zespół z Berkeley przeanalizował ponad tysiąc sześćset zapisów pracy systemów wieloagentowych na siedmiu popularnych frameworkach i ułożył z tego taksonomię MAST z czternastoma trybami awarii w trzech grupach. Pierwsza to błędy projektu i specyfikacji, czyli źle opisane role, niejasne zadania i agenci, którzy nie wiedzą, kiedy skończyć. Druga to rozjazd między agentami, czyli ignorowanie wyników kolegi, zadania wykonane dwa razy albo wcale i rozmowy, które toczą się obok siebie. Trzecia to brak weryfikacji, czyli nikt nie sprawdził, że wynik odpowiada na pytanie. Odsetek nieudanych przebiegów w badanych frameworkach wahał się od czterdziestu jeden do prawie osiemdziesięciu siedmiu procent, a autorzy dodają, że zyski na popularnych benchmarkach "są często minimalne". Proste poprawki promptów i ról dały kilka do kilkunastu punktów poprawy, co ich zdaniem dowodzi, że problem leży w projekcie systemu, a nie w sformułowaniach.

Bezpieczeństwo: zatruty agent rekrutuje kolegów

Rój ma jeszcze jedną słabość, której jeden agent nie ma. Agenci rozmawiają ze sobą, a rozmowa jest kanałem, którym może przejść atak. Wstrzyknięcie poleceń (prompt injectionPrompt injectionAtak, w którym złośliwa treść w danych, na przykład w mailu albo w polu formularza, jest odczytana przez model jako polecenie. W roju takie polecenie może przejść z agenta na agenta.) w roju potrafi się rozmnażać. Praca z 2024 roku o nazwie Prompt Infection pokazała, że złośliwe polecenia "samoreplikują się między połączonymi agentami". W listopadzie 2025 badacze z AppOmni pokazali to na produkcyjnej platformie ServiceNow. Złośliwa treść w polu rekordu przejęła niewinnego agenta, a ten zwerbował innych agentów z zespołu do kopiowania danych i zmiany rekordów. Przyczyną nie był błąd w kodzie, tylko domyślne ustawienia, bo agenci byli "automatycznie grupowani w ten sam zespół" i "oznaczani jako wykrywalni domyślnie po publikacji", a każdy działał z uprawnieniami użytkownika, który zaczął rozmowę. Lista OWASP dziesięciu zagrożeń dla aplikacji agentowych z grudnia 2025 ma na to dwie osobne pozycje. Niezabezpieczona komunikacja między agentami i awarie kaskadowe, w których błąd jednego rozlewa się na resztę.

Wniosek jest praktyczny i wraca do czwartego powodu orkiestracji, czyli minimalnego zestawu narzędzi. Orkiestracja pozwala rozdzielić trzy niebezpieczne zdolności, czyli dostęp do prywatnych danych, kontakt z niezaufaną treścią i możliwość wysyłania czegokolwiek na zewnątrz. Agent, który czyta maile od obcych, nie powinien mieć wysyłki, a agent, który wysyła, nie powinien czytać obcych maili. To działa tylko wtedy, gdy uprawnienia naprawdę się rozdziela, a nie kopiuje z prowadzącego na każdego subagenta. Do tego dochodzą bezpieczniki, które dziś ma każdy poważny framework. Claude Agent SDK ogranicza domyślnie zagnieżdżenie do trzech poziomów i dwudziestu subagentów naraz i pozwala ustawić budżet w dolarach, Pydantic AI ma limity kosztu, liczby wywołań i tokenów, a Microsoft w orkiestracji Magentic ma limity rund, zastojów i resetów, o których pisze, że to "strażnicy, których ustawiasz Ty". Rój bez limitu budżetu to firmowa karta kredytowa przyklejona do lodówki w akademiku.

Oceniający, strażnik i sędzia

Skoro rój bez nadzoru mnoży błędy, najważniejsza lekcja z orkiestracji nie dotyczy wykonawców, tylko tego, kto sprawdza ich pracę. Nadzór ma trzy klasyczne role. Oceniający pracuje w pętli z wykonawcą. Wykonawca pisze opis produktu, oceniający sprawdza go ze standardem marki i odsyła uwagi, i tak do skutku. Anthropic nazywa to oceniający i optymalizator (evaluator-optimizerEvaluator-optimizerWzorzec dwóch modeli, w którym jeden generuje wynik, a drugi go ocenia i odsyła uwagi, aż wynik spełni kryteria. Pętla poprawek bez udziału człowieka.), Google generator i krytyk. Jest jeden mocny argument, żeby oceniający był osobnym agentem, a nie tym samym, który pisał. W tekście o projektowaniu uprzęży dla długo działających agentów z marca 2026 Anthropic pisze wprost, że agenci "niezawodnie zawyżają oceny własnej pracy". Łatwiej nastroić sceptycznego recenzenta z czystym kontekstem, niż nauczyć autora samokrytyki. Cognition, twórca agenta Devin, mierzy to u siebie. Osobny agent recenzujący z czystym kontekstem łapie średnio dwa błędy na każdą zmianę w kodzie.

Strażnik to druga rola. Stoi na wejściu, na wyjściu albo przy narzędziu i sprawdza, zanim coś się wykona. W zestawie OpenAI do budowy agentów strażnik nazywa się guardrail (guardrailGuardrailOsobna reguła albo osobny model, który sprawdza wejście, wyjście lub wywołanie narzędzia i może zatrzymać agenta. W Agents SDK od OpenAI strażnik zgłasza przekroczenie przez tripwire, czyli linkę, która przerywa bieg.) i działa w dwóch trybach. Może pracować równolegle z agentem, co jest szybsze, ale agent zdąży zużyć tokeny albo wywołać narzędzie, zanim strażnik zadziała, albo blokująco, czyli zanim agent ruszy. Dla akcji nieodwracalnych, jak wysyłka maila z danymi klienta albo przelew, strażnik powinien być blokujący. Bramka porównująca cytaty z oryginałem umowy to właśnie strażnik, tyle że napisany w kodzie, a przykład prostszy to strażnik, który zatrzymuje każdą wiadomość wychodzącą z numerem PESEL w treści.

Sędzia to trzecia rola. Nie poprawia i nie blokuje, tylko wystawia ocenę, często kilku wynikom naraz. Gdy trzech agentów napisało trzy wersje odpowiedzi na reklamację, sędzia wybiera najlepszą. W literaturze nazywa się to model jako sędzia (LLM-as-a-judgeLLM-as-a-judgeUżycie modelu językowego do oceniania odpowiedzi innych modeli według kryteriów albo skali. Silne modele zgadzają się z ocenami ludzi w ponad 80 procentach przypadków, ale mają własne skrzywienia, na przykład preferują dłuższe odpowiedzi.) i ma udokumentowane skrzywienia, bo sędziowie preferują dłuższe odpowiedzi i tę, która stoi pierwsza. Anthropic w swoim systemie badawczym używa jednego wywołania z jednym promptem, które zwraca ocenę od zera do jednego i werdykt zaliczone albo nie, bo taki format najlepiej zgadzał się z ocenami ludzi.

Czterej nadzorcy roju

Wykonawca w środku zmienia świat. Oceniający odsyła, sędzia wybiera, strażnik blokuje, człowiek zatrzymuje

Człowiek z przyciskiem stop

Czwarty nadzorca nie jest agentem. Człowiek w pętli (human in the loopHuman in the loopKrok, w którym system zatrzymuje się i czeka na decyzję człowieka, zanim wykona akcję o skutkach trudnych do cofnięcia. Wymaga zapisu stanu, żeby rój mógł wznowić pracę po akceptacji.) to punkt, w którym rój zatrzymuje się i czeka. OpenAI podaje dwa wyzwalacze. Pierwszy to przekroczenie progu błędów, drugi to akcje wysokiego ryzyka, "wrażliwe, nieodwracalne albo o wysokiej stawce", z przykładami takimi jak anulowanie zamówień, "autoryzowanie dużych zwrotów albo dokonywanie płatności". Żeby rój mógł czekać na kierownika i nie stracić pracy, potrzebuje punktu kontrolnego (checkpointCheckpointZapis pełnego stanu przebiegu w trwałym miejscu, dzięki któremu system może się zatrzymać na decyzję człowieka albo po awarii i wznowić pracę dokładnie z tego miejsca.), czyli zapisu stanu, z którego można wznowić. LangGraph robi to przez przerwania z trwałym zapisem, Microsoft przez narzędzia wymagające akceptacji, które "wstrzymują przepływ do przeglądu przez człowieka", Langflow od wersji 1.11 przez pauzę z zapisanym stanem, a Zapier pozwala ustawić zatwierdzanie osobno dla każdej akcji. Przykład z firmy jest prosty. Agent przygotował zwrot pięciu tysięcy złotych, rój zatrzymał się i czeka na kliknięcie kierownika, a po kliknięciu wznawia pracę od tego miejsca. Europejskie prawo o sztucznej inteligencji wymaga w artykule czternastym, żeby systemy wysokiego ryzyka dało się nadzorować, przerwać przyciskiem stop i uchylić ich wynik. Nie ma tam osobnych przepisów o rojach, więc liczy się zastosowanie, a nie liczba agentów, ale w praktyce oznacza to, że przycisk stop musi zatrzymać cały rój, a nie jednego agenta.

Czy to się opłaca: co mówią dane i ile to kosztuje

Dowody za

Najczęściej cytowana liczba pochodzi z Anthropic. System badawczy z Opusem jako prowadzącym i Sonnetami jako robotnikami wypadł w ich wewnętrznym teście o dziewięćdziesiąt procent lepiej niż pojedynczy Opus. To wewnętrzny test na zadaniach badawczych, nie publiczny benchmark, i Anthropic uczciwie dopisuje, że większość zadań programistycznych ma mniej naprawdę równoległych części niż research, więc tam przewaga jest mniejsza. Najmocniejsze badanie, jakie mamy, to praca zespołu Google Research z grudnia 2025, uzupełniona w kwietniu 2026, która sprawdziła dwieście sześćdziesiąt konfiguracji na sześciu zadaniach, trzech rodzinach modeli i pięciu architekturach. Na zadaniu z analizy finansowej, które daje się rozłożyć na niezależne części, koordynacja centralna poprawiła wynik o osiemdziesiąt procent względem jednego agenta. Cognition w kwietniu 2026 podsumowało własną praktykę jednym zdaniem. Działa układ, w którym "wielu agentów wnosi inteligencję do zadania, a zapisy pozostają jednowątkowe", czyli myśli wielu, a wykonuje jeden.

Dowody przeciw

Ta sama praca Google pokazała drugą stronę. Na zadaniu z planowania sekwencyjnego, gdzie każdy krok zależy od poprzedniego, każdy wariant wieloagentowy pogorszył wynik, od trzydziestu dziewięciu do siedemdziesięciu procent. Autorzy znaleźli też próg nasycenia. Gdy pojedynczy agent rozwiązuje zadanie w więcej niż około czterdziestu pięciu procentach przypadków, dokładanie agentów zaczyna szkodzić. Przepływy biznesowe z szesnastoma narzędziami "cierpią z powodu narzutu koordynacji", a to dokładnie typowy proces w firmie z kilkunastoma integracjami. Badanie ze Stanforda z kwietnia 2026 dołożyło najważniejszą korektę. Przy tym samym budżecie tokenów na rozumowanie pojedynczy agent "konsekwentnie dorównuje albo przewyższa" system wieloagentowy na zadaniach wymagających kilku kroków wnioskowania. Rój dogania dopiero wtedy, gdy pojedynczy agent przestaje dobrze wykorzystywać swój kontekst. Gdy zestawisz to z liczbą Anthropic, że samo zużycie tokenów wyjaśnia osiemdziesiąt procent różnic w wynikach, obraz robi się jasny. Duża część przewagi roju to więcej mocy obliczeniowej rozłożonej na osobne konteksty, a nie magia współpracy. Rój wygrywa tam, gdzie jedna głowa jest za mała, i przegrywa tam, gdzie wystarczyłaby jedna głowa z lepszym promptem.

Kiedy zespół agentów pracuje lepiej niż jeden agent, a kiedy gorzej

Badacze Google porównali pracę jednego agenta z pracą zespołu agentów na różnych rodzajach zadań. Słupek pokazuje, o ile procent zespół wypadł lepiej albo gorzej od pojedynczego agenta

Ile to kosztuje

Anthropic podaje, że agent zużywa około czterech razy więcej tokenów niż zwykła rozmowa, a system wieloagentowy około piętnastu razy więcej. Google zmierzył narzut koordynacji od pięćdziesięciu ośmiu procent dla agentów niezależnych do pięciuset piętnastu procent dla architektury hybrydowej. Dlatego Anthropic pisze, że roje wymagają zadań, "których wartość jest wystarczająco wysoka, żeby zapłacić za lepszy wynik". Kilkanaście tysięcy umów sieci handlowej to jest takie zadanie, bo alternatywą były miesiące pracy prawników. Odpowiedź na pytanie o godziny otwarcia nie jest, i rój przy niej jest tym, czym zespół konsultantów przy wymianie żarówki. Wczesne wersje systemu Anthropic potrafiły zresztą uruchomić pięćdziesięciu subagentów do prostego pytania, więc skalowanie wysiłku trzeba zapisać w instrukcji prowadzącego. Dla prostego pytania jeden agent i kilka wywołań narzędzi, dla porównania dwóch do czterech subagentów, dla złożonego researchu więcej niż dziesięciu.

Drogi myśli, tani robi: orkiestracja modeli

Największą dźwignią kosztu jest czwarte znaczenie ze słownika, czyli orkiestracja modeli. Nie każdy krok wymaga najdroższego modelu, więc orkiestrator, kod, klasyfikator albo inny model, decyduje, który model obsłuży dany krok. W praktyce każdy rój jest jednocześnie orkiestracją modeli, bo prowadzący i roboczy rzadko pracują na tym samym silniku. W systemie badawczym Anthropic prowadzącym był Claude Opus 4, a robotnikami Claude Sonnet 4. Dokumentacja Claude Code wymienia wśród korzyści z subagentów "kontrolę kosztów przez kierowanie zadań do szybszych, tańszych modeli jak Haiku". Taki układ, w którym drogi model planuje, a tani wykonuje, jest dziś domyślny.

Ciekawsze jest odwrócenie. W kwietniu 2026 Anthropic opisało strategię doradcy (advisorAdvisorUkład, w którym tańszy model prowadzi zadanie i tylko w trudnych momentach pyta droższy model o radę. Odwrócenie klasycznego wzorca, w którym drogi model deleguje pracę tanim.), w której tani model prowadzi zadanie, a drogi tylko doradza, gdy tani utknie. Na teście wyszukiwania w sieci Haiku z doradcą Opus zaliczył czterdzieści jeden procent zadań wobec niecałych dwudziestu procent w pojedynkę, przy koszcie o osiemdziesiąt pięć procent niższym niż samodzielny Sonnet. Cognition zrobiło to samo w Devin Fusion, gdzie model z czołówki deleguje i nadzoruje, a tańszy pomocnik wykonuje. W ich własnym teście taki duet kosztował jeden dolar trzydzieści pięć centów za zadanie wobec trzech dolarów pięćdziesięciu jeden centów dla samego drogiego modelu, przy wyniku niższym o pół punktu. Orkiestracja nie musi więc znaczyć "drożej". Może znaczyć "taniej przy prawie tej samej jakości", jeśli podział ról jest przemyślany.

Drogi myśli, tani robi: trzy sposoby orkiestracji modeli

Drugie znaczenie słowa orkiestracja. Nie każdy krok wymaga najdroższego modelu, a dobór modelu do kroku potrafi ściąć koszt o rząd wielkości

Trzecia odmiana to routing i kaskady. Router (routerRouterKlasyfikator albo mały model, który na podstawie treści zapytania wybiera, który model je obsłuży. Pytanie o godziny otwarcia idzie do małego modelu, pytanie o warunki umowy do dużego.) klasyfikuje zapytanie i kieruje je do odpowiedniego modelu, a kaskada (kaskadaLLM cascadeStrategia, w której zapytanie najpierw obsługuje tani model, a do droższego trafia tylko wtedy, gdy tani nie jest pewny odpowiedzi. Opisana w pracy FrugalGPT z 2023 roku.) najpierw próbuje tanim modelem i eskaluje tylko niepewne przypadki. Badania z lat 2023 i 2024 podawały oszczędności rzędu osiemdziesięciu pięciu procent kosztu przy dziewięćdziesięciu pięciu procentach jakości drogiego modelu, a w kaskadach nawet więcej. Trzeba to jednak czytać z korektą ze stycznia 2026, gdy zbiorczy test routerów pokazał, że "wiele metod routingu wykazuje podobną skuteczność" i że część podejść, także komercyjnych, "nie potrafi wiarygodnie pobić prostego punktu odniesienia". Oszczędności są realne, ale gotowy router nie zawsze bije prostej reguły "najpierw tani, eskaluj przy niskiej pewności", więc trzeba mierzyć na własnych danych. Jest jeszcze mieszanka agentów (mixture-of-agentsMixture-of-agentsWarstwowy układ, w którym kilka modeli pisze własne odpowiedzi, a kolejny model składa z nich jedną. W 2024 roku zespół otwartych modeli pobił tak GPT-4o na teście preferencji odpowiedzi.), w której kilka modeli pisze własne odpowiedzi, a kolejny składa z nich jedną. To raczej zespół modeli niż rój agentów z narzędziami, ale bywa mylone z orkiestracją i dlatego je wymieniamy.

Z naszej stajni: loop, czyli orkiestrator z trzema piętrami pętli

Wszystko, co napisaliśmy wyżej, sprawdzamy w praktyce na własnym orkiestratorze. Nazywa się loop, pakiet @mtzn/loop, i jest narzędziem wiersza poleceń zaprojektowanym do automatyzacji dużych zadań. Bierze plan zapisany w pliku i wykonuje go punkt po punkcie, uruchamiając dla każdego punktu osobnego agenta Claude Code albo Codex. Opisujemy go dlatego, że widać w nim prawie każdy wzorzec z tego artykułu naraz.

Plan jako umowa, świeży agent na punkt

Plan to lista punktów z polami wyboru. Każdy punkt ma przypisany model, tryb wykonania po kolei albo równolegle oraz limity czasu i budżetu. Przed startem plan przechodzi audyt, który wyłapuje błędy w jego budowie. Loop bierze pierwszy niewykonany punkt i uruchamia dla niego nowego agenta w czystym kontekście. To wprost odpowiedź na czwarty powód orkiestracji, bo każdy punkt dostaje całą głowę dla siebie, a nie resztkę po poprzednich. Punkty równoległe idą naraz, a loop czeka na najwolniejszy. Zadanie nie kończy się wtedy, gdy agent kończy pracę, tylko wtedy, gdy pole wyboru w planie jest odhaczone. To rozróżnienie wydaje się drobne, a jest fundamentem, bo o stanie decyduje plan, a nie deklaracja agenta, który "niezawodnie zawyża oceny własnej pracy". Agent, który skończył bez odhaczenia, dostaje jeszcze jedną próbę. Po awarii loop wznawia pracę, a po każdym punkcie zapisuje stan w repozytorium, więc historia zmian zawsze zgadza się z planem.

Bramka, kontrola i cofanie

Agenci pracujący bez człowieka przy klawiaturze potrzebują strażnika, bo reguła zapisana w prompcie jest tylko prośbą. Dlatego każde polecenie, które agent chce wykonać na komputerze, przechodzi przez bramkę. Bramka sprawdza je przed wykonaniem i blokuje te, które mogłyby zaszkodzić czemuś poza zadaniem, a gdy nie potrafi ocenić polecenia, odmawia. Oceniającego mamy w postaci punktu kontrolnego. To, że agent skończył punkt, nie znaczy jeszcze, że etap jest dobry, dlatego co kilka punktów w planie stoi kontrola. Agent kontroli czyta zmiany, uruchamia aplikację, mierzy to, co opisuje plan, i wydaje jeden z trzech werdyktów. Akceptuje etap, cofa go do wskazanego punktu albo zatrzymuje się i oddaje decyzję człowiekowi. Cofnięcie nie jest ślepym "spróbuj jeszcze raz". Agent kontroli musi dopisać do cofanych punktów wnioski, co nie zadziałało i jak robić teraz, a kolejny wykonawca dostaje je w opisie punktu. Plan staje się w ten sposób pamięcią przebiegu. Ten sam plan może puścić punkt na Claude Code albo na Codexie, lokalnie, w odizolowanym kontenerze albo w chmurze, a agent może uruchomić własny podloop na innej maszynie. To hierarchia z sekcji o wzorcach, zbudowana na prawdziwych maszynach.

Loop: orkiestrator z trzema piętrami pętli

Na dole wykonawcy, w środku orkiestrator z bramką i kontrolą, na górze agent, który nadzoruje orkiestrator. Człowiek czyta raport rano

Agent, który nadzoruje orkiestrator

Bardzo ciekawy przykład daje praktyczne zastosowanie loopa w dużym zadaniu, takim jak wieloetapowa przebudowa oprogramowania. Widać w nim wybór, przed którym staje dziś każdy, kto automatyzuje pracę agentami. Można dać agentowi swobodę i pozwolić mu samodzielnie podejmować decyzje, licząc na dobry wynik. Można też zbudować procedurę, według której system działa krok po kroku, z kontrolami i cofnięciami. Można wreszcie połączyć jedno z drugim, i to robimy. Loop jest tu narzędziem orkiestracji w rękach agenta. Procedura biegnie według planu, a obok niej pracuje agent, który nadzoruje całość i reaguje zamiast człowieka.

Układ ma trzy piętra. Na dole są wykonawcy, osobny agent na każdy punkt planu. W środku jest loop z bramką i punktami kontrolnymi, z których każdy może cofnąć pracę i dopisać wnioski. Na górze działa agent nadzorujący, czyli sesja Claude Code z własną pętlą, która regularnie robi przegląd przebiegu. Czyta stan, dzienniki i raporty, porównuje postęp z planem i reaguje według zapisanych wytycznych. Gdy loop się zatrzyma, uruchamia go ponownie. Gdy zauważy, że któryś punkt jest źle opisany albo że kontrola zażąda czegoś, czego wykonawca nie dostarczy, poprawia plan, zanim dojdzie do kosztownego cofnięcia. Zgłasza problemy i wnioski, jak usprawnić procedurę, a kodu sam nie dotyka. Jego zadaniem jest doprowadzić całą procedurę do końca zgodnie z planem. Człowiek nie musi siedzieć przy ekranie. Czyta raport i wkracza tylko wtedy, gdy agent nadzorujący albo kontrola oddadzą mu decyzję.

Zrzut pokazuje taki przegląd w trakcie pracy. Po lewej agent nadzorujący opisuje, co sprawdził i co zmienił w planie, po prawej loop pokazuje punkty etapu, ich stan i kolejne kontrole. To jest orkiestracja w pełnej postaci. Hierarchia z trzema piętrami, oceniający, który może cofać pracę, strażnik na poziomie poleceń, plan jako wspólna pamięć, którą poprawiają i kontrola, i agent nadzorujący, a człowiek w pętli zastąpiony agentem działającym według wytycznych, z człowiekiem nad nim. Najważniejsza lekcja jest taka, że agent nadzorujący zapobiega kosztownym cofnięciom, zanim do nich dojdzie, bo wie, czego będzie wymagać następny punkt kontrolny. Swobodna praca agenta i sztywna procedura nie muszą się wykluczać. Procedura daje powtarzalność, a agent nad nią daje elastyczność tam, gdzie procedura czegoś nie przewidziała.

Pętla hybrydowa: jak z pracy z agentem rodzi się procedura

Skąd bierze się plan, który loop wykonuje? Nie z głowy. Najlepiej pokazać to na tym, jak powstał ten artykuł, bo on też jest przykładem orkiestracji, tylko innej niż loop. Zaczęło się od researchu. Subagent przeanalizował słowa kluczowe i działania konkurencji w wyszukiwarce, a na tej podstawie operator zdecydował, jakie tematy artykułów są potrzebne na naszej stronie, żeby pracować nad jej widocznością. Potem agent zaproponował listę artykułów, a człowiek wybrał ten, który chce. Agent przygotował strukturę i plan tekstu, człowiek zarządził zmiany i dopracował koncept. Na tej podstawie agent przeanalizował kod źródłowy loopa, opisał jego architekturę i działanie, i przygotował bazę artykułu. Ta baza trafiła do człowieka jako wersja robocza. Dalej człowiek redagował ją i przepisywał, czasem samodzielnie, czasem zlecając poprawki agentowi. Agent swobodnie decydował, czy do danej części uruchomić subagentów, a czasem to człowiek polecał mu z nich skorzystać.

To jest orkiestracja hybrydowa. Człowiek, pracując z agentem, de facto go orkiestruje. Instruuje go, poprawia jego pracę, w odpowiednich momentach zwraca uwagę na błędy i w ten sposób, nie pisząc tego nigdzie wprost, tworzy procedurę pisania dobrego artykułu. Każda korekta mówi coś o tym, czego oczekuje. Że przykład ma pasować do tego, jak takie systemy naprawdę się buduje. Że lokalne szczegóły techniczne nic nie wnoszą do opowieści. Że powody, dla których coś robimy, mają wynikać z praktyki, a nie z ogólników.

A teraz wyobraź sobie, że po wielu takich artykułach analizujesz historię wszystkich tych rozmów i wyciągasz z niej wnioski. Jakie błędy powtarzały się najczęściej, czego człowiek oczekiwał za każdym razem, które poprawki wracały jak bumerang. Z tych wniosków powstaje procedura dla loopa, jak pisać ciekawe artykuły, wykonywana przez tych samych agentów, z których korzystaliśmy przy pisaniu oryginału. Zapisujesz ją w zwykłym pliku tekstowym i to działa.

Na tym polega siła tego podejścia. W orkiestracji wszędzie szukamy pętli. Pracujemy z agentem hybrydowo, wiele razy, aż pamięć i notatki dojrzeją do tego stopnia, że produkcja treści, reklamy albo raportu przestaje wymagać naszych korekt albo da się je zmieścić w jednym czy dwóch punktach. Dopiero wtedy piszemy na tej podstawie plan dla agentów. W pewnym momencie widać, że automatyzacja staje się tak prosta i naturalna jak napisanie pliku tekstowego z procedurą, którą agenci wykonują w precyzyjnie określonych granicach, z jasnymi zasadami w każdym punkcie.

Ta sama pętla w marketingu

W ten sam sposób zbudowaliśmy generator reklam. Agent tworzy kreację, osobny etap kontroli jakości z modelem widzącym obraz ocenia ją ze standardem marki, pętla pozwala na trzy próby na wariant, a uwagi ludzi trafiają z powrotem do generatora i poprawiają jego własne instrukcje. Każda sesja z człowiekiem zostawia po sobie lepszą procedurę, więc kolejnych uwag jest coraz mniej. Pokazujemy to krok po kroku w artykule o tym, kiedy automatyzacja jest warta swojej ceny. Krok dalej opisujemy w tekście o tym, jak oddaliśmy agentowi 5 procent budżetu reklamowego. Tam agent z ustawionym celem przez cały kwartał sam tworzył i testował kreacje w wydzielonej części kampanii, a człowiek ustalał granice i oceniał wyniki. To ta sama zasada co w loopie. Najpierw pętla z człowiekiem, potem procedura, a na końcu agent, który pracuje sam w granicach, które człowiek mu wyznaczył.

Kiedy jeden agent nie wystarczy: sprawdzian przed decyzją

Zbierzmy to w sprawdzian, który możesz zrobić przy każdym procesie. Rój ma sens, gdy zachodzi choć jeden z czterech powodów i jednocześnie kilka warunków. Chcesz skonfrontować kilka podejść albo modeli, części zadania da się wykonać równolegle, proces ma stałą procedurę, którą warto zaprogramować krok po kroku, albo pomocnicy powinni pracować na wąskim wycinku wiedzy z minimalnym zestawem narzędzi. Zadanie rozkłada się na niezależne części, a nie na wspólne pisanie jednego dokumentu krok po kroku. Wartość wyniku uzasadnia kilka do kilkunastu razy wyższy rachunek za tokeny. I jest ktoś, kto sprawdza wynik, oceniający, sędzia, bramka w kodzie albo człowiek, bo bez tego błędy mnożą się siedemnastokrotnie. Jeśli te warunki nie zachodzą, zacznij od jednego agenta z dobrym promptem i narzędziami, a rój zostaw na później. Jeśli zachodzą, projektuj rój tak, żeby myśleć mogło wielu, ale klikać "wyślij" powinien jeden. Taki sprawdzian robimy z klientami na początku każdego wdrożenia, a jak wygląda cała droga od pierwszego procesu do roju, opisujemy na stronie o agentach AI dla firm.

I jeszcze jedno. Nie zatrudniaj drugiego agenta po to, żeby mieć w firmie dział AI z pięcioma etatami, które rozmawiają głównie ze sobą. Zatrudnij go wtedy, gdy pierwszy naprawdę nie wyrabia.

Czym zbudujesz rój: od n8n po Claude Code

No-code: n8n, Make i Zapier

W artykule-matce napisaliśmy, że n8n, Make i Zapier pozwalają zbudować chatbota, agenta i rój. Stan na jesień 2026 to potwierdza. W n8n węzeł AI Agent Tool pozwala agentowi głównemu "wywoływać innych agentów jako narzędzia", a agent główny "może nadzorować i delegować pracę" do węzłów wyspecjalizowanych w różnych zadaniach, z zagnieżdżaniem w wiele warstw. Od sierpnia 2026 n8n testuje też osobny byt o nazwie n8n Agents, w którym do opublikowanego agenta dołącza się innych jako subagentów, choć pełna orkiestracja wielu agentów jest tam na liście planów. Make od lipca 2026 ma subagentów, czyli "agentów Make dodawanych jako narzędzia wewnątrz innych agentów Make". Zapier pozwala agentowi wywołać innego agenta i, jak pisaliśmy, radzi nie przekraczać pięciu takich wywołań, a w 2026 roku przenosi agentów do zwykłych Zapów jako krok AI by Zapier z zatwierdzaniem osobno dla każdej akcji i wyborem modelu osobno dla każdego kroku. We wszystkich trzech dostajesz wzorzec agent jako narzędzie z prowadzącym, czyli ten, który w firmach jest najczęstszy i najbezpieczniejszy. Nie dostajesz sieci bez centrali, i to jest zaleta, nie wada.

Platformy dla dużych firm

Microsoft Copilot Studio od kwietnia 2026 ma w ogólnej dostępności agentów podrzędnych, agentów połączonych i komunikację z obcymi agentami przez protokół A2A, przy czym dokumentacja ostrzega o dodatkowym opóźnieniu "z powodu dodatkowych przeskoków orkiestracji" i o tym, że agent z podłączonymi agentami nie może sam być podłączony do innego. Salesforce w Agentforce stawia agenta głównego jako punkt wejścia, a jego silnik rozumowania "przegląda opis, instrukcje i dostępne akcje każdego agenta" i wybiera specjalistę. ServiceNow ma centralny orkiestrator agentów i pisze, że dynamiczny orkiestrator ma sens powyżej ośmiu do dziesięciu agentów. Amazon udostępnił współpracę wielu agentów w Bedrock w marcu 2025, a w październiku 2025 AgentCore, czyli infrastrukturę do uruchamiania rojów zbudowanych w dowolnym frameworku, z sesjami do ośmiu godzin i obsługą protokołów A2A i MCP. Google w kwietniu 2026 ogłosił Gemini Enterprise Agent Platform z "siecią subagentów" i frameworkiem grafowym w zestawie ADK. Dify, który w artykule-matce ustawiliśmy wśród narzędzi do chatbotów, od sierpnia 2026 ma agenta jako osobny zasób używany w wielu przepływach, ale orkiestracja wielu agentów nie jest jego głównym atutem. Langflow od wersji 1.11 publikuje przepływy jako agentów A2A i ma pauzę na decyzję człowieka z zapisanym stanem, co czyni go naturalnym następcą Flowise, którego twórcy wygasili projekt z końcem sierpnia 2026.

Frameworki i gotowe agenty

Jeśli piszesz kod, wybór jest szeroki i wzorce wszędzie są te same. OpenAI Agents SDK ma agenta jako narzędzie, przekazanie rozmowy, strażników i równoległość w kodzie. Claude Agent SDK ma subagentów z izolacją kontekstu, równoległość, limity i budżet, a dokumentacja ostrzega, że "jeden prompt może rozrosnąć się w drzewo agentów". Google ADK ma agentów sekwencyjnych, równoległych i pętlowych, przekazanie do subagenta i wspólny stan sesji, do którego każdy agent pisze pod własnym kluczem. Microsoft Agent Framework, oficjalny następca AutoGen i Semantic Kernel, od lipca 2026 ma pięć stabilnych wzorców, sekwencyjny, równoległy, naradę, przekazanie i Magentic. LangGraph pozwala narysować własny graf z węzłami deterministycznymi i agentowymi, a CrewAI rozdziela załogi, czyli zespoły agentów, od przepływów, które nimi sterują. Osobna kategoria to gotowe agenty, które mają rój w środku. Claude Code uruchamia subagentów i eksperymentalne zespoły z wspólną listą zadań i skrzynkami wiadomości. Codex ma subagentów domyślnie włączonych i ostrzega, że zużywają więcej tokenów niż pojedynczy przebieg. Devin od marca 2026 "zarządza innymi Devinami", z których każdy działa we własnej maszynie wirtualnej. Cursor pozwala uruchomić "tylu agentów, ilu chcesz, równolegle", Manus w trybie szerokiego researchu uruchamia ponad sto instancji naraz, a OpenClaw ma subagentów z własnym kontekstem i zaleceniem tańszego modelu dla nich. We wszystkich widać z zewnątrz trzy rzeczy. Panel z listą pomocników, ich transkrypty i rachunek za tokeny.

Mapa narzędzi do orkiestracji: od kreatorów po protokoły

Oś pozioma mówi, ile kodu piszesz. Oś pionowa mówi, jak daleko sięga orkiestracja, od agenta jako narzędzia po rozmowę z agentem innej firmy

MCP i A2A po ludzku

Dwa skróty wracają w każdej dokumentacji i warto je rozłożyć na części. Protokół kontekstu modelu (MCPModel Context ProtocolOtwarty protokół łączący agenta z narzędziami i danymi, na przykład z bazą, kalendarzem albo systemem fakturowania. Od grudnia 2025 rozwijany w fundacji pod Linux Foundation, w lipcu 2026 uproszczony do bezstanowego żądania i odpowiedzi.), czyli MCP, łączy jednego agenta z jego narzędziami. Protokół agent do agenta (A2AAgent2AgentOtwarty protokół, w którym agenci przedstawiają się wizytówką, zlecają sobie zadania i oddają wyniki, także między firmami i frameworkami. Wersja 1.0 z 2026 roku, ponad 150 organizacji wspierających.), czyli A2A, łączy agentów ze sobą. Dokumentacja A2A ujmuje to jednym zdaniem. "MCP jest pionowy, pogłębia jednego agenta. A2A jest poziomy, łączy agentów ponad tą granicą." Przykład stamtąd pasuje do każdej firmy usługowej. Klient rozmawia z agentem kierownika warsztatu przez A2A, agent mechanika używa narzędzi diagnostycznych przez MCP, a części zamawia u agenta dostawcy znowu przez A2A. Oba protokoły są dziś pod opieką Linux Foundation, A2A w wersji 1.0 wspiera ponad sto pięćdziesiąt organizacji, a wspierają go Copilot Studio, Agentforce, AgentCore, Gemini Enterprise i Langflow. Czy mała firma ich potrzebuje? MCP tak, bo to dziś standardowe gniazdko, którym agent podłącza się do Twoich systemów. A2A dopiero wtedy, gdy Twój agent ma rozmawiać z agentem innej firmy albo gdy budujesz rój z narzędzi różnych producentów. Wewnątrz jednego frameworku agenci rozmawiają ze sobą bez niego.

Najczęstsze pytania o orkiestrację agentów AI