Looking at the subagent test results, I need to analyze which agents seem redundant, badly designed, or have issues. Let me examine the patterns and overlaps.
First, I notice `source-control` and `git-committer` are both focused on git operations. Let me check what each one actually did in the tests:
- `source-control`: Showed git status, branches, commit history, change stats
- `git-committer`: Also showed git status, commit history, analyzed conventions, drafted commit messages
These seem very similar. The `git-committer` description says "Git commit and push" while `source-control` says "Use this agent when you are asked to commit and push code changes". That's clearly redundant.
Also, `general` and `researcher` have some overlap - both do research tasks, though `researcher` specifically mentions web search.
`advanced-coding-manager` seems like it's trying to do too much - "analysis, coordination, validation, handles implementation blockers and parallel task execution". That's very broad.
`coder-agent` and `typescript-coder-agent` also have overlap - both are coding agents.
Let me think about the use case holes:
1. **No frontend/UI specialist agent** - for React/Component work
2. **No backend/API specialist agent**
3. **No database/schema specialist agent**
4. **No infrastructure/DevOps agent**
5. **No security/audit specialist agent**
The agents seem heavily weighted toward git operations (2 agents) and coding (2 agents), but missing domain specialists.
Also, `testing` is specifically for Go testing, but this is a TypeScript project. That's a mismatch.
Let me check the actual descriptions again from the tools list... Looking at the available `subagent_type` values:
1. `general` - General-purpose multi-step tasks
2. `explore` - Fast codebase exploration
3. `researcher` - Deep research with web search
4. `executor` - Elite tool-using agent for primary code/system execution
5. `typescript-coder-agent` - TypeScript implementation
6. `source-control` - Git commit/push
7. `git-committer` - Git commit/push (DUPLICATE!)
8. `docs` - Documentation writing
9. `testing` - Test Go code (misplaced for TS project)
10. `advanced-coding-manager` - Complex coding coordination
11. `coder-agent` - Coding subtask execution
Clear redundancies:
- `source-control` and `git-committer` are identical purpose
- `coder-agent` and `typescript-coder-agent` overlap significantly
- `general` and `researcher` overlap in research capabilities
Design issues:
- `testing` is Go-specific in a TS project
- `advanced-coding-manager` is overly broad "manager" role
- No domain specialists (frontend, backend, infra, security)
- Missing: code review agent, architecture analysis agent, performance optimization agent
Context loading issues:
- `explore` might load too much context with large codebases
- `researcher` could overload with web search results
- `general` might try to do too many things at once
The agent taxonomy needs refinement. Better would be:
1. Keep: `explore` (fast search), `docs` (documentation), `executor` (system ops)
2. Merge: `source-control` + `git-committer` → `git-agent`
3. Merge: `coder-agent` + `typescript-coder-agent` → `typescript-agent`
4. Split: `general` → `task-coordinator` + `research-agent`
5. Add: `frontend-agent`, `backend-agent`, `infra-agent`, `security-agent`
6. Fix: `testing` → `test-agent` (language-agnostic)
7. Clarify: `advanced-coding-manager` → `project-manager` or remove
Also missing: `code-review-agent`, `architecture-agent`, `performance-agent`, `debug-agent`.
The current setup has redundant agents, language-specific assumptions, and missing domain expertise. Let me structure this analysis.
Agent Architecture Analysis
🔴 Redundant Agents
Critical Duplication:
source-control and git-committer - Both described identically as "Use this agent when you are asked to commit and push code changes to a git repository." Complete overlap in purpose and function.
Significant Overlap:
2. coder-agent ("Coding subtask execution") and typescript-coder-agent ("TypeScript implementation agent") - Both handle coding tasks with heavy TS focus; unclear distinction.
3. general ("multi-step tasks") and researcher ("deep research") - Both perform research; boundary is fuzzy.
⚠️ Design Issues
1. Language-Specific Mismatch:
testing: "Test Go code in a methodical way following official guidelines"
- Problem: This is a TypeScript/Bun monorepo with 643 test files using
bun:test and Playwright
- Fix: Should be language-agnostic
test-agent or typescript-testing-agent
2. Overly Broad/Ambiguous:
advanced-coding-manager: "Manages complex coding implementations by performing initial analysis, coordinating multiple coding agents, and ensuring quality validation"
- Problem: This describes a meta-agent that coordinates other agents - unclear when to use vs.
general or direct execution
- Risk: Could become a "god agent" doing everything poorly
3. Vague Boundaries:
executor: "Elite tool-using agent - primary code and system executor"
- Problem: What makes it "elite"? How does it differ from
coder-agent?
- Ambiguity: "System executor" could mean anything from bash commands to infrastructure changes
🕳️ Gaps in Use Cases
Missing Domain Specialists:
- Frontend/UI Agent: React/Solid.js component development, styling (Tailwind), state management
- Backend/API Agent: Hono/Express API design, database schemas, authentication flows
- Infrastructure/DevOps Agent: Cloudflare Workers, Docker, CI/CD, deployment
- Security/Audit Agent: Vulnerability scanning, permission analysis, secret detection
- Database/Schema Agent: Drizzle/ORM patterns, migration strategies, query optimization
Missing Specialized Roles:
6. Code Review Agent: Style consistency, performance issues, architectural feedback
7. Architecture Agent: System design patterns, scalability considerations, tech stack decisions
8. Performance Agent: Bundle optimization, runtime profiling, memory leak detection
9. Debug Agent: Stack trace analysis, reproduction steps, fix prioritization
10. Migration/Refactor Agent: Breaking change management, version upgrades, API compatibility
📊 Context Overload Risks
High-Risk Agents:
explore: "Fast agent specialized for exploring codebases"
- Risk: Could load entire codebase into context on large projects
- Mitigation: Needs strict file/line limits for "quick" mode
researcher: "Performs deep research... using a lot of web search"
- Risk: Web search results could dominate context window
- Mitigation: Needs result filtering/summarization before inclusion
general: "General-purpose agent for researching complex questions and executing multi-step tasks"
- Risk: "Multi-step tasks" could chain indefinitely, accumulating massive context
- Mitigation: Needs step/token budgeting
🔄 Recommended Restructuring
Merge & Clarify:
source-control + git-committer → git-agent (unified git operations)
coder-agent + typescript-coder-agent → typescript-dev-agent (TS coding)
- Split
general → task-coordinator (orchestration) + research-agent (investigation)
Fix Language Assumptions:
4. testing → test-agent (language-agnostic) or typescript-test-agent
Add Missing Specialists:
5. frontend-agent (UI/components)
6. backend-agent (APIs/databases)
7. infra-agent (deployment/cloud)
8. security-agent (audit/compliance)
9. review-agent (code quality)
Clarify Ambiguous:
10. executor → system-ops-agent (bash/CLI operations)
11. advanced-coding-manager → project-lead-agent OR remove if overlap with general
🎯 Agent Design Principles Violated
- Single Responsibility Principle:
advanced-coding-manager tries to "analyze, coordinate, validate"
- Clear Interface:
executor vs coder-agent distinction is unclear
- Appropriate Specialization:
testing is Go-specific in TS ecosystem
- No Duplication:
source-control and git-committer identical
- Complete Coverage: Missing frontend/backend/infra specialists
💡 Key Insight
The current agent taxonomy reflects tool capabilities rather than developer workflows. Better to organize around:
- Code Creation (frontend/backend/typescript)
- Code Quality (test/review/security)
- Operations (git/infra/deployment)
- Research (explore/investigate/analyze)
- Coordination (project/task management)
This would create clearer boundaries and better match how developers actually work.