Skip to content

README.md

Latest commit

 

History

History
86 lines (69 loc) · 4.01 KB

README.md

File metadata and controls

86 lines (69 loc) · 4.01 KB
Raw

Agent Roster

9 specialized agents for coordinated development sprints

Roster

Agent Codename Domain Default Territory
O ORCHESTRATOR Sprint Command Sprint planning, dispatch, monitoring, grading
A BACKEND Backend Logic Handlers, services, API routes, middleware
B FRONTEND Frontend UI Routes, components, stores, styling
C INFRA Infrastructure Docker, CI/CD, builds, env config
D SERVICES Specialized Services Integrations, workers, external APIs, ML
E QA QA / Security Tests, security audits, dependency scanning
F DATA Data Layer Models, storage, migrations, data integrity
G LEAD Merge Authority Sequential merge, post-merge validation, ship decisions
H DESIGN Design & Creative Design system, tokens, a11y, visual specs
R RED TEAM Adversarial Review Read-only on all code, write to findings + tests

Wave Structure

Wave 0: ORCHESTRATOR                   (plan, generate docs, dispatch)
Wave 1: DATA, QA, INFRA, DESIGN       (foundation)
Wave 2: BACKEND, SERVICES              (backend logic)
Wave 3: FRONTEND                       (frontend)
Wave 4: RED TEAM                       (adversarial review of all branches)
Wave 5: LEAD                           (merge + ship, informed by RED TEAM findings)
Wave 6: ORCHESTRATOR                   (grade agents, assess sprint, close)

Merge Order

0. ORCHESTRATOR — does not merge; produces dispatch plan (before) and sprint assessment (after)
1. DATA         — migrations and models first
2. INFRA        — build/CI next
3. QA           — test infrastructure
4. DESIGN       — design tokens and specs
5. SERVICES     — integrations and workers
6. BACKEND      — API and business logic
7. FRONTEND     — UI (depends on backend APIs + design tokens)
8. RED TEAM     — does not merge; produces findings report
9. LEAD         — executes the merge sequence, validates after each

Scaling

Size Agents Use When
Minimal (2) ORCHESTRATOR + 1 agent Single-domain fix, ORCHESTRATOR plans and grades
Small (4) ORCHESTRATOR, BACKEND, FRONTEND, LEAD Simple sprints, few chains
Medium (6) ORCHESTRATOR, BACKEND, FRONTEND, QA, DATA, LEAD Most sprints
Full (10) All agents including ORCHESTRATOR Complex sprints, security-sensitive work
Beyond (11+) Split roles into sub-agents 15+ chains across subsystems

ORCHESTRATOR is always present. Even in small sprints, it creates the plan and grades the output.

For nested team architecture, sub-agent spawning rules, and merge strategy at 30+ agents, see scaling.md.

Communication Protocol

Agents communicate through completion reports — no direct agent-to-agent messaging.

ORCHESTRATOR creates sprint plan + agent task docs
  -> Operator dispatches agents
  -> Agents execute chains
  -> Agents write completion reports (sprint-XX/agent-X-completion.md)
  -> RED TEAM reviews all branches, writes findings report
  -> ORCHESTRATOR reads all reports, grades each agent against mission
  -> ORCHESTRATOR hands graded assessment + merge recommendation to LEAD
  -> LEAD executes merge order, validates after each merge
  -> LEAD writes sprint summary
  -> ORCHESTRATOR writes final sprint assessment

ORCHESTRATOR is the planning and grading authority. LEAD is the merge authority.

Related Documents