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

[taminomara]

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.

[taminomara]

Full investigation write-up, for the record. Evidence items E1-E17, adversarial validation V1-V7, staged recommendation, and confidence/risks.

Full investigation — docs/plans/algorithmic-efficiency-specialist/investigation.md

Should Han add an algorithmic-efficiency specialist agent?

Summary

• Question. Would Han benefit from an "algorithm expert" agent that spots inefficient solutions and suggests better ones, and could it run during a planning or architecture pass?
• Answer. There is a real, verified gap. No agent in the 24-agent roster owns algorithmic or computational-complexity review of application logic, and none of the four skills that could dispatch one (code-review, architectural-analysis, plan-implementation, investigate) has any efficiency checkpoint beyond a five-line, database-shaped checklist. This is the one claim that survived adversarial re-verification against every named agent and two unnamed ones.
• But do not build the agent first. The authoring guidance's 45% rule says to optimize an existing surface before adding a node. The cheapest fill is to broaden code-review's manual Performance checklist and add complexity vocabulary to software-architect, then measure whether real reviews actually miss complexity findings. Only build a dedicated agent if that measurement shows a real miss rate.
• If it is built, scope it narrowly. A design-time algorithmic-complexity discovery agent (Big-O, data-structure fit, redundant passes, missing memoization or dynamic programming), not a broad "performance" agent. Runtime performance profiling collides with data-engineer, devops-engineer, and on-call-engineer; the design-time algorithmic slice is the part nobody owns.
• Where it would belong. plan-implementation and architectural-analysis are the highest-value homes, which is the direct yes to the planning/architecture half of the question. code-review and investigate are secondary. plan-a-feature is out by design.
• Confidence: medium, and honestly bounded. The gap is real. The specific fill, its trigger mechanism, and its roster-economics safety are unvalidated assumptions that happen to align. Treat the recommendation as a test plan, not a build order.

Question Statement

The request: would Han benefit from an algorithm-expert agent who can spot ineffective solutions and suggest improvements, and can it be used during planning or an architecture pass?

Two sub-questions follow:

1. Is the domain already covered? Does any existing agent or skill review the algorithmic or computational efficiency of application logic, or is this a genuine gap?
2. If added, where would it run? Which skills would dispatch it, and is the design-time ("planning or architecture pass") framing a fit?

Evidence Summary

Trust class for every item below is codebase (file path plus line, direct citation).

The domain is unowned across the whole roster:

• E1: No agent claims algorithmic-complexity review. A grep across all 24 agent files for performance|complexity|algorithm|big-o|O(n|memoiz|data structure|recomputation|inefficient|scalab returns only incidental uses. No agent name, Role Identity, or Domain Vocabulary section carries algorithmic time/space complexity as a first-class concept.
• E2: data-engineer (nearest overlap Gap analysis improvements #1) is scoped to the code-data boundary. data-engineer.md:214,218 flags "business logic written as in-memory iteration" and "application code [that] sorts / filters / aggregates fetched rows the database should have done." Verified: this only fires when in-memory work substitutes for a database operation. A pure in-memory function with no database involvement (an O(n²) string match, a linear search where a hash map would do) has nothing for this protocol to grip.
• E3: on-call-engineer (overlap Add the plan-work-items skill #2) frames inefficiency as a 3am resilience failure. on-call-engineer.md:66 catches an "unbounded queue, buffer, or result set" with failure modes "Queue Runaway, OOM-kill, slow memory leak." Verified: it keys on the absence of a size bound, not the asymptotic cost of a bounded operation. A triple-nested loop over a capped 1,000-item list never trips it.
• E4: devops-engineer (overlap code-review guardrails #3) works the ops and scale layer. devops-engineer.md:14,231,235 names "N+1 at scale," "missing indexes at scale," and "cache stampede," all evaluated for production readiness, cost, and blast radius, not for whether an in-memory function chose the right algorithm.
• E5: structural-analyst is static-only by charter. structural-analyst.md:8,94: "You analyze code as it is written, not how it behaves at runtime... Does not assess runtime behavior." Its five dimensions have no complexity axis.
• E6: behavioral-analyst has four fixed runtime dimensions, none is cost. behavioral-analyst.md:3,24-64: data flow, error propagation, state management, integration boundaries, with an explicit "Execute all four dimensions. Never skip one." Algorithmic cost falls under none.
• E7: concurrency-analyst's "algorithms" means concurrency primitives. concurrency-analyst.md:77 checks "lock-free algorithms" for correctness (compare-and-swap, memory ordering), not Big-O.
• E8: software-architect has no complexity input to synthesize. software-architect.md:3 synthesizes structural, behavioral, concurrency, and risk findings into SOLID/cohesion/coupling recommendations. Because none of its upstream discovery agents (E5-E7) produces a complexity finding, the gap propagates to the recommendation layer: even if dispatched, it has nothing to recommend on this axis. Confirmed against risk-analyst.md and junior-developer.md, which both require an upstream specialist finding or defer to named siblings, none algorithm-adjacent.
• E9: gap-analyzer disclaims performance analysis. gap-analyzer.md:3 names "performance bottleneck analysis" as out of scope. This is a data point that no agent claims the domain. It is not diagnostic on its own: undirected "does not do X" disclaimers without a "use Y" redirect are common in this roster (see V1), so the absence of a redirect here proves nothing by itself. E1-E8 carry the gap claim; E9 is corroborating color at most.

No skill has a real efficiency checkpoint:

• E10: code-review has a five-line manual checklist, DB/frontend-shaped. code-review/references/review-checklist.md:35-40 covers N+1 queries, frontend re-renders, pagination, indexes, and over-fetching. It is applied by the orchestrating session at Step 4 (code-review/SKILL.md:247-254), not a dispatched agent, and never touches algorithm or data-structure choice. Its 11-agent dispatch roster (SKILL.md:129-145) contains no complexity specialist.
• E11: architectural-analysis has no complexity signal or specialist. architectural-analysis/SKILL.md:65-84 lists a synthesis spine plus a "signal → specialist → min band" table. There is no complexity signal and no complexity specialist in it.
• E12: plan-a-feature defers all mechanic-level specialists by design. plan-a-feature/SKILL.md:181 intentionally excludes the analysts and architects from the spec stage and sends them downstream to plan-implementation. An algorithm specialist would not live here; the skill's own rule excludes its whole category.
• E13: plan-implementation has a "draw from" menu with no efficiency bullet. plan-implementation/SKILL.md:87-101. Adding a specialist here is one new bullet naming the specialist and its touch-condition, plus a matching Step 4 brief-table row.
• E14: investigate dispatches three conditional specialists, none for complexity, and only after a symptom exists. investigate/SKILL.md:42-48. The performance-adjacent one (data-engineer) triggers on "slow queries, N+1, unbounded scans," a database angle. It fires only once something is already slow, not on an approach that will scale badly but has not yet hurt.

Design constraints from the authoring guidance:

• E15: Add a specialist only for a measured gap; optimize existing agents first. multi-agent-economics.md states the 45% rule (optimize an existing agent before adding one) and caps a concurrently-dispatched team at about five.
• E16: The guidance's own "performance agent" example is the collision domain, not this one. agent-domain-focus.md:85-94 gives a worked "performance analysis agent" vocabulary: hot path, allocation pressure, cache miss ratio, flame graph, tail latency, GC pause, N+1 query, index scan vs. sequential scan, backpressure, circuit breaker. Every term is runtime profiling, the exact domain that overlaps data-engineer/devops-engineer/on-call-engineer. So this example is a warning, not support: an agent named "performance" routes straight to the collision vocabulary. Whatever gets built must be named and scoped for the algorithmic lens (asymptotic cost, data-structure fit, memoization) to avoid that pull.
• E17: Both proposed homes already exceed the soft cap in their large bands. architectural-analysis/SKILL.md:63-97 dispatches its discovery agents concurrently and its large-band roster is "6-9 agents"; plan-implementation/SKILL.md:72-105 caps its team at "6 to 8" and launches every specialist in parallel. The review-skill-or-agent-roster-reduction and roster-consolidation plans establish (via multi-agent-economics.md:11-12,36) that the ~5 cap governs exactly this parallel-dispatch pattern, and that real skills already reach 6-9 concurrent reviewers through independently-conditional signals co-firing, with nothing dispatched always-on. So a new conditional agent does not create bloat in a clean design, but it also cannot promise "under 5": it adds one more candidate competing for an already-strained band.

Analysis

The gap is real and cleanly bounded. Nine roster-level findings (E1-E9) and five skill-level findings (E10-E14) agree: the algorithmic-complexity lens is unowned, and the three agents that come closest each own a different concern (data placement, production resilience, ops scale). Adversarial re-reading of every named agent plus risk-analyst and junior-developer found no agent that could be prompted to catch a pure in-memory O(n²) or a wrong-data-structure choice today. This is the load-bearing fact, and it held.

Scope any fill to the design-time algorithmic lens, not broad performance. Two adjacent domains exist. Runtime performance profiling (hot paths, flame graphs, tail latency, GC) overlaps heavily with data-engineer, devops-engineer, and on-call-engineer. Design-time algorithmic complexity (is this the right algorithm and data structure; is there a redundant pass; would memoization change the asymptotics) is the slice nobody owns. E16 shows the pull is real: the guidance's own "performance agent" example lands squarely in the collision vocabulary. Holding the algorithmic line is what keeps friction low; letting it drift to "performance" re-opens the overlap with three charters.

Test the cheap fill before building a node (the 45% rule). The lowest-cost fill is to broaden code-review's manual Performance checklist beyond DB/frontend and to add a complexity vocabulary plus an explicit "flag asymptotic or data-structure inefficiency" instruction to software-architect's charter. Whether that under-delivers is an open question, not a settled one: the argument that a manual checklist activates no dedicated vocabulary cluster, and that a synthesizing agent will not reliably flag inefficiency it did not discover, is a plausible analogy but is as unproven as the gap-severity question below. The 45% rule the guidance states (E15) means this cheap route must be tested first, using the same A/B unique-survivor-yield method the roster-reduction effort already runs, and the agent built only if the checklist route shows a measurable miss.

Planning and architecture are the right homes for an agent, if one is built. This is the direct answer to the second half of the question. An inefficient algorithm is cheapest to fix before it is written:

• plan-implementation (E13): one "draw from" bullet, gated on a touch-condition. Closest fit to the "architecture pass" framing, since plan-a-feature (E12) deliberately pushes mechanic specialists here.
• architectural-analysis (E11): one new signal plus a table row and a min-band gate.
• code-review (E10) and investigate (E14) are secondary and after-the-fact.

The trigger signal is harder to gate than the existing ones. Every current signal in architectural-analysis is a literal keyword or file-pattern match (async, Dockerfile, schema files, mutex). "Nested loops over unbounded collections" needs semantic reasoning about whether a collection's size is bounded, which Grep cannot do. The one precedent for a judgment signal (Unfamiliar-area, SKILL.md:53) is a much shallower call. So the gate must use a concrete Grep-detectable proxy (nested-loop patterns, sort/search/recursion calls, large-collection operations) and accept that it will over-fire relative to the keyword signals, paired with an instruction for the specialist to self-report a negative result the way concurrency-analyst does. Do not assert the signal will behave like the others; it will not.

Recommendation

Staged and test-gated, so the expensive step is earned rather than assumed.

1. Stage 0 (cheap, reversible, do first). Broaden code-review's Performance checklist to include algorithmic and data-structure items (nested-loop blowups, linear scan where a hash lookup fits, missing memoization, redundant passes over an in-memory collection), and add complexity vocabulary plus a flag instruction to software-architect's charter. Then measure: run the project's A/B unique-survivor-yield method over a set of real changes with heavy in-memory computation, and see whether the broadened checklist surfaces complexity findings a normal review misses. This directly satisfies the 45% rule.
2. Stage 1 (only if Stage 0 shows a real miss). Build a discovery agent named for the algorithmic lens (for example algorithmic-efficiency-analyst), scoped to computational complexity and data-structure fit of application logic, in the structural/behavioral/concurrency analyst mold. Use agent-builder. Give it a real Domain Vocabulary (amortized cost, asymptotic complexity, data-structure fit, memoization, dynamic programming, redundant traversal, quadratic blowup, linear scan vs. hash lookup) and named anti-patterns with detection signals. Disclaim the runtime-performance overlaps so it does not drift into the collision domain (E16).
3. Stage 2 (wiring). Add it conditionally to plan-implementation and architectural-analysis first, using the concrete Grep proxy plus negative-result self-report from the Analysis, never unconditionally. Then code-review and investigate. Because both design-time homes already run above the soft cap in their large bands (E17), treat the new agent as competing for a slot on complex artifacts, not as free capacity.
4. Minor independent cleanup. If an owner is eventually built, add the redirect to gap-analyzer's "performance bottleneck analysis" disclaimer. This is cosmetic, not load-bearing (V1).

Validation Results

An adversarial-validator pass attacked the recommendation against the source files. The core survived; four supporting arguments were weakened or refuted, and the fixes are folded into the sections above.

• V1 (refutes E9-as-tell). The claim that gap-analyzer's undirected disclaimer was "uniquely diagnostic" is false. user-experience-designer.md:3, readability-editor.md:3, and edge-case-explorer.md:3 all carry undirected "does not do X" clauses; gap-analyzer itself has four. Undirected disclaimers are a common style, not a signal. E9 downgraded to corroborating color.
• V2 (refutes E16-as-support). The guidance's "performance analysis agent" example vocabulary is entirely runtime profiling, the collision domain this proposal avoids. E16 rewritten as a warning about naming drift, not as evidence the domain is safe.
• V3 (confirms the core). Direct re-reading of every nearest-overlap agent plus risk-analyst and junior-developer found no agent that covers a pure in-memory algorithmic-complexity problem. The gap claim (E1-E8) holds. This was the one attack that failed.
• V4 (weakens the trigger plan). The algorithmic-surface signal is not mechanically detectable like the keyword signals; boundedness needs semantic reasoning Grep lacks. Analysis now specifies a Grep proxy plus negative-result self-report and concedes over-firing.
• V5 (weakens the sequencing). The doc invoked the 45% rule but recommended building the agent before testing the cheap route. Recommendation reordered: Stage 0 tests the checklist route first; the agent is Stage 1, gated on a measured miss.
• V6 (refutes the cap promise). "Keeps any single run under the ~5 concurrent cap" is factually wrong: architectural-analysis runs 6-9 and plan-implementation caps at 6-8 in their large bands before this agent is added. Corrected in E17 and Counterarguments: the agent adds a candidate to an already-strained band rather than introducing bloat into a clean design.
• V7 (downgrades confidence). With E9 and E16 discounted, the case rests on the negative-space grep (solid) plus assumptions about checklist inadequacy and trigger reliability that are not yet tested. Summary confidence set to medium and stated as bounded.

Confidence Assessment and Remaining Risks

• Confidence: medium. The gap is real and survived adversarial re-verification (V3). The specific fill, its trigger mechanism, and its roster-economics safety are unvalidated assumptions that happen to align. That is why the recommendation is staged and test-gated rather than a build order.
• Is the gap felt, or only structural? The evidence proves the domain is uncovered, not that reviews are demonstrably missing complexity bugs. Stage 0's measurement exists precisely to answer this before any agent is built.
• Scope drift to "performance." The single largest design risk. If the agent grows into runtime profiling it collides with three charters and the boundary text balloons (E16). The algorithmic line must hold.
• Trigger reliability is unverified. No test set of real algorithmic-surface vs. non-surface code has been run through a prototype signal (V4).
• Roster economics. Both integration points already exceed the soft cap in their large bands (E17, V6). The new agent competes for inclusion on complex artifacts; it does not add free coverage.