## Problem A full roundtable spawns 2–5 consultants in parallel (`roundtable_create` schema enforces 2–5 participants), each as a CC subagent. Bro then reads all votes, calls `roundtable_summarize`, then `roundtable_finalize_decisions`. For a single decision this can hit tens of thousands of tokens across the fan-out. The trigger threshold today is bro's judgment via `tmb_planning`, not a structured impact gate. ## Evidence (verified against live source) - `mcp/trajectory-server/src/tools/roundtable.ts` registers 5 tools: `roundtable_create`, `roundtable_vote`, `roundtable_close`, `roundtable_finalize_decisions`, `roundtable_summarize`. `roundtable_create.participants_count` schema is "Number of non-human participants (2–5)". - `templates/agents/{architect,ceo,cto,pm}.md` — all 4 consultants have **`skills: []`** (no skills attached) and `model: opus`. So consultants do **not** load bro's planning/review skill bodies on spawn. The earlier claim that consultants "spawn with full bro context (bro skills, project memory)" was wrong on the skills front. They do still inherit CLAUDE.md (51 lines, plugin-level) and any project-level CLAUDE.md. - Consultant `tools:` allowlist is `Read, Glob, Grep, Bash, mcp__plugin_tmb_trajectory-server` — same MCP namespace as bro, so all 61 trajectory-server tool names enter the deferred-tool index. - A `roundtable-slash-detect.sh` PreToolUse hook + `roundtable-auq-shape.sh` exist, and `roundtable_create` is server-gated: it rejects without a prior `roundtable_slash_invoked` audit row (per CLAUDE.md routing table). So roundtables aren't easily triggered ad-hoc — they require the Human to type `/roundtable`. The largest cost components per roundtable (corrected): 1. **N opus consultant spawns** (N=2–5), each with `model: opus` (more expensive per token than sonnet) and full MCP tool surface 2. **`pr-reviewer-no-worktree.sh` and `require-feature-branch-active.sh` PreToolUse [Agent] hooks** fire on every subagent spawn — minor per-spawn cost 3. **Bro reading N votes via `roundtable_vote` rows** — currently no compaction 4. **Optional `roundtable_summarize` + `roundtable_finalize_decisions`** — additional bro turns ## Plan 1. Define explicit impact tiers in `tmb_planning`: - **T1** (no roundtable): single-file change, well-scoped fix - **T2** (advisory consultant): cross-cutting refactor in one component — single consultant spawn (1 of architect/cto/pm/ceo) - **T3** (roundtable required): API/schema/protocol change, channel-affecting decision — server already requires `/roundtable` slash trigger 2. Add `impact_tier: 'T2' | 'T3'` parameter to `roundtable_create`; T2 returns a single-spawn directive rather than initializing a full roundtable row. 3. Default consultant `model` to `sonnet` for T2 advisory spawns; reserve `opus` for T3 roundtables. 4. Add a `roundtable_votes_compact` server-side response shape: when bro calls `roundtable_summarize`, return votes as `[{agent, summary_3_lines}]` not full bodies. Full vote bodies via explicit `include_full=true`. 5. Track cost via `audit` event `roundtable_spawn_cost` with `content_json: {participants_count, model, hook_count}` — measurement for follow-up tuning. ## Acceptance criteria - L4 simulation: `roundtable_create` called without `impact_tier` returns a 400-style error with the rubric. - L4 simulation: T2 invocation spawns 1 consultant (sonnet) not a full roundtable. - New L5 dogfood scenario: a T2 decision completes without firing `roundtable_create` at all. - `templates/agents/*.md` ship a `model: sonnet` variant for T2-eligible spawns OR a runtime model override is supported. ## Out of scope - Removing consultants entirely. - Async/queued consultant votes. - Per-consultant model tuning (separate concern). ## Note on source Previous description claimed consultants spawn "with full bro context (bro skills, project memory)" — incorrect. Templates have `skills: []`. Verified by reading `templates/agents/{architect,ceo,cto,pm}.md` frontmatter directly.