13. 5. 2026Aktualizováno 15. 7. 2026

Claude Code agent teams: multi-agent práce konečně míří do praxe

Realistický cover: vývojář řídí více AI agentů v Claude Code na pracovním monitoru

Anthropic 13. května 2026 přidal do Claude Code research preview agent teams. V českých AI kanálech se to objevilo hlavně v souvislosti s tím, že Claude Code už není jen jeden agent, kterému dáte úkol a čekáte. Začíná se z něj stávat prostředí, kde se práce rozpadá mezi více specializovaných agentů.

Aktualizace 25. května 2026: doplnil jsem i příkaz /goal, který Anthropic vydal ve verzi Claude Code 2.1.139 už 11. května 2026. Je to důležitý dílek stejné skládačky: agent teams řeší rozdělení práce, /goal řeší, kdy má agent pokračovat bez dalšího popostrčení a kdy už je hotovo.

Aktualizace 28. května 2026: doplňuji také Superset, který ukazuje druhou větev stejného trendu: ne multi-agent režim uvnitř jednoho nástroje, ale lokální orchestraci více coding agentů přes izolované Git worktree. To není nový release z dneška, ale prakticky důležité workflow, které dobře doplňuje agent teams i /goal.

Aktualizace 18. června 2026: doplňuji praktickou vrstvu kolem Claude Code hooks a notifikací. Nejde o nový model, ale o důležitý detail provozu: dlouhé agentní běhy mají člověka aktivně zavolat zpět, když chtějí povolení, narazí na chybu nebo dokončí práci.

Aktualizace 29. června 2026: doplňuji ještě provozní detail, který se o víkendu znovu objevil v české AI scéně: Claude Code může běžet lokálně jako nástroj v terminálu, ale samotný model běží vzdáleně. Pro firemní nasazení je to podstatné. Neřešíte jen prompt, ale i oprávnění k souborům, síťový přístup k pracovní stanici, schvalování příkazů a to, jaká data odcházejí do modelu.

Aktualizace 30. června 2026: přidávám návaznost na Remote Control, Claude Code on the web a Slack. Důležitá není samotná možnost spustit agenta z mobilu nebo ze Slack threadu. Důležité je rozlišit, kde agent skutečně běží, odkud bere kontext a kdo má právo ho poslat do repozitáře.

Tohle je důležitější než běžná položka v changelogu. Pokud AI v týmu používáte každý den, problém už není jen „umí napsat kód?“ Problém je, jak řídit více paralelních úvah, jak jim dát mantinely a jak uhlídat, že výsledkem nebude drahý chaos.

Claude Code agent teams: workflow s governance a review

Co se změnilo

V changelogu Claude Code je u verze 2.1.141 z 13. května 2026 uvedené, že přibyla experimentální funkce agent teams pro multi-agent spolupráci. Zapíná se přes proměnnou CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 a Anthropic rovnou upozorňuje, že jde o tokenově náročnou funkci.

Prakticky si to představuju takhle:

  • jeden agent řeší implementaci,
  • druhý kontroluje rizika a testy,
  • třetí dělá průzkum dokumentace nebo kódu,
  • hlavní člověk drží zadání, priority a rozhodnutí.

To není magie. Je to spíš dobrý seniorní workflow zabalený do nástroje.

Nová vrstva: /goal

/goal posouvá Claude Code jiným směrem než agent teams. Nejde o to, že máte víc agentů. Jde o to, že nastavíte měřitelnou podmínku dokončení a Claude pokračuje přes více tahů, dokud ji samostatný hodnoticí model nevyhodnotí jako splněnou.

Typický příklad cíle:

/goal npm test projde bez chyb a git status neukazuje žádné nechtěné změny

Podle dokumentace Claude Code se po každém tahu kontroluje, jestli je cíl splněný. Pokud ne, Claude dostane důvod a pokračuje dalším tahem. Hodnoticí model sám nespouští příkazy ani nečte soubory; soudí jen podle toho, co se objevilo v konverzaci. Proto je potřeba, aby Claude v průběhu práce ukazoval důkazy: výstup testů, build, diff, seznam splněných kritérií.

Superset: externí orchestrátor místo dalšího chatu

Superset jde na stejný problém z jiné strany. Není to model ani nový coding agent. Je to editor/orchestrátor, který umí spouštět více CLI coding agentů paralelně na jednom stroji. Podle dokumentace podporuje nástroje jako Claude Code, Codex, Gemini CLI, Cursor, OpenCode nebo Copilot a každému běhu vytváří izolované prostředí přes Git worktree.

Prakticky to znamená:

  • jeden agent opravuje bug,
  • druhý připravuje testy,
  • třetí zkouší refaktor,
  • čtvrtý řeší dokumentaci,
  • člověk mezi tím porovnává diffy, pouští testy a rozhoduje, co se sloučí.

Tohle je důležitý rozdíl proti agent teams. Agent teams řeší spolupráci agentů uvnitř Claude Code. Superset řeší provozní orchestrace napříč různými nástroji a oddělenými pracovními stromy. Je to méně magické, ale velmi praktické: izolace přes worktree je nudná technologie, která přesně řeší problém, že dva agenti nesmí šlapat po stejných souborech.

Neznamená to, že máte pustit deset agentů na jeden chaotický úkol. Dává to smysl hlavně pro paralelní, oddělitelné práce: samostatné issue, experimentální varianty řešení, refaktor vedle nové feature, nebo rychlé porovnání Claude Code vs. Codex vs. Gemini CLI na stejném zadání.

Kdy použít agent teams, /goal a Superset

Beru to takhle:

  • agent teams se hodí, když potřebujete paralelní role uvnitř jednoho problému: implementace, review, výzkum, testy,
  • /goal se hodí, když máte jeden jasný koncový stav a nechcete agenta po každém kroku znovu popohánět,
  • Superset se hodí, když chcete pustit více nezávislých agentních běhů vedle sebe a držet je oddělené přes worktree,
  • auto mode řeší hlavně schvalování nástrojů uvnitř jednoho tahu,
  • hooks nebo vlastní loop dávají smysl, když potřebujete determinističtější kontrolu vlastním skriptem.

Nejzajímavější kombinace je podle mě /goal + rozumné mantinely + izolované worktree + lidský review. Třeba: „migruj modul, dokud všechny testy neprojdou, ale neměň veřejné API a po 10 tazích zastav s reportem.“ To už není chatování. To je zadání práce agentovi.

Hooks jako provozní panel agenta

Nový praktický signál z české scény je jednoduchý: Claude Code nemusí jen tiše běžet v terminálu. Přes hooks se z něj dá udělat agent, který na konci práce, při požadavku na povolení nebo při chybě spustí vlastní akci. Klidně notifikaci, zápis do logu, webhook do Slacku nebo lokální text-to-speech.

Oficiální dokumentace Claude Code popisuje hooks jako uživatelské shell příkazy, HTTP endpointy nebo promptové hooky navázané na události v životním cyklu. Prakticky jsou důležité hlavně události jako Notification, Stop, StopFailure, PreToolUsePostToolUse. To jsou místa, kde se z chatovacího nástroje stává řízený proces.

Pro týmové nasazení to neberu jako hračku. Dává smysl nastavit například:

  • hlasové nebo systémové upozornění, když agent čeká na povolení,
  • zprávu do Slacku po dokončení dlouhého běhu,
  • automatický zápis souhrnu do issue nebo interního logu,
  • tvrdý blok pro destruktivní příkazy,
  • kontrolní hook po úpravě souborů, který spustí lint nebo testy.

Tohle je malá změna v konfiguraci, ale velká změna v ergonomii. Pokud agent běží 20 minut, člověk nemá sedět a sledovat kurzor. Agent má pracovat, zaznamenat důkazy a ozvat se ve chvíli, kdy je potřeba rozhodnutí nebo review.

Tři režimy: lokální stroj, cloud a Slack

Claude Code se prakticky rozpadá do tří různých provozních režimů a je chyba házet je do jednoho pytle.

První režim je Remote Control. Podle dokumentace zůstává session běžet na vašem stroji a web nebo mobil jsou jen ovládací plocha. To je dobré, když agent potřebuje lokální checkout, lokální MCP servery, lokální nástroje nebo projektovou konfiguraci. Zároveň to znamená, že počítač musí běžet, musí mít síť a pořád nese rizika lokálního prostředí.

Druhý režim je Claude Code on the web. Tam session běží v cloudové infrastruktuře Anthropic. Hodí se, když chcete rychle založit úkol bez lokálního setupu, pustit víc úloh paralelně nebo pracovat nad repozitářem, který nemáte zrovna naklonovaný. Bezpečnostní model je jiný: místo přístupu k vašemu lokálnímu stroji řešíte připojené GitHub repozitáře, cloudové prostředí, sdílení session a limity plánu.

Třetí režim je Slack. Když v kanálu zmíníte @Claude s coding úkolem, Slack integrace umí založit Claude Code session na webu, přenést kontext threadu, vybrat repozitář a posílat průběžné stavy zpět do Slacku. Pro firmy je to zajímavé hlavně u bug triage: v support nebo incident kanálu už existuje popis problému, logy, očekávané chování a diskuse týmu. Agent z toho může udělat vyšetření nebo malý PR, aniž by někdo musel ručně kopírovat kontext do editoru.

Tady ale začíná governance. Slack thread není automaticky bezpečný prompt. Claude dokumentace výslovně upozorňuje, že agent může pracovat s kontextem konverzace a může následovat instrukce z okolních zpráv. Proto bych Slack režim nepouštěl do obecného firemního chatu. Dává smysl spíš ve vyhrazených kanálech typu #dev-bugs, #support-triage nebo #internal-tools, kde jsou jasná pravidla, kdo může agenta zmínit, jaký repozitář se smí použít a kdy je povinný lidský review.

Praktický pattern: Slack slouží jako vstupní fronta, Claude Code on the web jako izolované pracovní prostředí a pull request jako kontrolní bod. Remote Control nechávám pro situace, kdy agent potřebuje konkrétní lokální prostředí vývojáře. Jakmile se tyto tři režimy smíchají bez pravidel, tým ztratí přehled, kde vznikla změna, z jakého kontextu a kdo ji vlastně autorizoval.

Lokální nástroj není lokální model

Claude Code je podle oficiální dokumentace agentický coding nástroj dostupný v terminálu, IDE, desktopové aplikaci a prohlížeči. Prakticky to znamená, že běží blízko vašeho repozitáře, umí číst soubory, upravovat je, spouštět příkazy a napojit se na vývojářské nástroje. Neznamená to ale, že se model počítá lokálně na notebooku.

Pro týmy je tahle hranice důležitá. Lokální běh CLI řeší ergonomii a přístup k pracovním souborům. Vzdálený model řeší inference. Bezpečnostní otázky proto leží mezi nimi:

  • které složky a repozitáře agent smí číst,
  • které příkazy smí spustit bez potvrzení,
  • jestli v pracovním stromu nejsou secrets, produkční dumpy nebo klientská data,
  • jak se člověk připojuje ke stroji, kde agent běží,
  • kde vzniká auditní stopa a kdo schvaluje výsledek.

Praktický víkendový pattern je jednoduchý: vývojář má Claude Code na vlastním počítači nebo devboxu, k němu se bezpečně připojí přes privátní síť typu Tailscale a agent běží nad lokálním checkoutem. To dává smysl, pokud chcete pokračovat v práci mimo hlavní počítač, sledovat dlouhý běh nebo schválit krok na dálku. Pořád ale platí, že musíte oddělit přístup ke stroji, přístup k repozitáři a oprávnění samotného agenta.

Tailscale SSH v dokumentaci popisuje model, kde se SSH spojení autentizuje a šifruje přes WireGuard a Tailscale node keys. To je užitečná síťová vrstva, ne kouzelná bezpečnostní výjimka. Pokud agent může na stroji spustit destruktivní příkaz, vzdálené připojení přes VPN z toho automaticky neudělá bezpečný proces.

Moje praktické minimum: samostatný pracovní účet nebo devbox, jasný pracovní adresář, žádné produkční secrets v repu, read-only default tam, kde to jde, schvalování destruktivních příkazů, hooks pro logování a lidský review před mergem. Pak je „lokální Claude Code + vzdálený přístup“ dobrý workflow. Bez toho je to jen rychlejší cesta k dražší chybě.

Kde to dává smysl

Agent teams ani Superset bych nepouštěl na malé úkoly typu „přejmenuj komponentu.“ Tam je overhead zbytečný. Smysl to má u úloh, kde se dnes člověk stejně přepíná mezi rolemi:

  • větší refaktoring,
  • debugging v neznámé části systému,
  • bezpečnostní review,
  • migrace API nebo frameworku,
  • příprava PR s dopadem do více modulů,
  • analýza produkčního incidentu,
  • porovnání více agentů nebo modelů na stejném zadání.

U těchto úloh už jeden agent často nestačí. Potřebujete paralelní kontrolu, izolaci a dobrý merge proces, ne jen delší prompt.

Co bych nastavil před použitím

První pravidlo: agent teams, /goal ani Superset nejsou omluva pro vypnutí kontroly. Naopak. Čím víc autonomie agent dostane, tím víc potřebujete mantinely.

Minimum pro týmové nasazení:

  • jasný limit na tokeny, počet tahů nebo rozpočet pro jednu úlohu,
  • oddělené pracovní větve nebo worktree,
  • měřitelný konečný stav, ideálně test, build nebo checklist,
  • povinný závěrečný report: co se změnilo, co se netestovalo, kde jsou rizika,
  • lidský review krok před merge,
  • pravidla pro secrets, produkční data a destruktivní příkazy,
  • logování toho, který agent udělal jaké rozhodnutí.

Bez toho se multi-agent workflow rychle změní v dražší verzi chaosu.

Moje praktická pointa

Tohle je přesně směr, kterým se bude práce vývojáře posouvat. Ne „AI nahradí programátora“, ale „jeden senior bude řídit víc agentních vláken a rozhodovat, které výstupy pustí dál.“

Z toho plyne jedna nepříjemná věc: slabý technický člověk z toho automaticky silný tým neudělá. Agent teams, /goal a Superset násobí kvalitu řízení. Když je zadání špatné, budou jen rychleji vyrábět špatný výsledek.

Závěr

Claude Code agent teams zatím beru jako research preview, /goal jako velmi užitečný režim pro úkoly s jasným koncem a Superset jako praktickou lokální vrstvu pro řízení více agentních běhů. Směr je ale jasný. Vývojové workflow se posouvá od jednoho chatovacího okna k řízeným agentním běhům.

Kdo dnes nastaví dobré limity, review, worktree a zadávání práce, bude z toho těžit. Kdo jen zapne další experimentální funkci, pravděpodobně si koupí drahou lekci.

Aktualizace 15. července 2026: adopce je týmový problém, ne instalace nástroje

Tomáš AI dnes otevřel praktickou pointu, kterou u firemních AI rolloutů vidím pořád: vybrat nástroj nestačí. Pokud se nezmění způsob práce, odpovědnosti a měření, firma jen přidá další aplikaci do stacku.

Dobře to doplňuje čerstvá studie Adoption and Impact of Command-Line AI Coding Agents nad raným rolloutem Claude Code a GitHub Copilot CLI v Microsoftu. Autoři sledovali desítky tisíc inženýrů a nepopisují adopci jako čistě technický problém. První použití se šířilo hlavně přes sociální síť uvnitř firmy, retence souvisela víc s reálnou coding aktivitou než s demografií a uživatelé agentů mergovali zhruba o 24 % více pull requestů, než by podle modelu mergovali bez adopce. Autoři zároveň férově upozorňují, že merged PR není totéž jako skutečná hodnota dodané změny.

Pro CTO je z toho praktičtější závěr než „kupte všem agenta.“ Pilot má mít viditelné šampiony, konkrétní use casy, měřené výstupy a pravidla pro review. Nestačí poslat odkaz na nástroj do Slacku a čekat plošnou změnu. Lepší je vybrat týmy, které už mají dost kódové práce, ukázat reálné příklady v pull requestech, sbírat použití po workflow a měřit nejen počet PR, ale i kvalitu review, defekty, dobu do merge, tokenové náklady a spokojenost týmu.

To zapadá do celé pointy tohoto článku. Agentní vývoj není o tom, že vývojář dostane silnější chat. Je to změna provozu: jak zadáváme práci, jak agent běží, kdo schvaluje akce, jak se oddělují worktree, co se loguje a podle čeho poznáme, že se produktivita opravdu zvedla. Bez toho zůstane Claude Code nebo Copilot CLI zajímavou hračkou pro pár nadšenců. S dobrým rolloutem se z toho může stát normální týmová schopnost.


Zdroje: Claude Code changelog, Claude Code /goal dokumentace, Claude Code commands, Superset, Superset docs: AI Agents, Superset: Working with Git Worktrees, Filip Oborník: Superset, Filip Oborník: Claude Code Goal, Jirka Herník: Týmy agentů v Claude Code a první AI Zero-Day, Tomáš AI: Claude Code průvodce, Claude Code hooks reference, AI s rozumem: Jak jsem donutil Claude Code, aby se mnou mluvil, Claude Code overview, Claude Code security, Tailscale SSH docs, AI s rozumem: Claude Code běží lokálně, AI s rozumem: vzdálený přístup přes Tailscale, AI s rozumem: co znamená lokálně, Claude Code Remote Control, Claude Code in Slack, AI s rozumem: Claude Code na dálku, Jirka Herník: Claude ve Slacku, Adoption and Impact of Command-Line AI Coding Agents, Tomáš AI: implementace není jen o technologiích.