Subagenci w Claude Code dostają zadanie, robią je i oddają wynik sesji, która ich wywołała. Agent teams działają inaczej. Jedna sesja zostaje liderem zespołu, a pozostałe, czyli teammates, to pełne, niezależne instancje Claude Code, każda z własnym kontekstem. Rozmawiają ze sobą bezpośrednio, biorą zadania ze wspólnej listy, a człowiek może napisać do dowolnego z nich z pominięciem lidera.
Jak włączyć agent teams w Claude Code
Funkcja jest eksperymentalna i domyślnie wyłączona. Włącza ją zmienna środowiskowa, w powłoce albo w settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}Potem wystarczy opisać zadanie i zespół zwykłym językiem, na przykład „Spawn three teammates to explore this from different angles: one on UX, one on technical architecture, one playing devil's advocate” (to przykład z dokumentacji). Dwie pułapki. Po pierwsze, zespół powstaje tylko w sesji interaktywnej: w trybie -p i w Agent SDK teammates się nie pojawią. Po drugie, przy włączonych zespołach każdy subagent, któremu Claude nada imię, startuje jako teammate. Zespół potrafi więc powstać, choć nikt o niego nie prosił. Wyłącza się to, ustawiając tę samą zmienną na 0.
Subagenci czy agent teams?
| Subagenci | Agent teams | |
|---|---|---|
| Kontekst | własny, wynik wraca do wywołującego | własny, pełna niezależność |
| Komunikacja | zwracają wynik | piszą do siebie bezpośrednio |
| Koordynacja | wszystkim zarządza główny agent | wiadomości plus wspólna lista zadań |
| Koszt w tokenach | niższy, wyniki są streszczane | wyższy, każdy to osobna instancja |
Jak działa zespół: skrzynki, lista zadań i blokady
Mechanika jest zaskakująco przyziemna. Każdy agent ma skrzynkę w pliku JSON: ~/.claude/teams/{team-name}/inboxes/{agent-name}.json. Wiadomość liczy się jako wysłana dopiero wtedy, gdy zapis do pliku odbiorcy się uda. Lista zadań leży w ~/.claude/tasks/{team-name}/, zadania mają trzy stany (pending, in progress, completed) i mogą zależeć od innych. Gdy dwóch teammates chce wziąć to samo zadanie naraz, rozstrzyga blokada pliku. Konfiguracja zespołu znika po zakończeniu sesji, lista zadań zostaje na dysku.
Domyślnie wszyscy siedzą w jednym terminalu, a teammate'a wybiera się strzałkami w panelu pod polem promptu. Tryb z podzielonymi panelami wymaga tmuxa albo iTerm2 z narzędziem it2. Nie działa w zintegrowanym terminalu VS Code, w Windows Terminal ani w Ghostty, co na Windowsie mocno zawęża wybór. Przełącza się go ustawieniem teammateMode albo flagą --teammate-mode.
Uprawnienia dziedziczą się po liderze, z wyjątkiem trybu dontAsk. Jeśli lider działa z --dangerously-skip-permissions, cały zespół też. Pytania o zgodę od teammates wyskakują w sesji lidera. Ważny szczegół bezpieczeństwa: wiadomość od innego agenta jest oznaczona jako pochodząca od innej sesji Claude, więc teammate nie może zgodzić się na coś w imieniu człowieka ani przepchnąć odrzuconej akcji przez kolegę. Jest też haczyk na jakość: hooki TeammateIdle, TaskCreated i TaskCompleted mogą kodem wyjścia 2 zawrócić teammate'a do pracy albo zablokować oznaczenie zadania jako skończonego.
Ilu teammates i ile to kosztuje?
Dokumentacja radzi zaczynać od 3–5 teammates i 5–6 zadań na każdego. Koszt rośnie liniowo z liczbą członków zespołu, bo każdy ma własne okno kontekstu. Do tego cache promptu in-process teammate'a trzyma domyślnie pięć minut, także na subskrypcji, a godzinę dopiero po ustawieniu subagentPromptCacheTtl na 1h. Taniej zrobiło się dopiero razem z obniżką cen Opusa 5.5.
Ograniczeń jest sporo i są wypisane uczciwie. /resume nie przywraca teammates, sesja ma dokładnie jeden zespół, teammates nie mogą zakładać własnych zespołów, a lidera nie da się zmienić. Status zadań potrafi się spóźniać i blokować zależne zadania. Najrozsądniej zacząć od roboty bez pisania kodu, na przykład od recenzji PR z trzech stron (bezpieczeństwo, wydajność, testy) albo od szukania przyczyny błędu kilkoma konkurującymi hipotezami. Tam równoległość daje najwięcej, a dwóch agentów nie nadpisuje sobie nawzajem tego samego pliku.
