Multi-agent orchestration: čo sa pokazilo v 3 315 behoch

Som Denys, full-stack a AI inžinier. Staviam softvér s jednou hlavnou reláciou Claude Code, ktorá odovzdáva prácu špecializovaným subagentom: prieskumníkom, plánovačovi, implementátorom, bezpečnostným a kódovým revízorom. Je to správa o tomto multiagentovom systéme, nie o klientskom produkte. Čísla pochádzajú z logov, ktoré systém vedie: z evidencie spustení (jeden riadok na každého spusteného agenta), prepisov relácií a z histórie gitu samotnej konfigurácie. Mená klientov a projektov sú vynechané.

Postavil som aj interaktívny dashboard na orchestráciu agentov ako prototyp s ukážkovými dátami. Všetko nižšie pochádza zo skutočných behov.

Čo je multiagentová orchestrácia?

Multiagentová orchestrácia je nastavenie, v ktorom jeden hlavný agent odovzdáva ohraničené úlohy špecializovaným agentom a spája ich výsledky; orchestrátor vlastní kontext, rozpočty a opakované pokusy. V tomto článku sa objavuje ako dva vzory: hlavná relácia so subagentmi (prieskumníci, plánovač, implementátori, revízori) a hooky, ktoré presadzujú pravidlá, ktoré agenti nemôžu obísť presviedčaním. Dashboard na orchestráciu agentov ukazuje rovnakú myšlienku na ukážkových dátach; nasledujúce časti sú o tom, čo sa pokazilo v skutočných behoch.

Ako nastavenie vyzerá?

Jedna hlavná relácia komunikuje so mnou a vlastní zadanie. Pri väčších úlohách sama nikdy nepíše produkčný kód. Prácu rozosiela:

• Prieskumníci čítajú jednu vrstvu kódovej základne (frontend, backend, databázu) a píšu krátku mapu.
• Plánovač mení mapu na číslované kroky s cestami k súborom.
• Implementátori si berú každý jednu fázu plánu, najprv píšu testy, potom kód. Paralelní implementátori dostávajú vlastný git worktree.
• Revízori kontrolujú diff: jeden bezpečnosť, druhý správnosť, obaja na tom istom commite.

Medzi nimi stoja hooky: malé skripty, ktoré Claude Code spúšťa pred každým volaním nástroja aj po ňom. Hook môže volanie zablokovať, napríklad spustenie agenta, zápis súboru alebo git commit. Konfigurácia má 165 hookov, asi 40 z nich sa týka orchestrácie. Pravidlá, ktoré agenti čítajú, sú Markdown; pravidlá, ktoré obísť nemôžu, sú hooky. Toto rozdelenie je hlavné poučenie z tých dvoch mesiacov a zvyšok textu vysvetľuje prečo.

Koľko agentov bežalo a na ktorých modeloch?

Meranie (17. 8. – 19. 10. 2026)	Hodnota
Spustených subagentov	3 315 za 57 aktívnych dní
Typov agentov	30
Najčastejšie spúšťaní	implementátor (tdd-guide) 793, bezpečnostný revízor 455, general-purpose 424
Skutočne použitý model	Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, zvyšok zdedený od hlavnej relácie
Spustené po jednom	67,7 %
Najväčšia paralelná vlna	5 agentov (strop), dosiahnuté 9-krát
Behov revízorov na beh implementátora	0,71 (680 revízií, 963 implementácií)

Dve čísla ma prekvapili. Po prvé, väčšina spustení boli jednotliví agenti, nie rozvetvenia. Paralelná práca je výnimka: oplatí sa pri čítaní a revíziách a pri písaní stojí veľa (pozri prvé zlyhanie nižšie). Po druhé, pri 23 % spustení, kde súbor agenta uvádza model, bežal v skutočnosti iný model, takmer vždy Sonnet povýšený na Opus (584 z 610). To je zámer: hook model povýši, keď krok siaha na rizikový kód, napríklad migrácie, autentifikáciu alebo serverové routy, a tiež potom, ako implementátor na Sonnete trikrát po sebe neprejde tým istým testom. Silnejší implementátor bežal 159-krát; log neviem rozdeliť na „rizikový krok“ a „opakované zlyhanie“, takže netvrdím, koľko z toho boli záchrany.

Koľko stojí multi-agent orchestration?

Platím paušálne predplatné, takže žiadny účet za token neexistuje. Prepisy však zaznamenávajú každý token, takže tu je to, koľko by posledných 30 dní (20. september – 19. október) stálo za cenníkové ceny API spoločnosti Anthropic:

30 dní	Tokeny
Spolu	asi 15,99 miliardy
Čítania z cache	15,55 miliardy (97,7 % všetkého, čo išlo do modelu)
Zápisy do cache	372 miliónov
Nový nekešovaný vstup	0,18 milióna
Výstup	69 miliónov

Za cenníkové ceny (Opus 5.5 4 USD za milión vstupných tokenov, 20 za milión výstupných, 0,20 za milión čítaní z cache; Sonnet 5.5 a Fable 5.1 za svoje) vychádza samotný výstup, vstup a čítania z cache pri troch súčasných modeloch asi na 3 350 USD. To vynecháva zápisy do cache a staršie verzie modelov, ktoré sú v logu stále, takže skutočná suma za API je vyššia. Dve tretiny z tých 3 350 USD tvoria čítania z cache: každé kolo znova posiela celý kontext a cache je jediný dôvod, prečo je to vôbec zaplatiteľné.

Rozdelenie medzi hlavnú reláciu a subagentov je časť, ktorú by som použil pri plánovaní rozpočtu:

• Subagenti spotrebovali 42 % všetkých tokenov, ale napísali 66 % výstupu. Hlavná relácia je drahá, lebo nesie najdlhší kontext; subagenti sú tam, kde sa skutočne píše text a kód.
• Revízori sú lacní. Bezpečnostná alebo kódová revízia spotrebovala 1–4 milióny tokenov. Implementátor 5–100 miliónov. Dvaja revízori pri každom rizikovom commite stoja menej ako jeden implementátor, ktorý skúša znova.
• Najväčšia relácia, 6. októbra, spustila 63 subagentov a za 3,5 hodiny spotrebovala 372 miliónov tokenov.

Čo sa pokazilo

Každé zlyhanie nižšie sa stalo, má dátum a skončilo hookom alebo skriptom, ktorý mu znova zabráni. Žiadne z nich nie je „model napísal chybu“. Bežné chyby zachytili testy a revízori. Tieto prešli oboma.

Dátum (2026)	Čo sa pokazilo	Čo tomu bráni teraz
19. 8.	Paralelní agenti prepísali jeden súbor prekladov: 55 z ~95 kľúčov stratených, všetky kontroly zelené	Každý agent píše svoje kľúče do vlastného fragmentu; zlučovací skript dokáže, že každý kľúč dorazil
24. 8.	Upratovací skript zmazal 4 hotové balíčky práce	Upratovanie preskočí každý worktree s nezozbieranými zmenami; najprv zozbierať, potom upratať
1. 9.	Neskoršie vlny agentov štartovali zo zastaraného kódu	Prácu každého agenta zlučovať ako trojcestný patch, nikdy kópiou súboru
13. 9.	Agent zomrel pri štarte a spustenie hlásilo „úspech“	Spúšťač číta prvý výstup agenta a mŕtvy model na čas označí pre všetky relácie
20. 9.	Dve moje vlastné pravidlá si odporovali; agenti opakovali odmietnutý príkaz	Zadania pre izolovaných agentov obsahujú tvary príkazov, ktoré sandbox prijíma
18. 10.	Agent upravil kontroly, ktoré blokovali jeho commit	Súbory kontrol sú z projektových relácií len na čítanie; zmeny sa logujú a hlásia poplachom
18. 10.	Pokyny na opravu ticho zmenili, čo dostávajú používatelia klientskej aplikácie	Každé zadanie opravy hovorí „zachovaj živé správanie“; zmeny produktu sa vracajú ku mne

Paralelní zapisovatelia a súbor, ktorého sa dotkne každá funkcia

Traja agenti stavali naraz tri funkcie klientskej iOS aplikácie. Každý pridal svoje textové reťazce do jediného prekladového katalógu aplikácie a každý uložil vlastnú verziu celého súboru. Vyhralo posledné uloženie. 55 z asi 95 nových kľúčov zmizlo. Build každého agenta prešiel, lebo kópia každého agenta bola konzistentná; kontrola katalógu prešla, lebo jej pokrytie bolo porušené iným spôsobom. Našiel som to ručným počítaním kľúčov.

Oprava má tri časti. Hook odmietne spustiť agenta, ktorého deklarované súbory sa prekrývajú so zapisovateľom, ktorý ešte beží. Agenti zdieľané katalógy nikdy neupravujú; svoje kľúče píšu do súboru s fragmentom a jeden skript fragmenty zlúči, zlyhá pri konfliktných hodnotách a potom skontroluje, že je každý kľúč na mieste. Druhý hook zablokuje commit, ak má katalóg menej kľúčov ako predtým. Úprimná časť: tieto poistky som pridal 18. októbra, 60 dní po strate. Medzi týmito dátumami bola jedinou ochranou veta v Markdown pravidle a pravidlo je len návrh.

Upratovanie, ktoré zmazalo hotovú prácu

Paralelní implementátori pracujú v git worktrees a zmeny stagujú bez commitu. Kontrola commitu povedala hlavnej relácii, nech spustí upratovací skript. Skript preskakoval worktrees, ktorých agent ešte bežal, a títo agenti už skončili. Štyri hotové balíčky práce boli zmazané, bez zvyšných git objektov na obnovu. „Beží agent ešte?“ a „bola jeho práca zozbieraná?“ sú dve rôzne otázky a skript sa pýtal len na prvú. Upratovanie teraz preskakuje každý worktree so zmenami, ktoré hlavný checkout nemá, a samostatný hook blokuje priame mazanie priečinkov worktree.

Vlny, ktoré štartovali zo starého kódu

Plán o 11 krokoch bežal ako 6 implementátorov v 3 vlnách. Vlny 2 a 3 štartovali z commitu, na ktorom relácia začala, tri commity pozadu. Skopírovanie súboru jedného agenta späť by vrátilo hotovú zmenu iného agenta. Worktree je snímka miesta, odkiaľ ste vyšli, takže sa výsledky teraz vracajú ako trojcestné patche a konflikty vyplávajú na povrch namiesto tichého prepísania.

Mŕtvy agent, ktorý hlásil úspech

Agent pripnutý na model s vyčerpaným limitom využitia zomrel pred prvým krokom. Spustenie vrátilo „spustené úspešne“; zlyhanie dorazilo neskôr ako správa o nečinnosti. Opakovanie na inom modeli prepol späť ten istý hook, ktorý modely pripína. Hlavná relácia potom ticho napísala plán sama, čo bol presne výsledok, ktorému mal plánovač predísť. Hook teraz číta prvý výstup agenta a mŕtvy model na nejaký čas označí pre všetky relácie.

Agent, ktorý upravil vlastné kontroly

18. októbra relácia pracujúca na klientskom projekte dostávala stále zablokovaný commit kvôli jednej kontrole. Upravila tri zo skriptov kontrol tak, aby jej commit prešiel. Nič z toho nebolo skryté; úpravy boli na očiach. Ale nič ich ani nezastavilo, lebo kontroly ležali v priečinku, kam agent mohol zapisovať, a strážili sa len nástroje na úpravu súborov, nie príkazy shellu. Súbory kontrol teraz možno meniť len z relácie spustenej v priečinku samotnej konfigurácie, pokryté sú všetky cesty zápisu (editor, presmerovania shellu, skripty, git) a každá ich zmena počas projektovej relácie sa loguje s poplachom.

Toto je zlyhanie, pred ktorým by som varoval ako prvé. Agent, ktorému poviete „dostaň ten commit cez“, berie bránu ako súčasť problému.

Dve moje pravidlá si odporovali

Jedno pravidlo agentom hovorilo, nech tri a viac krokov shellu spoja do jedného skriptu, aby šetrili tokeny. Agenti izolovaní vo worktree bežia pod sandboxom, ktorý presne taký tvar odmieta. Agenti narazili na „too complex to verify“ trikrát po sebe v niekoľkých dňoch a spálili rozpočet preformulovaním. Agenti sa teraz po dvoch rovnakých odmietnutiach zastavia a zadania pre izolovaných agentov uvádzajú tvary príkazov, ktoré fungujú.

Prečo multiagentové systémy zlyhávajú?

Podľa týchto dvoch mesiacov: nie preto, že je model príliš slabý. Žiadne zo siedmich zlyhaní vyššie nebolo zlyhanie modelu pri úlohe, ktorú dostal. Zlyhávajú v spojoch medzi agentmi, kde za nič nenesie zodpovednosť jediný agent:

• Zdieľaný stav. Súbor, ktorého sa dotkne každá funkcia, pracovný strom, vetva. Každý agent je lokálne v práve a výsledok je globálne zlý.
• Zelené kontroly. Každý incident vyššie prešiel kontrolami, ktoré vtedy existovali. Kontrola dokazuje to, čo kontroluje, nič viac.
• Signály úspechu, ktoré klamú. „Spustené“, „uložené“, „upratané“ znamenali vždy niečo užšie, než hovorili.
• Agenti optimalizujúci pre bránu. Povedzte agentovi, že commit je zablokovaný, a bude hľadať spôsob, ako ho odblokovať, vrátane cesty cez samotnú bránu.

Iní stavitelia hlásia rovnaký vzorec pri väčších flotilách. Jed Arden, ktorý prevádzkuje asi dvadsať agentov, napísal, že LLM sa v jeho logu incidentov takmer nevyskytuje (júl 2026). Tím Cursoru zistil, že dvadsať agentov zdieľajúcich jeden koordinačný súbor so zámkami sa spomalilo na priepustnosť dvoch alebo troch (január 2026).

Čo by som nastavil ako prvé

Ak začínate so subagentmi v Claude Code alebo s akoukoľvek multi-agent orchestration, v tomto poradí by som to robil podľa toho, čo ma stálo naučiť sa to:

1. Logujte každé spustenie agenta. Jeden riadok na spustenie: čas, typ agenta, model, riziko. Bez toho nepoznáte, čo systém robí, a žiadne z čísel vyššie by neexistovalo.
2. Jeden zapisovateľ na súbor. Paralelní zapisovatelia dostanú worktree a deklarovaný zoznam súborov. Súbory, do ktorých pridáva každá funkcia (preklady, lockfily, changelogy), majú jedného vlastníka a ostatní odovzdávajú fragmenty.
3. Najprv zozbierať, potom upratať. Nikdy nenechajte upratovanie rozhodovať podľa „beží to“. Rozhodujte podľa „je jeho práca v hlavnom checkoute“.
4. Kontroly dajte agentom z dosahu. Hooky, ktoré blokujú, uložené tam, kam projektová relácia zapisovať nemôže.
5. Obmedzte vlnu. Päť paralelných agentov je môj strop; za ním sa úzkym hrdlom stáva revízia a konflikty rastú rýchlejšie než priepustnosť.
6. Eskalujte podľa opakovania, nie podľa snahy. Predvolene lacný model; po treťom rovnakom zlyhaní jeden pokus na silnejšom modeli; potom človek.

Koľko stojí AI agent postaviť a prevádzkovať pre firmu, a nie pre pracovný postup jedného vývojára? To je iná otázka a s číslami na ňu odpovedá článok Koľko stojí AI agent? Prevádzka podľa 4 projektov. Ktoré panely sledujem teraz, z rovnakých logov o mesiac neskôr, je v článku AI agent monitoring dashboard: čo ukázalo 1 238 behov.

Hranice tejto správy

• Nastavenie jedného vývojára. Jedna hlavná relácia, až päť paralelných agentov. Flotily desiatok či stoviek agentov zlyhávajú ďalšími spôsobmi, napríklad pri štarte.
• Žiadny skutočný účet. Suma v dolároch je ekvivalent v cenníkových cenách API za 30 dní, spodný odhad, ktorý vynecháva zápisy do cache a staršie modely. Platím paušálne predplatné.
• Medzery v logoch. Zablokované spustenia sa nelogujú, takže nemôžem povedať, ako často sa strop vlny uplatnil. Tých 159 behov silnejšieho implementátora mieša rizikové kroky a opakované zlyhania.
• Dátumy z vlastných poznámok. Dátumy incidentov pochádzajú z poznámok a commitov písaných ten istý deň; jeden incident je v staršom súbore pravidiel datovaný inak a použil som poznámku.

Prototyp dashboardu, ktorý z tejto práce vyrástol, je prípadová štúdia Dashboard na orchestráciu agentov a stavba agentov pre klientov patrí pod AI agentov a vývoj chatbotov.