Próg 10 agentów — Dlaczego skalowanie powyżej 10 agentów AI zmienia wszystko
Coś się psuje przy 10.
Nie technologia. Infrastruktura organizacyjna i monitoringowa wokół niej.
Pierwszych pięć agentów jest prostych — każdy wykonuje jedno zadanie, każdy ma jasnego właściciela, każdy jest śledzalny. Od szóstego do dziewiątego są zarządzalne. Przy dziesiątym ktoś zwykle zauważa, że coś się przesunęło, ale nie potrafi dokładnie określić co. Przy piętnastym wkraczają w tryb kryzysowy produkcji — kaskadowe błędy, których nie mogą wyśledzić, faktury, których nie potrafią uzasadnić, i konfigurację monitoringu generującą więcej szumu niż sygnału.
Dane Google Cloud wyjaśniają dlaczego: 52% organizacji wdrażających AI ma agentów w produkcji. 39% wdrożyło więcej niż 10. Problem polega na tym, że praktycznie nie istnieje wskazówka, co się zmienia przy tym progu. Ekosystem treści pokrywa wdrożenie od jednego do pięciu agentów w najdrobniejszych szczegółach. Następnie pojawia się przepaść dokładnie w momencie, gdy zaczyna się prawdziwe inżynierowanie.
To jest o tej przepaści.
Co dane tak naprawdę pokazują
Raport Google Cloud o ROI na 2025 rok zawiera dwie liczby, które powinny znaleźć się w każdej prezentacji dla CTO.
52% organizacji z wdrożeniami AI przeszło etap pilotażowy. To nie jest już eksperyment — to infrastruktura produkcyjna.
39% przekroczyło 10 agentów.
Luka między tymi dwiema liczbami to miejsce, gdzie żyje większość nieudanych wdrożeń. Przejście od jednego agenta do pięciu to dobrze zrozumiała ścieżka. Przejście od dziewięciu do dwunastu to zupełnie inny problem, a prawie nikt nie pisze o nim uczciwie.
Dlaczego 1–10 agentów działa — i dlaczego nie może się skalować
Powód, dla którego 1–10 agentów jest zarządzalne, ma charakter strukturalny, nie technologiczny.
Każdy agent ma jasnego właściciela. Gdy coś się psuje, jedna osoba przeprowadza triage. Gdy coś działa, jedna osoba otrzymuje uznanie. Struktura odpowiedzialności jest skalowalna ludzko.
Koszt każdego agenta jest atrybuowany. Wiesz, ile kosztuje miesięcznie agent obsługi klienta. Wiesz, ile kosztuje agent fakturowania. Gdy CFO pyta, które inwestycje AI przynoszą wartość, możesz odpowiedzieć.
Wyniki każdego agenta są weryfikowalne. Sprawdzasz pracę. Losowo weryfikujesz wygenerowane faktury, zamknięte zgłoszenia, wyprodukowane raporty. Praca agenta jest rozróżnialna od pracy ludzi wokół niego.
Awaria każdego agenta jest kontrolowana. Jeden agent się psuje, jedna osoba go naprawia, system działa dalej.
Ta struktura działa do około 10 agentów. Przestaje działać przy 11.
Co pęka przy progu 10 agentów
Tryby awarii przy skali są konkretne i nameable.
Wybuch złożoności orkiestracji
Agent A zależy od agenta B, który zależy od agenta C. Gdy A zawodzi, nie wiesz, czy to wina A, B, czy C. Awaria jest kaskadowa i niewidoczna, dopóki nie wynurzy się gdzieś dalej w strumieniu — zwykle przed klientem.
W jednej organizacji agent routingu leadów czasami wysyłał leady do niewłaściwego przedstawiciela handlowego. Proces debugowania trwał cztery dni. Rzeczywista przyczyna: agent wzbogacania danych zaczął zwracać nowe pole, którego agent routingu nie oczekiwał, co powodowało błędną interpretację wyniku priorytetu. Nikt nie dotknął agenta routingu. Nikt nie dotknął CRM. Awaria była całkowicie w interakcji między dwoma agentami, z których każdy był testowany indywidualnie i uznany za poprawny.
To jest fundamentalny problem systemów wieloagentowych: agenci są testowani w izolacji, ale zawodzą w kompozycji.
Zapaść atrybucji kosztów
Bez infrastruktury śledzenia per-agent wiesz, że wydajesz X dolarów miesięcznie na AI. Nie wiesz, którzy agenci produkują wartość, a którzy są szumem.
W średniej firmie z 14 agentami CFO zapytał: „Które z nich są warte tego, co płacimy?" Odpowiedź zajęła trzy tygodnie i była wciąż niedokładna. Agenci byli dodawani stopniowo przez osiem miesięcy przez trzech różnych członków zespołu, i nikt nie zbudował infrastruktury atrybucji, gdy pierwszy agent był wdrażany.
Koszt tego długu atrybucji: około 40 000 dolarów nadmiernie aprowizowanej pojemności agentów, której nikt nie zauważył, ponieważ rozliczenia przychodziły jako jedna pozycja.
Luka monitoringowa
Metryki poszczególnych agentów są widoczne. Metryki interakcji agent-system nie są.
Indywidualne metryki agenta obsługi klienta są w porządku. Indywidualne metryki agenta CRM są w porządku. Ale interakcja między nimi — co się dzieje, gdy agent obsługi klienta tworzy sprawę, na której agent CRM musi działać — ta interakcja nie ma metryk. Widzisz drzewa. Nie widzisz lasu.
To jest luka monitoringowa przy skali. Wymaga instrumentacji, której większość platform agentowych nie zapewnia out of the box, i której większość zespołów nie wie, że potrzebuje, dopóki już nie wdroży się w nią.
Dwuznaczność własności
Gdy trzej agenci przyczyniają się do jednego wyniku, kto jest właścicielem wyniku?
Bardziej konkretnie: gdy agent zawodzi w połowie workflow, kto przeprowadza triage? Gdy wyniki agenta degradują, ponieważ inny agent zmienił swoje zachowanie, kto diagnozuje? Gdy system produkuje zły wynik, kto ponosi odpowiedzialność?
Struktura organizacyjna, która działa dla pięciu agentów — „ty jesteś właścicielem tego agenta, ja jestem właścicielem tamtego" — nie mapuje się łatwo na piętnście agentów, gdzie agenci wchodzą w interakcje ze sobą częściej niż z ludźmi, którzy nominalnie są ich właścicielami.
Podatek koordynacyjny
Czas spędzany na koordynowaniu agentów rośnie jako O(n²).
Z pięcioma agentami narzut koordynacyjny jest zarządzalny — sporadyczne check-iny, sporadyczne debugowanie, sporadyczne przekierowania. Jedna osoba może utrzymywać mentalny model interakcji pięciu agentów.
Z dwudziestoma agentami koordynacja staje się pełnoetatową rolą. Potrzebujesz kogoś, czyjej pracy jest śledzenie zależności agent-do-agent, zarządzanie przekazywaniem zadań, debugowanie awarii między agentami, i utrzymywanie mapy systemu, której nikt inny nie ma czasu prowadzić.
Przy pięćdziesięciu agentach potrzebujesz zespołu.
Większość organizacji wdrażających agenty AI nie zaplanowała budżetu na tę rolę. Odkrywają potrzebę reaktywnie — gdy narzut koordynacyjny już skonsumował zyski produktywności, które agenci mieli dostarczać.
Warstwa orkiestracji — czym tak naprawdę jest
Warstwa orkiestracji to infrastruktura, która siedzi nad poszczególnymi agentami i zarządza pięcioma rzeczami, których agenci nie mogą zarządzać sami.
Routing zadań: Który agent obsługuje które żądanie? W systemie 5-agentowym to manualna decyzja. W systemie 15-agentowym wymaga logiki routingu, która rozumie możliwości agentów, bieżące obciążenie i kontekst.
Zarządzanie stanem: Jak agenci dzielą kontekst? Gdy Agent A produkuje wynik, którego potrzebuje Agent B, skąd B wie, co A wyprodukowało? Bez infrastruktury współdzielonego stanu agenci komunikują się przez kruche przekazania — zrzuty plików, triggery webhooków, współdzielone bazy danych, które wychodzą z synchronizacji.
Obsługa błędów: Co się dzieje, gdy agent zawodzi w połowie workflow? Czy workflow się zatrzymuje? Czy inny agent ponawia próbę? Czy człowiek otrzymuje powiadomienie? Indywidualni agenci obsługują własne błędy. Orkiestracja obsługuje błędy na granicach między agentami.
Śledzenie kosztów: Atrybucja per-agent, per-zadanie, per-wynik. Wymaga instrumentacji, której większość frameworków agentowych nie zapewnia natywnie.
Monitoring: Metryki interakcji agent-system, nie tylko metryki na poziomie agenta. To jest luka monitoringowa opisana powyżej.
Czym warstwa orkiestracji nie jest: pojedynczym superagentem, który robi wszystko. To nie jest AI zarządzający innymi AI w jakiejś sentymentalnej hierarchii. To infrastruktura — routing, stan, obsługa błędów, atrybucja, monitoring — która sprawia, że systemy wieloagentowe są operacyjnie możliwe do opanowania.
LangGraph obsługuje stateful workflows i jest najbardziej elastyczną opcją dla deweloperów. AWS Bedrock Agents zapewnia zarządzaną orkiestrację z integracją AWS. Azure AI Agent Service oferuje podobne zarządzane możliwości dla zespołów zorientowanych na Microsoft. Google Vertex AI Agent Builder znajduje się w tej samej kategorii. CrewAI zapewnia wieloagentową orkiestrację opartą na rolach, która jest bardziej dostępna dla zespołów bez głębokiego inżynierowania infrastruktury.
Framework decyzyjny
Pięć pytań, które przebijają się przez szum.
Czy ten agent wchodzi w interakcję z istniejącymi agentami? Jeśli nowy agent odczytuje wyniki lub zapisuje dane wejściowe do istniejącego agenta, znajdujesz się już na terytorium orkiestracji. Interakcja musi być zaprojektowana, nie emergentna.
Czy mogę atrybuować jego koszt do konkretnego wyniku biznesowego? Jeśli nie możesz odpowiedzieć na to pytanie dla proponowanego agenta, dodajesz nieprzejrzystość. Każdy agent, którego nie możesz atrybuować, jest generatorem szumu w raportowaniu kosztów.
Czy dzieli stan z innymi agentami? Jeśli nowy agent potrzebuje dostępu do danych, które inni agenci produkują lub konsumują, potrzebujesz infrastruktury współdzielonego stanu.
Czy mogę monitorować go niezależnie? Nie tylko czy działa — czy jego wyniki są poprawne, czy jego wskaźnik błędów mieści się w granicach. Jeśli nie możesz to zmierzyć, nie możesz tego poprawić.
Czy mogę odpowiedzieć „którzy agenci produkują wartość" dla wszystkich moich obecnych agentów? Jeśli nie możesz odpowiedzieć na to dla istniejących agentów, już przekroczyłeś próg. Problem 10 agentów nie dotyczy konkretnie 10. agenta — dotyczy luki w możliwościach, która kumuluje się wraz z dodawaniem agentów. 10. agent to po prostu moment, gdy luka staje się niemożliwa do zignorowania.
Zasada praktyczna: jeśli dodajesz 8. agenta i będzie on wchodził w interakcję z którymkolwiek z poprzednich 7, zainwestuj w infrastrukturę orkiestracji przed 10. Koszt zbudowania jej retroaktywnie jest znacznie wyższy niż zbudowanie jej proaktywnie.
Rzeczywisty koszt progu
Narzędzia monitoringu mogą kosztować więcej niż same agenci przy skali.
W jednej organizacji z 23 agentami miesięczny koszt narzędzi do monitoringu i observability wynosił 1,3x kosztu platformy agentowej. Monitoring nie był nawet dobry — generował wystarczająco dużo alertów, że zespół rozwinął alert fatigue i przeoczył rzeczywiste awarie.
Podatek koordynacyjny to drugi konsekwentnie niedoszacowany koszt. W jednym zespole osoba utrzymująca infrastrukturę agentową spędzała 60% swojego czasu na koordynacji — pisaniu kodu integracyjnego między agentami, debugowaniu awarii między agentami, utrzymywaniu mapy systemu — i 40% na rzeczywistej pracy, którą agenci mieli wykonywać.
I szczera uwaga: dla większości firm SMB pozostanie poniżej 10 agentów z czystymi rozwiązaniami punktowymi jest właściwym wyborem architektonicznym. Infrastruktura orkiestracji wymagana do niezawodnego uruchamiania 10+ agentów to znacząca inwestycja. Jeśli Twój przypadek użycia może być obsługiwany przez siedmiu agentów, z których każdy dobrze wykonuje jedną rzecz, nie potrzebujesz orkiestracji.
Sygnał, który mówi, że go przekroczyłeś
Gdy nie możesz odpowiedzieć „którzy agenci produkują wartość?" — to wtedy go przekroczyłeś.
Nie gdy osiągniesz agenta numer 10. Gdy pytanie o atrybucję staje się nieodpowiedzialne.
Jeśli zbliżasz się do tego momentu, inwestycją jest infrastruktura orkiestracji: routing, stan, obsługa błędów, atrybucja, monitoring. Zespoły, które skalują się ponad 10 agentów z sukcesem, to te, które potraktowały 8. lub 9. agenta jako moment, gdy celowa architektura staje się konieczna.