Anthropic nedávno přidal do Claude Code nový slash příkaz /goal – zadáte cíl, odejdete pryč a vrátíte se k hotovému diffu. Plně autonomní agentní režim v té nejpřímější podobě. Miodrag Todorović, spoluzakladatel JigJoy, posledních pár měsíců staví nástroj jménem baro – CLI, které dělá v podstatě totéž, jen jinak. Místo jednoho Claude sezení spouští DAG paralelních sezení, každé řeší kus práce a všechna komunikují přes sdílenou event bus knihovnu Mozaik.

Na papíře to vypadá jako jasná výhra paralelismu. Realita byla jiná.

Benchmark: stejný úkol, dva přístupy

Testovacím polem byl interní marketplace s inzeráty aut – NestJS + Drizzle + Postgres na backendu, Next.js + shadcn/ui na frontendu. Cílem bylo přesunout ~1 300 řádků hardcodovaných dat o značkách a modelech aut z frontend bundlu do backendového slovníku obsluhovaného malým REST API – středně velký refactor dotýkající se schématu, API, seed dat i frontend komponent.

Soutěžící:

• Claude Code /goal – jedno Opus sezení, plné agentní nástroje, autonomní režim
• baro 0.24 běžící nad Mozaikem s --parallel 5, stejný Opus model pod kapotou

Oba startovaly ze stejné git větve, oba doběhly bez lidského zásahu.

První kolo: paralelismus prohrál

Výsledky byly nepříjemné překvapení. baro strávilo o 6 minut wall time víc a spotřebovalo 2,4x tokenů na stejném úkolu. /goal to zvládl za 21:38 a 81 100 tokenů, baro 0.24 potřebovalo 28:43 a 192 455 tokenů.

A když autor otevřel oba PR a pročetl si reálný kód, propast byla ještě větší. V baro PR se opakovaně objevovaly tři vzorce:

Náhodná regenerace celého schématu. Agent jedné story spustil drizzle-kit generate proti tomu, co považoval za správný stav, a commitnul migraci, která znovu vytvořila všechny tabulky v aplikaci – uživatele, inzeráty, úplně všechno. Bez IF NOT EXISTS. Na produkční databázi by to spadlo na CREATE TABLE "users". Člověk by to chytil za dvě vteřiny.

Self-inflicted rename migrace. Story S2 pojmenovala sloupec normalized_key, story S4 si přečetla PRD pozorněji a použila slug. Pozdější story si všimla nesouladu a poslala pátou migraci, jejíž jediným účelem bylo přejmenovat sloupce, které S2 pojmenovala špatně. Celé tokeny a čas jedné story spotřebované na úklid rozhodnutí, které se mělo udělat za vteřinu.

Závislost, kterou nikdo nechtěl. S10 přidala @tanstack/react-query do package.json. S14 o S10 nevěděla a vyrobila si vlastní cache modul v čistém TypeScriptu. PRD nezmínilo ani jedno. Finální PR má obojí – runtime závislost, kterou specifikace nepožadovala, vedle ručně psané cache, která ji duplikuje.

Špatná diagnóza

Autor měl pracovní hypotézu, baro má problém s exploration overhead. Agenti opakovaně čtou stejné soubory, pouští stejné grepy. Většina toho, co přistálo v baro 0.24, mířila právě sem:

• Knihovník (Librarian) – participant, který indexuje volání nástrojů všech agentů, dostal větší kontextový rozpočet
• Začal broadcastovat nové nálezy běžícím agentům uprostřed práce přes event bus
• Přibyl staggered launch: druhý agent v úrovni DAG startuje 10 sekund po prvním, aby Knihovník stihl zachytit a rozeslat první explorationy

Všechny tři změny dělaly skutečnou měřitelnou práci – token usage klesl o 15-20 % a wall time o pár minut. Ale failure módy, které trápily, se nehnuly. Schema regen pořád byl. Rename sloupců pořád byl. TanStack Query se pořád připatlal nepozván.

Skutečný problém: rozhodnutí, ne koordinace

Když autor postavil tři selhání vedle sebe, společný jmenovatel nebyl exploration. Bylo to, že v každém případě někde padlo důležité rozhodnutí, které nevidělo zbytek práce.

S2 si vybrala normalized_key, protože jí nikdo neřekl, že spec říká slug. S10 přidala TanStack Query, protože jí nikdo neřekl, ať to nedělá. Každé rozhodnutí samo o sobě bylo rozumné. Množina rozhodnutí, naskládaná vedle sebe, byla rozsypaná.

Jedno Claude Code sezení tenhle failure mode nemá. Není to o kvalitě modelu, model je stejný Opus. Jedno sezení drží celý úkol v jednom kontextovém okně. Jakmile tah 1 zvolí slug, tah 12 to pořád ví.

baro tento ekvivalent neměl. Jeho planner sekal cíl na story, ale design nedělal. Každá story šla do práce ze studena a vymýšlela si vlastní odpověď.

Oprava: Architect na sběrnici

Tady se Mozaik vyplatil. Je event-driven, tedy každá část baro je participant na sdílené event bus. Conductor, Story Factory, Story Agent, Critic, Surgeon, Librarian, Sentry, Finalizer – všichni participanti. Nikdo nevolá nikoho přímo, jen se přihlašují k typům událostí a emitují vlastní.

Přidání „upstream rozhodovatele“ tedy nebyla architektonická změna. Byl to nový participant: Architect.

Architect poslouchá RunStartedItem. Když to padne, spustí jeden Claude Opus tah s plným přístupem k nástrojům, přečte existující codebase a emituje DecisionDocumentItem na sběrnici. Ten dokument obsahuje přesné cesty k souborům, názvy schématových polí, tvary API odpovědí, volby knihoven, konvence pojmenování – každé cross-cutting rozhodnutí, které by jinak 16 izolovaných agentů vymýšlelo každý jinak. Pak ztichne. Architect nesleduje běh, nehodnotí story, nepřeplánovává. Udělá svou jednu věc a odejde.

Implementace: ~200 řádků nového kódu v Rust planneru, který spouští Architect proces, parsuje výstup a zaplete dokument do plannerova promptu i do prd.json. Na TypeScript straně se jediná změna týká Conductorovy metody resolvePrompt, která teď před každou story prompt předřazuje dokument pod hlavičkou „Design spec (authoritative)“.

Co autor nemusel dělat: nesahal na Conductor, Story Factory, Story Agent, Critic, Surgeon, Librarian, Sentry, ani Finalizer. Žádný z nich neví, že Architect existuje. Pořád dělají přesně to, co dělali předtím, Architect jen přidává nový obsah do promptů, které stejně staví.

Co by stejná oprava stála jinde

Autor srovnává cenu téhle změny v jiných multi-agentních setupech:

V ručně psaném Promise.all orchestrátoru by se musel rozšířit run, změnit signatura funkce, upravit prompt builder a protáhnout to skrz retry/resume logiku. Orchestrátor vlastní control flow, takže nová fáze je nová větev v něm.

V CrewAI je jednotka kompozice crew se seznamem agentů a tasků. Přidání fáze produkující výstup, na kterém závisí každý další task, znamená definovat nového agenta, nový task, prothreadovat výsledek vlastním delegačním vzorem a změnit, jak ostatní tasky tenhle vstup objevují. Modifikujete topologii, ne ji doplňujete.

V LangGraph je jednotkou state graph. Nový node, nové state field, hrany na správné místo, a každý downstream node musí vědět, že to pole existuje, i kdyby ho nepoužíval.

Žádná z těch změn není sama o sobě obrovská. Ale všechno jsou to změny systému, který už existuje. Mozaikův bus pattern udělal z Architecta čistou adici – každý jiný participant si nechal původní kód beze změny a navíc dostal nové chování zdarma.

Odveta

Stejný repo, stejná startovní větev, stejný cíl. baro 0.25 s Architectem.

Výsledky:

baro 0.25 doběhlo o 4 minuty rychleji než /goal. Migrace: jedna, s IF NOT EXISTS, production-safe. Frontend klient: jeden soubor, ~120 řádků, native fetch s Map cache. Žádné nové runtime závislosti. PR, který by autor reálně schválil.

Paralelní speedup ratio vyskočilo z 1,8x v baro 0.24 na 3,1x v 0.25 – protože agenti jsou opravdu nezávislí, ne potichu si přehrávají práci nebo si šlapou po rozhodnutích.

Tokeny zůstávají asi 28 % nad /goal baseline. To je inherentní cena spuštění vícero Claude procesů – každý si znovu staví kontextové okno. Reálné číslo, ale mnohem menší a řešitelnější problém než decision drift.

Co si z toho odnést

Většina psaní o multi-agent codingu, CrewAI demos, AutoGen swarmy, LangGraph cookbook, se soustředí na to, co se děje během exekuce. Jak spolu agenti mluví, jak sdílejí stav, jak řeší neshody. To jsou férové otázky, ale baro selhání ukázala něco jiného: agenti spolu mluvili dost, jenom se hádali o otázkách, které měly být vyřešeny ještě než se kdokoli z nich probudil.

Malá upstream fáze před swarmem je v podstatě to, jak lidské týmy řeší stejný problém – tech lead udělá architektonická rozhodnutí, inženýři dělají práci. Vzor tak nezajímavý, že je trochu trapné, jak dlouho trvalo k němu dojít. Zajímavý není ten vzor, zajímavý je, že s event-bus tvarem, který Mozaik poskytuje, jeho přidání nestálo nic kromě samotného nového participanta.

Pointa pro Claude Code uživatele: pro spoustu malých, ohraničených úkolů bude /goal první volba, je hned po ruce, bez instalace. Otázka, kdy se vyplatí sáhnout po multi-agent setupu jako baro, dostala v tomhle benchmarku zajímavou odpověď: ne automaticky kvůli paralelismu, ale až když má architektura prostor postavit upstream „tech-lead fázi“ levně.

Zdroj: Miodrag Todorović, JigJoy Blog