Orchestrace více agentů: 30 000 řádků, 150k tokenů

V září 2026 jsme dokončili upgrade MCP, který sáhl zhruba na 30 000 řádků kódu. Skončil s asi 150 000 tokeny v kontextu. Práci si rozdělilo pět subagentů běžících paralelně, každý na své části změny.

Zajímavé číslo není počet řádků. Zajímavé je to číslo, které zůstalo malé. Kdyby třicet tisíc řádků zpracovával jeden dlouho běžící agent, sezení by se zahltilo dávno před koncem. Obvyklá odpověď na to zní: počkejme si na větší kontextové okno. Je to špatná odpověď. Tady pomohlo něco jiného, totiž jinak rozvržená práce. A to rozvržení stojí na třech pravidlech, která můžete převzít, aniž byste si pořizovali cizí framework.

Agent, který píše kód, ztrácí kvalitu dávno předtím, než mu dojde kontextové okno. Při práci s Claudem vidíme, že se výstupy začnou zhoršovat kolem 500 000 tokenů kontextu. Je to naše vlastní pozorování, ne benchmark. Od té hranice se odpovědi vzdalují tomu, co je v repozitáři. Praktické pravidlo, podle kterého pracujeme, zní: zůstat zhruba pod polovinou dostupného okna a zbytek brát jako rezervu, ne jako kapacitu.

Zní to jako plýtvání, dokud neuvidíte, co se za tou hranicí děje. Model neohlásí, že přestal sledovat rozhodnutí, které padlo před dvěma hodinami. Odpovídá dál a pořád stejně sebejistě, a zaplatí to ten, kdo pak čte diff. Tento způsob selhání už má jméno, context rot, a dá se shrnout jednou větou: dlouhé sezení není dlouhá paměť.

Rozpočet je tedy daný, objem práce ne. Zbývá jediná proměnná, totiž kdo drží kterou část kontextu.

Uspořádání má tři úrovně. Nejdůležitější jsou ty dvě horní.

Vrstva 0 je obyčejný chat s člověkem. Existuje proto, aby se vyjasnil záměr, ne aby vznikal kód. Výstupem té konverzace je prompt ušitý na míru agentovi, který práci odvede. Když ho napíšete jako vědomý krok, ta mlhavá polovina úvah se do pracovního kontextu vůbec nedostane. Alternativou je napsat první verzi zadání rovnou do sezení, které ho bude vykonávat.

Vrstva 1 je orchestrátor. Odpovídá za plán i za review. Samotnou funkcionalitu nepíše.

Pod ním sedí dev subagenti a review subagenti. Orchestrátor je spouští, každého s úzkým zadáním a s kontextem, ve kterém je jen to, co daný úkol potřebuje. To je orchestrace AI agentů v běžném smyslu slova, s jedním podstatným rozdílem. Subagenti jsou jednorázoví, orchestrátor ne. Když dev subagent skončí, jeho kontext zmizí. Přežije jen to, co se stihlo zapsat.

Orchestrátor napíše podrobný plán v markdownu a prochází ho v několika kolech, ještě než se rozběhne první dev subagent. V tom pořadí je celý trik. Ten krok se snadno vynechá, protože vypadá jako zdržení.

Když spustíte agenty dřív, narazíte na selhání, které zná každý. Dev agent dostane polovičaté zadání, začne psát kód, narazí na připomínky z review a okamžitě na ně reaguje. Říkáme tomu panika. Agent bere každý komentář jako příkaz. Pak nekontrolujete práci, ale reakci na ni.

Plán vyladěný na vrstvě 1 to z velké části odstraní. Dev subagent už totiž nerozhoduje o tom, co je vlastně úkol. Vykonává rozhodnutí, které má písemnou podobu.

Dev agent, který dostane výstup z review, si ho nejdřív roztřídí na důležité a nedůležité. Teprve potom sáhne do kódu.

Vypadá to jako formalita, ale není. Komentáře z review přijdou jako jeden seznam bez priorit. Skutečná chyba ve funkčnosti stojí vedle názoru na pojmenování proměnné a vedle návrhu, kterým si recenzent sám nebyl jistý. Člověk si takový seznam přebere, aniž by si toho všiml. Agent ne. Bez třídicího kroku ho projde popořadě a se stejným nasazením u každé položky. Vážný nález tak dostane stejnou pozornost jako drobná výtka.

Brání to přesně tomu selhání, které jsme popsali výš. Agent, který na připomínku reaguje ve chvíli, kdy dorazí, začne psát kód dřív, než si vyhodnotí, jestli na ní vůbec záleží.

Každý agent v tomto uspořádání zapisuje svou specifikaci, plán a postup do samostatných souborů, které git nesleduje. Orchestrátor si vede vlastní soubor s postupem.

Důvodem je obnova po přerušení. Přerušené sezení, vyčerpaný limit kontextu, uspaný počítač. Když máte jen chat, ve všech třech případech začínáte vysvětlovat znovu. Se stavem na disku si další běh přečte, kam se práce dostala, a pokračuje. Díky souborům je navíc práce čitelná pro člověka i za běhu. To oceníte ve chvíli, kdy se něco pokazí a vy potřebujete zjistit, co si agent myslel, že dělá.

Sofie Meyer, další kolegyně z týmu, potvrdila totéž z vlastní práce. Není to tedy teorie od stolu. Vede si oddělený plán v markdownu, který agent během práce odškrtává, a v praxi jí to fungovalo dobře. Dva lidé, kteří popisují stejný postup, jsou slabý důkaz. Je to ale druh důkazu, kterému věříme víc než README nějakého frameworku.

Rozdělením práce mezi subagenty ušetříte kontext. Kontext ale není jediné omezení.

Špatně zadaný úkol tím nezachráníte. Když z vrstvy 0 vyjde mlhavý prompt, orchestrátor sebevědomě naplánuje špatnou věc a pět subagentů ji postaví paralelně, rychleji, než by to zvládl jeden.

Review to nenahradí. Všechna tři pravidla řeší, jak dostat lepší vstup k lidskému recenzentovi, ne jak se ho zbavit. Všechno, co běžně děláme kolem agentních workflow, platí dál.

A nedá se to použít na každý úkol. Změnu na 30 000 řádcích jde rozdělit čistě, protože se skládá z částí. Zamotaný refaktoring, kde každý soubor závisí na všech ostatních, se rozdělit nedá. Když se o to přesto pokusíte, vyrobíte hlavně merge konflikty mezi agenty.

Pokud si z článku chcete odnést jednu věc, ať je to pravidlo třetí. Zapisovat plán a postup do souboru je desetiminutová změna v tom, jak promptujete. Když sezení proběhne dobře, nestojí vás nic. Když ne, zachrání vám ho celé.

Pravidla jedna a dvě jsou větší krok. Znamenají postavit něco, co drží plán a třídí připomínky, a to už je kus skutečné inženýrské práce. Právě to pořadí ale udrží rozpočet tokenů v mezích. Kontext zůstává malý, protože každý agent drží jen svůj díl. Celek drží pohromadě soubory a orchestrátor, ne jedna hodně dlouhá konverzace.

Upgrade, kterým tento článek začal, nedokončil chytřejší model. Dokončil ho menší kontext, se kterým se zacházelo pečlivěji. Pokud agentic coding děláte denně a sezení se vám pořád prodlužují, právě tady se vyplatí začít dřív, než se vydáte shánět větší okno.