Chief of Staff pattern: jak řídit dlouhé běhy Claude Code a výsledku skutečně věřit
Jedna relace Claude Code funguje skvěle hodinu. Pak se začne rozpadat. Kontext se zkracuje, detaily z před dvou hodin přežijí jen jako shrnutí a agent, který hlásí „testy prošly", už dávno nehlásí pozorování — hlásí vzpomínku na svůj záměr. Přidáš víc agentů a problém se znásobí: pět nespolehlivých reportérů a nikdo, kdo by je vyrovnával.
Řešení není technické, ale organizační. Jedna dlouhožijící relace koordinuje, verifikuje a drží stav — a samostatné krátké relace dělají implementaci. Vzor se jmenuje orchestrator-worker (také coordinator-implementor-verifier nebo maker-checker) a jeden tým mu začal říkat Chief of Staff. Název si nemusíš pamatovat, disciplínu, která za ním stojí, ano. Je to nejdůležitější chybějící kousek, pokud chceš nechat agenty pracovat přes noc — a na rozdíl od dohledu, kdy druhá AI hlídá první, jde o systém, který verifikuje výsledky, ne záměry.
Proč jedna relace na dlouhé úlohy nestačí
Rozpad má tři příčiny a žádná se netýká inteligence modelu:
- Kontext je konečný a ztrátový. Kompakce zahodí specifics, které dělaly detail užitečným.
- Self-reporty se odchylují od reality. Čím delší relace, tím větší mezera mezi „co jsem chtěl udělat" a „co jsem udělal".
- Nic se nekumuluje. Lekce naučená bolestivě ve druhé hodině je do další relace pryč, pokud ji někdo nezapsal tam, kde si ji příští relace přečte.
Klíčové poznání: generování kódu nikdy nebylo bottleneck. Bottleneck je kontrola. Proto vzor odděluje orchestraci od exekuce — koordinátor kód nepíše, protože v momentě, kdy začne implementovat, přestává verifikovat a celá struktura se hroutí do jedné přetížené relace.
Tři komponenty, které potřebuješ
Konkrétní nástroje jsou vyměnitelné, role ne:
- Agent runtime — Claude Code: relace, nástroje, editace souborů, shell, messaging mezi relacemi. Každá relace má vlastní kontextové okno a izolace je feature, ne chyba.
- Substrát relací — cmux nebo cokoli scriptovatelného, čímž spustíš novou exekuční relaci programově. Jeden detail, který stojí reálný čas:
--commandposílá text do shellu workspace, nespouští agenta. Agent musíš vyvolat explicitně (claude "Přečti docs/briefs/current.md a udělej přesně to, co tam je."), jinak se instrukce jen vypíše do shellu a launcher přesto ohlásí úspěch. - Trvalý stav — deska úkolů. Plan Desk, Jira, cokoli s API nebo MCP, co agent dosáhne. Tohle lidé vynechávají a proto jejich multi-agent setupy nepřežijí noc. Sesny jsou jednorázové, deska ne. Deska je paměť systému.
Na desce žijí: tasky jako build kontrakty (problém, akční kroky, interface, validační kontrakt, non-goals — dost detailů, aby exekuční relace nikdy nemusela číst nadřazený dokument), status, který se překlápí atomicky s prací (in_progress v momentě startu, done v momentě verifikace — nikdy hromadně na konci), a design dokumenty provázané s tasky, které řídí.
Operační smyčka
Jedna položka práce. Jeden dispatch. Jeden commit.
- PULL — vytáhni další neblokovaný task z desky
- READ — přečti provázaný design dokument dřív, než se něčeho dotkneš
- RED GATE — pusť verifikátor nejdřív: musí selhat
- DELEGATE — deleguj na exekuční relaci (nebo si to postav sám)
- PROVE — přepusť každý claimnutý příkaz; rozhodují exit kódy
- OBSERVE — čti diff hunk po hunku
- GATE — vyřeš approval lane s uvedeným zdůvodněním
- SHIP — překlop status, commitni jen tu položku, zaznamenej progres
Proč red gate první
Pokud je kontrola zelená ještě před startem, práce nedokazuje nic. Nerozeznáš správnou implementaci od kontroly, která se nikdy nespustí, filtru, který nic nematchuje, nebo testu asertující něco už pravdivého. Red gate navíc levně odhalí zastaralou práci: nemalá část fronty tasků se ukáže jako už hotová — postavená pod jinou kartou nebo zrušená pozdější změnou. Zelený red gate stojí jeden příkaz a ušetří hodinu čtení kódu pro něco, co už existuje.
Proč jeden commit na položku
Git historie zůstane 1:1 s deskou. Každý commit subject jmenuje svůj task. Když se něco rozbije za tři dny, cesta od symptomu k rozhodnutí je jeden git log daleko.
Verifikační disciplína: srdce vzoru
Tohle odlišuje metodologii od „pusť pár agentů najednou".
Hlášení je důkaz, ne instrukce. Když exekuční relace hlásí „suite zelená, 49 kontrol, nula selhání", úkolem koordinátora je zjistit, jestli je to pravda. Ne proto, že agenti lžou — ale protože věc, na kterou reportují, a věc, kterou kontrolovali, jsou často dva různé objekty. Reálný příklad: relace zapsala commit hash ručně do logu a pak ho verifikovala git cat-file proti short hash ve svém shellu — ne proti stringu, který tam zapsala. Obě kontroly prošly. Soubor obsahoval hash, který nikam nevedl. Pravidlo: verifikuj artefakt čtením hodnoty zpět z artefaktu, nikdy z proměnné, o které si myslíš, žes ji tam zapsal.
Defect class, na kterou si dát pozor
Nejčastější selhání v agentním inženýrství: instrument, který hlásí úspěch pro práci, kterou neudělal.
| Podoba | Jak vypadá | Jak tě zmátne |
|---|---|---|
| Prázdná aserce | Test, který projde, ať feature funguje nebo ne | Smaž testovanou věc a zůstane zelený |
| Tiché no-match | Grep nebo filtr, který nic nematchuje | Nula nálezů vypadá jako „čisto" |
| Chybný check | Příkaz, který se vůbec nespustil | Chyba se spolkne, absence vypadá jako důkaz |
| Špatný reference | Filtr klíčovaný na „novější než X" | Co proběhlo mezi, proklouzne |
| Zastaralý premise | Očekávaná hodnota přečtená z rozbitého kódu | Projde bug, který měl chytat |
| Scope mismatch | Zelená kontrola nad podmnožinou prezentovaná jako celek | Jmenovatel se nikdy neuvádí |
Obecná obrana: každá kontrola, která může selhat v nematchování, to musí říct. Nula a „neproběhlo" musí být rozlišitelné. A absence potřebuje pozitivní kontrolu ve stejném běhu — než uvěříš negativu, dokaž pozitivu: nasměruj check na známý dobrý případ. Nástroj, který hlásí „čisto", a nástroj rozbitý produkují identický výstup.
Trvalé kanály místo efemérních
Relace si můžou posílat zprávy přímo a je to užitečné — tak koordinátor odpoví na otázku nebo exekutor nahlásí rozpor. Ale není to spolehlivé: zpráva se může zařadit za zaneprázdněnou relaci, zadržet ve schvalovacím režimu nebo expirovat nedoručena. Mlčení není souhlas. Cokoli, co musí dojít, jde trvalým kanálem: commitnutý soubor, karta na desce, komentář. Zpráva je postrčení, soubor je kontrakt.
Launch prompt drž krátký a ukazuj na soubor (Context: <url> místo vkládání kontextu). Dlouhé command stringy nespustíš spolehlivě; reviewovatelný brief v commitu je znovu spustitelný.
Timeboxing: reportuj, ale nezastavuj se
Interval rozhoduje, jak často se hlásíš, nikdy kde práce končí. Když timer vyprší uprostřed položky, dokonči ji, verifikuj, commitni, pak reportuj. Půlit běh uprostřed tasku uvízne v nejtěžším stavu: napůl aplikováno, neverifikováno, nepopsatelně. Checkpoint je moment hlášení, ne žádost o povolení — pokud chytáš sebe, jak píšeš „mám pokračovat?", smaž to. Člověk, který sleduje, přeruší; člověk, který nesleduje, ti právě zabil běh otázkou. Reportuj, co je prokázáno, ne co bylo zkuseno: položka bez verifikačního výsledku se nese, nedokončuje.
Mechaniky, které stojí reálný čas
- Ověř, že spuštěná relace běží. Launcher nahlásí „workspace created", což není totéž jako běžící agent. Checkni proces a jeho pracovní adresář — a referenční timestamp zachyť těsně před spuštěním, jinak filtr „novější než poslední relace" rád připustí nesouvisející relaci.
- Jména relací nejsou adresy. Před oslovením relace znovu vypsat živé seznamy; zkrácené ID z desky není klíč — doplnit ho na plnou délku vyrobí well-formed hodnotu, která neexistuje. Hledej substring výrazného labelu.
- Ve sdíleném working tree nikdy bare commit.
git add <path>+git commitcommitne celý index včetně věcí, které mezitím nastagovala souběžná relace. Použijgit commit -- <paths>.
Kdy to použít — a kdy ne
Použij, když: práce přesahuje jedno kontextové okno, streamy můžou běžet paralelně, chybné „hotovo" je dražší než pomalé, a projekt přežije paměť jedné relace. Nepoužívej, když: jde o jeden dobře vymezený change (jedna relace, nula ceremonií), když si nemůžeš dovolit režii (pattern reálně spotřebovává tokeny na verifikaci, která negeneruje kód), nebo když nemáš trvalé úložiště — bez něj neřídíš tento vzor, jen pustíš pár relací a doufáš.
Režie je smysl. Kupuješ si možnost výsledku věřit.
Jak začít tento týden
- Postav trvalou desku — jeden projekt, pár cílů, tasky s dependency hranami, dostupné přes API/MCP.
- Napiš kontrakt do jednoho souboru: smyčka, definice „hotovo", standardy. Commitni. Každá relace ho čte při startu.
- Pusť jednoho koordinátora a jednoho exekutora. Ne šest. Získej verifikační smyčku poctivou se dvěma.
- Přidej handoff artefakt — soubor, který koordinátor aktualizuje na konci každé relace o aktuální stav a lekce. Tohle dělá, že se relace kumulují.
- Veď log lekcí. Když tě něco překvapí, zapiš to tam, kde si to příští relace přečte — dřív, než skončí.
Míra úspěchu není, kolik kódu vznikne. Je to, jestli se můžeš kdykoli zeptat „jaký je stav této práce?" a dostat odpověď, která je pravda. Když tě agenti na dlouhých úlohách zklamají, instinkt sáhne po lepším modelu nebo většímu oknu. Obojí pomáhá, ani jedno neřeší skutečné omezení: že nikdo nekontroluje. Koordinující relace, která napíše nula řádků kódu, ale ví, co je pravda, je víc než další exekutor. Je to stará lekce z lidských organizací — a funguje i tady.
