2.1.178: native team-management tools TeamCreate / TeamDelete no longer surfaced (regression from 2.1.177)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34750
2. https://github.com/anthropics/claude-code/issues/68408
3. https://github.com/anthropics/claude-code/issues/61867

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Have the same issue - TeamCreate, TeamDelete tools no longer available in 2.1.178:

{
  "ts": "2026-06-16T05:52:49.301Z",
  "session_id": "82bc5809-e448-4532-9e1e-32b510d21885",
  "transcript_path": "...",
  "cwd": "...",
  "permission_mode": "bypassPermissions",
  "effort": { "level": "high" },
  "hook_event_name": "PostToolUse",
  "tool_name": "ToolSearch",
  "tool_input": {
    "query": "select:SendMessage,TaskCreate,TaskGet,TaskList,TaskUpdate,TeamCreate,TeamDelete",
    "max_results": 7
  },
  "tool_response": {
    "matches": [
      "SendMessage",
      "TaskCreate",
      "TaskGet",
      "TaskList",
      "TaskUpdate"
    ],
    "query": "select:SendMessage,TaskCreate,TaskGet,TaskList,TaskUpdate,TeamCreate,TeamDelete",
    "total_deferred_tools": 21
  },
  "tool_use_id": "toolu_01KfXS31bw5ic5evDodiBcDE",
  "duration_ms": 2
}

Same call in 2.1.177:

{
  "ts": "2026-06-15T19:22:24.372Z",
  "session_id": "9d318100-3ec5-48c4-856d-3bdeed3edb2b",
  "transcript_path": "...",
  "cwd": "...",
  "permission_mode": "bypassPermissions",
  "effort": { "level": "xhigh" },
  "hook_event_name": "PostToolUse",
  "tool_name": "ToolSearch",
  "tool_input": {
    "query": "select:SendMessage,TaskCreate,TaskGet,TaskList,TaskUpdate,TeamCreate,TeamDelete",
    "max_results": 7
  },
  "tool_response": {
    "matches": [
      "SendMessage",
      "TaskCreate",
      "TaskGet",
      "TaskList",
      "TaskUpdate",
      "TeamCreate",
      "TeamDelete"
    ],
    "query": "select:SendMessage,TaskCreate,TaskGet,TaskList,TaskUpdate,TeamCreate,TeamDelete",
    "total_deferred_tools": 23
  },
  "tool_use_id": "toolu_01SxUSL2xjhgViLV4cEzMsB4",
  "duration_ms": 1
}

I also experienced this issue, and it broke my entire development system, thought I was going crazy.

Yep, we use agent teams heavily and 2.1.178 broke all our flows. Hoping for a fast-follow fix :)

same happened here, rolled back to 2.1.177 until anthropic solves the issue.

│ Symlink ~/.local/bin/claude → versions/2.1.177 ✅
│ Quarantined 2.1.178/179/181 → versions-quarantine-2.1.178-regression/ (recoverable) ✅
│ Version pool now contains → only 2.1.177 ✅ (launcher picks newest-in-pool, so this is what makes the pin hold)
│DISABLE_AUTOUPDATER=1 → added to settings.json.env ✅ (native auto-update is "protected", so autoUpdates:false alone is ignored)
│ 2.1.177 --version → runs ✅
│Recheck note → reference_claude_code_2178_teamcreate_regression.md + MEMORY.md index ✅

┌───────────────────────┬────────────────────────────────────────────┐
│ Check │ Result │
├───────────────────────┼────────────────────────────────────────────┤
│ Running CLI version │ 2.1.177 ✅ │
├───────────────────────┼────────────────────────────────────────────┤
│ ~/.local/bin/claude │ → versions/2.1.177 ✅ │
│ symlink │ │
├───────────────────────┼────────────────────────────────────────────┤
│ Version pool │ only 2.1.177 (launcher can't pick a newer │
│ │ broken build) ✅ │
├───────────────────────┼────────────────────────────────────────────┤
│ Quarantine │ versions-quarantine-2.1.178-regression/ │
│ │ intact ✅ │
├───────────────────────┼────────────────────────────────────────────┤
│ TeamCreate / │ │
│ TeamDelete / │ loadable (absent in the broken session) ✅ │
│ SendMessage │ │
├───────────────────────┼────────────────────────────────────────────┤
│ tmux │ 3.4, and we're inside session claude-001 │
│ │ (attached) ✅ │
└───────────────────────┴────────────────────────────────────────────┘

Confirmed same on 2.1.178. Rolling back to 2.1.177 is the right immediate move.

For anyone who needs to stay on 2.1.178 while waiting for a patch: the workaround is to set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and then fall back to the Agent tool directly (no explicit TeamCreate call). The lead session will operate in the implicit team scope. You lose named teams and the clean TeamDelete teardown, but SendMessage, TaskCreate, TaskList, and TaskUpdate all still work, so a hub-and-spoke coordination pattern can keep running.

One thing worth noting for the Anthropic team: the failure mode here (team-management tools silently reported as disconnected MCP tools rather than simply absent) suggests the native tool surface is being initialized through the same injection path as MCP-provided tools. If the two initialization paths share a registration step that changed in 2.1.178, that explains why only TeamCreate/TeamDelete dropped out while the rest of the agent-teams surface stayed intact.

Watching for the fix here.

Hi all, we're intentionally simplifying agent teams and merging them into subagents, so subagents are team members by default.

In practice, a session has one agent team almost always, so we unshipped the team create/delete machinery to make it automated. For folks that rely on explicit tool calls, could you share what exactly you rely on -- is it that you want a visual indicator of the current team name? or that you want multiple concurrent teams that cannot communicate with one another? or something else?

@bcherny The main issue here is that the breaking change was silent - no announcement, and the documentation was still listing non-existing tools and broken conventions. I see that the docs are updated now, but that was some wasted time for me.

Suggestion: include breaking changes in the changelog

@bcherny this has completely broken my workflow, i used to have a team with an agent being the planner/orchestrator and specialist subagents doing the actual work .. this meant that I could actually connect to the team pane and send message directly in case there was an issue.. now everything is dropped without any notification.. please claude needs to give us workaround before making such breaking change

⚠️ Correction (2026-06-18): the failing repro below was on CC 2.1.179, not 2.1.181 — and the shutdown behaviour appears FIXED in 2.1.181. claude --version reported the auto-updated on-disk binary (2.1.181), but /status showed the session that produced these failures was actually running 2.1.179 (sessions keep their launch version). On a 2.1.181 session, an in-process run_in_background teammate completed a lead-initiated shutdown_response cleanly ("Shutdown approved … now exiting"); split-pane (tmux/iTerm2) teammate mode also shows teammates in their own window with working close-down. So the "no termination path" framing below was 2.1.179-specific. Original text left for the record — see follow-up.

---

Confirming this on 2.1.181 (macOS), and flagging the downstream impact for orchestration that relied on TeamCreate.

With TeamCreate/TeamDelete gone, Agent(name, run_in_background: true) is the only way to fan out persistent, message-driven workers — but those are background subagents, not teammates, and they have no termination path:

• A background subagent's only documented self-terminate is approving a shutdown_request via shutdown_response, and that is rejected with: "Structured team-protocol messages (shutdown/plan responses and requests) are acts of the session itself and cannot be sent by a background subagent. Send a plain text message instead."
• There is no other exit tool, and TaskStop/TaskList cannot reach it. It idles and emits idle_notifications until the parent session exits.

The deeper loss is that TeamCreate teammates were the only worker type that was both coordinable and closable. The replacements force an either/or:

| Worker | Coordinable mid-flight | Closable |
|---|---|---|
| run_in_background subagent | yes | no |
| synchronous subagent | no (blocks caller, dies on return) | yes (self-closes) |
| TeamCreate teammate (removed) | yes | yes |

So restoring TeamCreate/TeamDelete — or any spawn that yields a persistent, lead-terminable worker — is what unblocks closable fan-out orchestration. The shutdown side has a separate pre-existing bug even for real teammates (#60199). Happy to provide a minimal repro if useful.

⚠️ Correction (2026-06-18): this was observed on CC 2.1.179, not 2.1.181, and appears FIXED in 2.1.181. The session here was actually running 2.1.179 (per /status; claude --version reports the updated on-disk binary). On 2.1.181 an in-process run_in_background teammate completes the shutdown handshake cleanly, so the "no termination path" point below no longer holds on current builds. See follow-up.

---

Thanks @bcherny — that the team→subagent merge is intentional is genuinely clarifying, and the auto-team simplification is a good direction. To answer "what exactly you rely on": it's not a team-name indicator or multiple concurrent teams. It's a team member the lead can terminate.

TeamDelete + the per-member shutdown handshake gave lead-initiated teardown of persistent members once their work was done.

In the merged model the members are run_in_background subagents — which is great for orchestration (persistent, message-driven: push → wait for review → fix on a lead nudge → push again). But they currently have no termination path:

• a background subagent can't send shutdown_response — "Structured team-protocol messages … cannot be sent by a background subagent. Send a plain text message instead."
• there's no other exit tool, and the lead's shutdown_request isn't honored;
• TaskStop / TaskList can't reach them.

So they idle and emit idle_notifications until the whole session exits. A long orchestration run spawns ~14 workers across waves; each lingers after completing, flooding the lead with idle pings, unreapable. There's also an asymmetry: spawning is not session-gated (a background subagent can freely spawn its own subagents on 2.1.181), but termination is — you can create non-closable workers at any depth and can't end them.

We don't want TeamCreate/TeamDelete back. What's needed is close-down to work for subagent team members in the merged model — either let the lead's shutdown_request actually reap a background member, or give a background member a self-exit (allow shutdown_response, or a "done/exit" affordance). Today: creation unrestricted at any depth, termination impossible.

(Related pre-existing shutdown bug even for real teammates: #60199. Downstream tracker: bjcoombs/ai-native-toolkit#211.)

Following up to correct my two comments above — and it's good news for the merge direction.

Version mis-stamp. The repro I posted was from a session I believed was 2.1.181 (claude --version), but /status showed it was actually running 2.1.179. Sessions keep their launch version while the on-disk binary auto-updates, so everything I'd stamped "2.1.181" was 2.1.179 behaviour.

Re-tested on 2.1.181 — the shutdown path I complained about is resolved:

• An in-process run_in_background teammate received a lead-initiated shutdown_request, replied with shutdown_response {approve:true}, and the runtime returned "Shutdown approved. Sent confirmation to team-lead. Agent … is now exiting." — it exited cleanly.
• With split-pane teammate mode (tmux / iTerm2), teammates render in their own window and also close down cleanly.

So the "subagent team members can't be shut down" problem was 2.1.179-specific; on 2.1.181 subagents are closable team members, which is exactly the intended end state of the team→subagent merge. The capability appears to have landed between 2.1.179 and 2.1.181.

To be clear on scope: this only corrects the shutdown/closability concern I raised. The TeamCreate/TeamDelete removal itself is intentional per your note above; the live concerns others have raised here (the change was silent, and the docs still referenced the removed tools / CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS) are separate and still worth addressing. Apologies for the noise from the mis-stamped version. Downstream tracker updated accordingly: bjcoombs/ai-native-toolkit#211.

TL;DR — independent testing on 2.1.181 (merged model, in-process backend): the lead's shutdown_request does reap background teammates, the roster is flat (no background grandchildren), and the channel works flag-free, including headless -p. So the "no termination path / non-closable workers at any depth" picture looks better on current builds — with one caveat (I didn't test tmux-pane-backed members).

Three notes on the termination/lifecycle discussion:

1. Termination works, lead-initiated. SendMessage(to=<name>, {type: shutdown_request}) → teammate shutdown_approved → teammate_terminated, and the member drops from members[]. A background subagent can only emit shutdown_response as a reply to an inbound shutdown_request — so "can't send shutdown_response" is expected when no request was sent first (no request_id to echo). ⚠️ All my probes were in-process; tmux-pane-backed members untested.
2. No workers "at any depth." Roster is flat by construction: Agent(name=…, run_in_background=true) from a teammate → "Teammates cannot spawn other teammates — the team roster is flat"; nameless bg → "In-process teammates cannot spawn background agents. Use run_in_background=false…". So background depth is bounded to 1.
3. TaskList/TaskStop can't reach them — confirmed, but ~/.claude/teams/session-<id>/config.json members[] is a live, pruned roster you can read.

What changed, 2.1.177 → 2.1.181 (2.1.181 col = live probes; 2.1.177 col = the legacy TeamCreate model as recorded, not re-tested here)

| | 2.1.177 (legacy) | 2.1.181 (merged) |
|---|---|---|
| Team tools | TeamCreate/TeamDelete present | absent (by design) |
| Establish membership | TeamCreate, then named members | named background Agent, no TeamCreate |
| Lead reap | TeamDelete (whole team) + per-member shutdown | per-member shutdown_request only (no bulk teardown) |
| Enable flag | CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 needed | flag-free |
| Team dir | caller-named | auto, session-<id> |
| Headless -p team mode | ❌ | ✅\* (merged channel stays resident) |

\* headless -p row is from a nested claude -p stream-json probe; re-confirming. Unchanged across both: teammate self-exit is reply-only; the on-disk config.json schema is the same shape.

Full notes / capability matrix: https://github.com/spacedock-dev/spacedock/blob/spacedock-state/dev/using-claude-team-merged-model-support.md#capability-matrix--claude-code-21181-merged-auto-team-model

Hi all, we're intentionally simplifying agent teams and merging them into subagents, so subagents are team members by default. In practice, a session has one agent team almost always, so we unshipped the team create/delete machinery to make it automated. For folks that rely on explicit tool calls, could you share what exactly you rely on -- is it that you want a visual indicator of the current team name? or that you want multiple concurrent teams that cannot communicate with one another? or something else?

@bcherny I've tested this a bit more and can confirm this is a good simplification that allows bi-directional messaging for subagents. the only thing i'd ask is the steerability of the team members when getting messages from the main agent or the user. right now the message is sent but not read until the subagents are "free", which requires manually interrupting them.

Hi all, we're intentionally simplifying agent teams and merging them into subagents, so subagents are team members by default. In practice, a session has one agent team almost always, so we unshipped the team create/delete machinery to make it automated. For folks that rely on explicit tool calls, could you share what exactly you rely on -- is it that you want a visual indicator of the current team name? or that you want multiple concurrent teams that cannot communicate with one another? or something else?

that's terrible news, I for example use Agent Teams for spawning a complete 8 x Opus 8 [1m] context each + Team Lead, each one with a specific agent role devised for my project workflow and they talk with eachother and answer to teamlead, everything running under tmux multiple panes, it's really the best way to drive multiple teams, i also do this with subtree so i can have multiple agent teams running specific worktrees and each agent has a full 1m context window because the current state of the production project is quite heavy.

please maintain current Agent Teams configuration because subagents are really bad for longrunning sessions and heavy complexity stuff because they're quite dumb and also subagents fills context quite extensively for enterprise projects. the best tmux usage of live agents is seeing what they're actually doing instead of waiting for subagents in background processes that can`t be verified and having separate context windows for longrunning work.

take a look at my current team topology & lifecycle

🧭 Team topology & lifecycle (GOLDEN RULE: all work via this team)

┌───────────────────────┐
│ TEAM-LEAD │ orchestrates · runs DB pushes,
│ (this Claude loop) │ EF deploys, git, execute_sql gates
└──────────┬────────────┘
│ TeamCreate / Agent(spawn) / SendMessage / TaskUpdate
┌──────────────┬─────────────┼─────────────┬──────────────┬───────────────┐
▼ ▼ ▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│architect│ │ db │ │ hooks │ │ infra │ │frontend │ │ reviewer │
│ design │ │migrations│ │src/hooks│ │EF·lib· │ │components│ │ SPLIT │
│drop-safe│ │(authors)│ │ ** │ │functions│ │app·msgs │ │ audit │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └──────────┘

• planner (.planning/**, close-out) + gsd-ui-auditor (6-pillar UI audit)

read-only: architect, reviewer, ui-auditor · write: db/hooks/infra/frontend

Lifecycle: spawn(on-demand) → work-1-turn → idle(stays alive) → dismiss → respawn
Every agent = a REAL attachable tmux pane running 2.1.177 (gated-visibility rule).

⚙️ The wave-orchestration workflow we ran

PER WAVE: architect-first ──▶ parallel executors ──▶ TEAM-LEAD GATE ──▶ verify
(no unilateral fixes) (domain-split, (push/deploy/ (probes,
no file races) live probe) build green)

Specialized agent roster

┌─────┬────────────────────┬─────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ # │ Agent │ Class │ Description (genericized) │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1 │ architect │ read-only + │ [Platform] architect — deep architectural analysis, schema design, ADRs, system-design decisions. Produces architectural statements for stakeholder decisions. Read-only code access; writes to │
│ │ │ planning │ .planning/. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 2 │ researcher │ read-only │ [Platform] researcher — deep codebase exploration, DB analysis, production-data analysis, best-practices research. Produces research docs that inform planning & architecture. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 3 │ planner │ write .planning/ │ [Platform] GSD planner — maintains ROADMAP, STATE, PROGRESS, phase directories, verification tracking. Owns .planning/ exclusively. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 4 │ db (executor) │ write migrations │ [Platform] database executor — creates migration files with proper SQL. Never runs db push/execute_sql for schema changes; team-lead handles all DB ops. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 5 │ hooks (executor) │ write src/hooks/ │ [Platform] hooks executor — writes/modifies React Query hooks, mutations, data-layer code. Owns src/hooks/ exclusively. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 6 │ infra (executor) │ write lib/EF/config │ [Platform] infrastructure executor — cache-invalidation graph, edge functions, config, cross-cutting utilities. Owns src/lib/, supabase/functions/, src/config/. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 7 │ frontend │ write UI │ [Platform] frontend executor — components, pages, styling, i18n. Owns src/components/, src/app/, messages/. Follows the design system. │
│ │ (executor) │ │ │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 8 │ reviewer │ read-only │ [Platform] code reviewer — audits code quality, security, data integrity, architectural consistency. Read-only; never modifies files. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 9 │ debugger │ read-only │ [Platform] debugger — systematic hypothesis-driven debugging for financial, RLS, orchestrator, and data-integrity issues. Persistent debug state across sessions. │
└─────┴────────────────────┴─────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Tools per agent

WRITERS (Read·Write·Edit·Grep·Glob·Bash·SendMessage + extras)
db + memory(search·open)
hooks + memory(search·open)
infra + memory(search·open) (leanest writer — no extra MCP)
frontend + memory(search·open) · magic(searchRegistryItems·getRegistryItem) ◀ shadcn/UI registry
planner + memory(search·open) · sequential-thinking · context7(resolve·query)

READ-ONLY / ANALYSIS (Read·Grep·Glob·Bash·SendMessage + extras)
architect + Write·Edit (to .planning only) · execute_sql · memory(search·open·read_graph)
· context7 · firecrawl(search·scrape) · sequential-thinking · WebSearch · WebFetch
researcher+ execute_sql · memory(search·open·read_graph) · context7
· firecrawl(search·scrape·agent·agent_status) · sequential-thinking · WebSearch · WebFetch
reviewer + execute_sql · memory(search·open)
debugger + execute_sql · memory(search·open) · sequential-thinking · WebSearch

Capability patterns worth noting

• execute_sql (read-only SELECT) is granted to architect, researcher, reviewer, debugger — the analysis agents probe live DB state. The executors (db/hooks/infra/frontend) do NOT have it — and db explicitly cannot db push. All schema mutation +

pushes route through team-lead (the I-10 / "team-lead owns execute_sql verification" doctrine).

• Domain ownership is exclusive (hooks=src/hooks, infra=lib/functions/config, frontend=components/app/messages, planner=.planning) — this is what prevents the file-coordination races.
• Web/doc reach (context7, firecrawl, WebSearch/Fetch) is concentrated in architect + researcher — the agents that need external best-practices input.
• magic (shadcn registry) is unique to frontend.
• All are opus[1m]; the team-lead orchestrates, spawns on-demand into real tmux panes, and is the only one that pushes to prod.

Hi all, we're intentionally simplifying agent teams and merging them into subagents, so subagents are team members by default. In practice, a session has one agent team almost always, so we unshipped the team create/delete machinery to make it automated. For folks that rely on explicit tool calls, could you share what exactly you rely on -- is it that you want a visual indicator of the current team name? or that you want multiple concurrent teams that cannot communicate with one another? or something else?

@bcherny that's terrible news, I for example use Agent Teams for spawning a complete 8 x Opus 8 [1m] context each + Team Lead, each one with a specific agent role devised for my project workflow and they talk with eachother and answer to teamlead, everything running under tmux multiple panes, it's really the best way to drive multiple teams, i also do this with subtree so i can have multiple agent teams running specific worktrees and each agent has a full 1m context window because the current state of the production project is quite heavy.

please maintain current Agent Teams configuration because subagents are really bad for longrunning sessions and heavy complexity stuff because they're quite dumb and also subagents fills context quite extensively for enterprise projects. the best tmux usage of live agents is seeing what they're actually doing instead of waiting for subagents in background processes that can`t be verified and having separate context windows for longrunning work.

take a look at my current team topology & lifecycle

🧭 Team topology & lifecycle (GOLDEN RULE: all work via this team)

┌───────────────────────┐
│ TEAM-LEAD │ orchestrates · runs DB pushes,
│ (this Claude loop) │ EF deploys, git, execute_sql gates
└──────────┬────────────┘
│ TeamCreate / Agent(spawn) / SendMessage / TaskUpdate
┌──────────────┬─────────────┼─────────────┬──────────────┬───────────────┐
▼ ▼ ▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│architect│ │ db │ │ hooks │ │ infra │ │frontend │ │ reviewer │
│ design │ │migrations│ │src/hooks│ │EF·lib· │ │components│ │ SPLIT │
│drop-safe│ │(authors)│ │ ** │ │functions│ │app·msgs │ │ audit │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └──────────┘

• planner (.planning/**, close-out) + gsd-ui-auditor (6-pillar UI audit)

read-only: architect, reviewer, ui-auditor · write: db/hooks/infra/frontend

Lifecycle: spawn(on-demand) → work-1-turn → idle(stays alive) → dismiss → respawn
Every agent = a REAL attachable tmux pane running 2.1.177 (gated-visibility rule).

⚙️ The wave-orchestration workflow we ran

PER WAVE: architect-first ──▶ parallel executors ──▶ TEAM-LEAD GATE ──▶ verify
(no unilateral fixes) (domain-split, (push/deploy/ (probes,
no file races) live probe) build green)

Specialized agent roster

┌─────┬────────────────────┬─────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ # │ Agent │ Class │ Description (genericized) │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1 │ architect │ read-only + │ [Platform] architect — deep architectural analysis, schema design, ADRs, system-design decisions. Produces architectural statements for stakeholder decisions. Read-only code access; writes to │
│ │ │ planning │ .planning/. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 2 │ researcher │ read-only │ [Platform] researcher — deep codebase exploration, DB analysis, production-data analysis, best-practices research. Produces research docs that inform planning & architecture. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 3 │ planner │ write .planning/ │ [Platform] GSD planner — maintains ROADMAP, STATE, PROGRESS, phase directories, verification tracking. Owns .planning/ exclusively. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 4 │ db (executor) │ write migrations │ [Platform] database executor — creates migration files with proper SQL. Never runs db push/execute_sql for schema changes; team-lead handles all DB ops. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 5 │ hooks (executor) │ write src/hooks/ │ [Platform] hooks executor — writes/modifies React Query hooks, mutations, data-layer code. Owns src/hooks/ exclusively. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 6 │ infra (executor) │ write lib/EF/config │ [Platform] infrastructure executor — cache-invalidation graph, edge functions, config, cross-cutting utilities. Owns src/lib/, supabase/functions/, src/config/. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 7 │ frontend │ write UI │ [Platform] frontend executor — components, pages, styling, i18n. Owns src/components/, src/app/, messages/. Follows the design system. │
│ │ (executor) │ │ │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 8 │ reviewer │ read-only │ [Platform] code reviewer — audits code quality, security, data integrity, architectural consistency. Read-only; never modifies files. │
├─────┼────────────────────┼─────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 9 │ debugger │ read-only │ [Platform] debugger — systematic hypothesis-driven debugging for financial, RLS, orchestrator, and data-integrity issues. Persistent debug state across sessions. │
└─────┴────────────────────┴─────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Tools per agent

WRITERS (Read·Write·Edit·Grep·Glob·Bash·SendMessage + extras)
db + memory(search·open)
hooks + memory(search·open)
infra + memory(search·open) (leanest writer — no extra MCP)
frontend + memory(search·open) · magic(searchRegistryItems·getRegistryItem) ◀ shadcn/UI registry
planner + memory(search·open) · sequential-thinking · context7(resolve·query)

READ-ONLY / ANALYSIS (Read·Grep·Glob·Bash·SendMessage + extras)
architect + Write·Edit (to .planning only) · execute_sql · memory(search·open·read_graph)
· context7 · firecrawl(search·scrape) · sequential-thinking · WebSearch · WebFetch
researcher+ execute_sql · memory(search·open·read_graph) · context7
· firecrawl(search·scrape·agent·agent_status) · sequential-thinking · WebSearch · WebFetch
reviewer + execute_sql · memory(search·open)
debugger + execute_sql · memory(search·open) · sequential-thinking · WebSearch

Capability patterns worth noting

• execute_sql (read-only SELECT) is granted to architect, researcher, reviewer, debugger — the analysis agents probe live DB state. The executors (db/hooks/infra/frontend) do NOT have it — and db explicitly cannot db push. All schema mutation +

pushes route through team-lead (the I-10 / "team-lead owns execute_sql verification" doctrine).

• Domain ownership is exclusive (hooks=src/hooks, infra=lib/functions/config, frontend=components/app/messages, planner=.planning) — this is what prevents the file-coordination races.
• Web/doc reach (context7, firecrawl, WebSearch/Fetch) is concentrated in architect + researcher — the agents that need external best-practices input.
• magic (shadcn registry) is unique to frontend.
• All are opus[1m]; the team-lead orchestrates, spawns on-demand into real tmux panes, and is the only one that pushes to prod.

The greatest value of the Team feature was that it provided a reliable communication channel between CC sessions running as independent processes. Within CC, it was also used as a channel for delivering events originating outside the session.

This made it possible to build orchestration systems around CC. If this capability is removed, it will become difficult to use CC as an orchestration platform.