Consider a design-time algorithmic-efficiency specialist (gap in the agent roster)

Summary

The agent roster has no owner for design-time algorithmic / computational-complexity review of application logic (Big-O, data-structure choice, redundant passes, missing memoization or dynamic programming). This is a real, verified gap. Before adding a 25th agent, though, the authoring guidance's own 45% rule says to test the cheapest fill first and only build a node if that measurement shows a real miss.

Full investigation (evidence E1-E17, adversarial validation V1-V7, staged recommendation, confidence and risks) is attached as a collapsible comment below.

The gap (verified against all 24 agents and 4 skills)

No agent owns the algorithmic-complexity lens. The three nearest agents each own a different concern:

• data-engineer fires only when in-memory work should have been a database query (code-data boundary).
• on-call-engineer catches unbounded results as a 3am OOM risk, not the cost of a bounded O(n²) operation.
• devops-engineer works infra scale and cost, not per-function algorithm choice.

A pure in-memory O(n²), or a linear scan where a hash lookup fits, has nothing in the roster to grip it. code-review's only efficiency checkpoint is a five-line, DB/frontend-shaped manual checklist (N+1, re-renders, pagination, indexes, over-fetching). structural-analyst is static-only by charter; behavioral-analyst has four fixed dimensions, none of them cost; software-architect is a synthesizer with no complexity input to act on. This claim survived direct adversarial re-reading of every relevant agent.

Planning / architecture fit

Yes, and that is where an agent would earn the most. An inefficient algorithm is cheapest to fix before it is written, so the design-time skills are the highest-value homes: plan-implementation and architectural-analysis, with code-review and investigate as after-the-fact. plan-a-feature is out by design, because it defers all mechanic-level specialists downstream.

Recommendation (staged and test-gated)

1. Stage 0 (cheap, do first). Broaden code-review's Performance checklist to cover algorithmic and data-structure items, and add complexity vocabulary plus a flag instruction to software-architect's charter. Then measure, using the project's existing A/B unique-survivor-yield method, whether real reviews of computation-heavy changes miss complexity findings. This satisfies the 45% rule.
2. Stage 1 (only if Stage 0 shows a real miss). Build a design-time algorithmic-complexity discovery agent in the structural/behavioral/concurrency analyst mold, scoped to the algorithmic lens (asymptotic cost, data-structure fit, memoization), never broad "performance." The guidance's own "performance agent" example vocabulary is runtime profiling, which is exactly the domain that collides with the three agents above, so the naming and scope must hold the algorithmic line.
3. Stage 2 (wiring). Add it conditionally to plan-implementation and architectural-analysis first, then code-review and investigate. Both design-time homes already run 6-9 agents in their large bands, so a new agent competes for a slot on complex artifacts rather than adding free capacity. Gate it on a concrete Grep proxy (nested-loop / sort / recursion / large-collection patterns) plus a negative-result self-report, and accept that it will over-fire relative to the keyword signals.

Confidence

Medium, and honestly bounded. The gap is real and survived adversarial verification. The specific fill, its trigger mechanism, and its roster-economics safety are unvalidated assumptions that happen to align. The largest open question is whether the gap is felt (reviews demonstrably missing complexity bugs) or only structural: Stage 0's measurement exists to answer exactly that before any agent is built.

Start with the existing A/B unique-survivor-yield method and inspect the code-review Performance checklist plus the software-architect charter described in the issue. Measure whether Stage 0 misses complexity findings; done means using that result to decide whether to build and wire a narrowly scoped algorithmic-complexity agent.