A quick summary of Claude Code's Agent teams: A lead session can initiate multiple independent teammate sessions for parallel collaboration. They are self-organized through a shared task list and messaging system, making them more suitable for discussing, exploring, and collaborating on complex tasks. Key features include: - Difference from subagents: Subagents involve a lead agent assigning tasks, with subagents only reporting results; agent teams allow multiple teammates to communicate directly, share task lists, and claim tasks themselves, making them more suitable for complex tasks requiring discussion and collaboration. - Activation method: Disabled by default; requires setting the environment variable `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` (configurable in `settings.json`). - How to start: Use natural language to have Claude create a team and describe your desired team structure (roles/number of members/division of labor). After creation, a shared task list will be generated. The lead is responsible for aggregation and completion, and you can interact directly with each teammate. - Presentation Modes: Two UI modes - In-process: All team members run within the same terminal, switching between concurrent messaging via Shift+Up/Down. - Split panes: Each team member has their own pane (requires tmux or iTerm2 + it2 CLI/Python API), default is auto. - Specify team members and models: Claude can decide the number of teammates, or explicitly require (e.g., "4 teammates refactor in parallel") and specify the model used by each team member. - Plan approval: Team members can be required to submit a plan in read-only mode before the lead approves it and begins coding; approval criteria can be provided in the prompt (e.g., tests must be included). - Delegate mode: Allows the lead to only orchestrate without writing code directly (Shift+Tab toggles), suitable for scenarios where you want to turn the lead into a pure orchestration. - Task Assignment and Preemption: The shared task list supports pending/in-progress/completed tasks and dependencies; leads can assign tasks, and teammates can also claim them themselves; file locks prevent multiple people from competing for the same task. - Shutdown and Cleanup: Leads can request a teammate to shut down a task; upon completion, the lead can perform a cleanup (checking for active teammates to avoid resource residue/inconsistency). - Local Storage and Architecture: Team configurations and task lists are stored locally (e.g., `~/.claude/teams/{team}/config.json`, `~/.claude/tasks/{team}/`), with a mailbox for message delivery and idle notifications. - Token Cost: Teams significantly increase token consumption (each teammate's independent context), suitable for research/review/new features; daily small tasks are more cost-effective per session. - Usage suggestions and troubleshooting: Emphasize "providing sufficient context, appropriate task splitting, avoiding file conflicts, and continuous monitoring and guidance"; list common problems (teammates not appearing, too many permission prompts, lead ending work too early, orphaned tmux, etc.).

Personal summary: It feels quite immature, especially since you need to provide sufficient guidance and continuous monitoring. I think if you can provide that, using only subagents instead of agent teams should be able to get the job done just fine; the advantages of this architecture aren't obvious. The main advantage might be that it's a less token-intensive alternative to the normal multi-agent approach?