Agent Teams Command

---
name: agent-teams-command
description: Ender's Game approach to commanding Claude Code Agent Teams. Strategic multi-agent orchestration with Karpathy Agentic Engineering principles — plan, act, observe, iterate. L1-L5 commander progression.
version: "1.2"
updated: "2026-05-18"
---

# Ender's Game: Agent Teams Command System

> "Ender knew, even as he gave the order, that this was the way victory would come — not through strength, but through understanding." — Orson Scott Card

> This is not a "feature" — this is a **command system**. You are not "using" Agent Teams. You are **commanding a fleet**. Based on Karpathy's Agentic Engineering framework, transforming Claude Code Agent Teams into a complete operational architecture.

## Command Philosophy: Ender's Three Principles

| Principle | Meaning | Agent Teams |
|-----------|---------|-------------|
| **Trust Your Commander** | Ender commands through squad leaders, not every soldier | Let Team Lead coordinate; you don't micromanage each agent |
| **Understanding Over Strength** | Study the enemy's thinking | Know each agent's capability; choose Opus vs Sonnet deliberately |
| **Asymmetric Tactics** | Solve problems in unexpected ways | Let agents QA each other; parallel multi-directional exploration |

## Usage Template

**Prompt**
```text
Use agent-teams-command for this project. Split work into roles, define ownership, coordinate progress, and verify the integrated result.
```

**Use Case**
- Coordinating multi-agent work when a task is too large for one linear agent pass.

**Expected Result**
- The agent produces a team plan with roles, responsibilities, communication cadence, integration points, and verification gates.

**Output Example**
- A team map with agent roles, owned files or modules, deliverables, integration plan, and verification checklist.

**Verification Case**
- Each delegated task has a bounded scope, clear owner, expected output, and integration check.

**Verified Effect**
- Parallel agent work becomes coordinated delivery instead of overlapping, unreviewed outputs.

---

## Karpathy Agentic Engineering Mapping

```
You (Commander) = Process Scheduler
Team Lead       = CPU Core
Teammates       = Parallel Processes
Task List       = Shared Memory / IPC
Context Window  = RAM (per agent, isolated)
Tools           = System Calls
QA Loop         = Error Correction / Interrupt Handler
Team Log        = Durable Disk / Write-back
```

---

## Agent Team Operating Model

Use agent teams only when parallel processes reduce wall-clock time or increase quality. Each process needs a bounded territory, explicit IPC, and an integration gate.

| OS concern | Team command rule |
|---|---|
| Process creation | Spawn only for independent or reviewable work. |
| Memory isolation | Give each teammate only the context needed for its scope. |
| IPC | Use task lists, handoff notes, and review reports. |
| Locks | Assign file/module ownership before work begins. |
| Interrupts | Stop or redirect agents when scope, safety, or quality drifts. |
| Join | Integrate only after each output has evidence. |
| Cleanup | Close agents and write lessons to wiki/logs. |

Avoid parallelism when the next step depends on a single blocking decision. Do that work locally, then delegate independent slices.

---

## Command Architecture

```
┌──────────────────────────────────────────────────────────────┐
│                   Fleet Command System                         │
├──────────────────────────────────────────────────────────────┤
│  Phase 0: Plan     — Task decomposition + resource allocation │
│  Phase 1: Act      — Parallel multi-directional exploration   │
│  Phase 2: Observe  — Cross-validation + QA loop               │
│  Phase 3: Iterate  — Refine until quality threshold met       │
│  Phase 4: Learn    — Post-mission review + knowledge capture  │
└──────────────────────────────────────────────────────────────┘
```

---

## Chain of Command

```
You ──→ Team Lead ──→ Teammates
  ↓         ↓            ↓
Strategic  Tactical     Execution
```

### Three-Layer Decision Model

| Layer | Role | Responsibility | Karpathy Equivalent |
|:----:|------|--------------|-------------------|
| **Strategic** | You (Ender) | Set goals, allocate resources, key decisions | Process Scheduler |
| **Tactical** | Team Lead | Task decomposition, agent coordination, quality monitoring | Main Agent Loop |
| **Execution** | Teammates | Execute, call tools, return results | Worker Processes |

---

## L1: Recruit — System Activation

### Initial Setup
```json
// .claude/settings.local.json — Activate fleet command
{
  "experimental.agentTeams": true,
  "teammateMode": "auto"
}
```

```bash
claude --version  # Require ≥ v2.1.32
```

### System Verification (Plan→Act→Observe)
```
Plan:    Verify Agent Teams are available
Act:     Create a 3-agent team for a simple task
Observe: Check multi-color panels are active
Iterate: If failed, check config and version
```

### First Deployment
```
Create a team of 3 teammates using Sonnet.
1. Front-end developer
2. Back-end developer
3. QA agent
Build me a landing page.
```

---

## L2: Squad Leader — Understanding the System

### Agentic Engineering Core Concepts

```
Agent Teams = Multi-processing parallel system
Sub-agents  = Single-threaded sub-processes
```

| Architecture | Sub-agents | Agent Teams |
|-------------|-----------|-------------|
| **Context** | Isolated process, result returns to main | Fully isolated processes |
| **IPC** | Reports to main agent only | **Direct inter-process messaging** |
| **Scheduling** | Main agent manages all | **Shared memory + self-scheduling** |
| **Token Cost** | Lower | Higher (but significantly better quality) |

### Karpathy Engineering Checklist

```
□ Each agent has clear system boundary (Own Territory)
□ Task list managed as shared memory
□ QA loop as error correction mechanism
□ Plan→Act→Observe iteration
□ Resource monitoring (Token cost)
□ Team log captures decisions, evidence, and reusable learning
```

---

## L3: Tactician — Efficient Execution

### Standard Orders Template (Karpathy Plan→Act→Observe)

```
GOAL: [Strategic objective — sets context, like loading system prompt]

ORDERS: Create a team of [N] teammates using [MODEL].

─── TEAMMATE 1 ─── Codename: [NAME] — Role: [ROLE]
  TASK: [Specific task description]
  OWNERSHIP: [file/module ownership]
  DEPENDENCY: Message [TEAMMATE] when done
  
─── TEAMMATE 2 ─── Codename: [NAME] — Role: [ROLE]
  TASK: [Specific task description]
  OWNERSHIP: [file/module ownership]
  DEPENDENCY: Wait for [TEAMMATE] to complete

─── TEAMMATE 3 ─── Codename: [NAME] — Role: QA
  TASK: Validate all outputs
  OWNERSHIP: tests/
  DEPENDENCY: Wait for all teammates

DELIVERABLES:
1. [Deliverable 1]
2. [Deliverable 2]
3. QA report
4. Integration notes + residual risks

QUALITY GATES:
- [ ] All tests passing
- [ ] No critical QA issues
- [ ] No file ownership conflicts
- [ ] Each teammate reports changed files, evidence, and open risks
```

### Three Engineering Laws

| # | Principle | Engineering Meaning | Violation Consequence |
|:-|----------|-------------------|---------------------|
| 1 | **Own Territory** | Each module has a clear owner | File overwrites, logic conflicts |
| 2 | **Direct Messaging** | Inter-process IPC communication | Dependency blocking, serialization |
| 3 | **Wait-for-Dependencies** | Synchronization point management | Data inconsistency, race conditions |

### Command Interface

```
In-process mode:
  Shift+Down = Switch process context
  Escape     = Send interrupt signal (SIGINT)
  Ctrl+T     = View process table (task list)

Split-panes mode (tmux):
  Each process in its own terminal
  Color coding: Red(BE)/Green(FE)/Blue(QA)/Yellow(Research)
```

---

## L4: Commander — Advanced Systems Engineering

### Plan Approval Gate

> Engineering equivalent of "design review" phase.

```text
Spawn an architect teammate to refactor the auth module.
Require plan approval before they make any changes.
```

```
Teammate (Plan Mode) → Submit design proposal
    ↓
Lead → Design review
    ├── Approved → Enter execution phase
    └── Rejected → Revise and resubmit
```

**Review criteria (programmable quality gates):**
```
"Only approve plans that include test coverage"        → Test coverage gate
"Reject plans that modify the database schema"          → Architecture protection gate
"Every plan must have a rollback strategy"              → Rollback strategy gate
```

### Hooks: System Event Callbacks

> Similar to Karpathy's tool-call hook mechanism — triggers callbacks on key system events.

```json
{
  "hooks": {
    "TeammateIdle":   "python scripts/check-idle.py",    // Process idle → reschedule
    "TaskCreated":    "python scripts/validate-task.py",  // Task created → validate
    "TaskCompleted":  "python scripts/verify-quality.py"  // Task done → quality check
  }
}
```

### Multi-Phase Pipeline

> Classic systems engineering pattern: parallel sub-tasks within sequential phases.

```
PHASE 0 — Plan
  3 researchers exploring different directions in parallel
  ↓ Sync point: All directions complete

PHASE 1 — Observe
  Critic reviews all findings
  ↓ Sync point: Consensus reached

PHASE 2 — Act
  Builder executes validated solution
  ↓ Sync point: Execution complete

PHASE 3 — QA (Iterate)
  Full test + fix loop
  ↓ Exit when quality threshold met
```

### Fleet Resource Management

```
Optimal size: 3-5 agents (beyond → scheduling overhead > parallel gain)
Model selection: Sonnet (default) | Opus (complex reasoning) | Haiku (simple tasks)
Token budget: Each agent has independent context window
Cleanup protocol: Lead MUST execute cleanup (otherwise resource leak)
Write-back: Lead records decisions, evidence, and reusable lessons
```

### Resource Cleanup Protocol

```text
1. "Ask [teammate] to shut down"     → Send termination signal
2. Wait for confirmation              → Graceful shutdown
3. Repeat until all teammates down   → All processes terminated
4. "Clean up the team"                → Release shared resources
```

---

## L5: Legendary Commander — Classic Campaigns

### Campaign 1: Full-Stack System Development

```text
GOAL: Build a full-stack app (REST API + React) running on localhost.

ORDERS: Create a team of 3 teammates using Sonnet.

─── TEAMMATE 1 (Codename: GEPARD/BACKEND) ───
  TASK: FastAPI + SQLite + REST endpoints
  OWNERSHIP: backend/
  DEPENDENCY: Notify FALCON when done

─── TEAMMATE 2 (Codename: FALCON/FRONTEND) ───
  TASK: React frontend + API integration
  OWNERSHIP: frontend/
  DEPENDENCY: Wait for GEPARD's API spec

─── TEAMMATE 3 (Codename: SENTINEL/QA) ───
  TASK: E2E tests + API tests
  OWNERSHIP: tests/
  DEPENDENCY: Wait for all teammates

QUALITY GATES:
- [ ] All tests passing
- [ ] API response time <200ms
- [ ] No frontend console errors
```

### Campaign 2: Technical Decision Research

```text
GOAL: Evaluate PostgreSQL → MongoDB migration feasibility.

ORDERS: Create a team of 3 teammates using Opus.

─── TEAMMATE 1 (Codename: OWL/DATABASE) ───
  TASK: Query pattern analysis + performance benchmarks
  OWNERSHIP: research/performance/

─── TEAMMATE 2 (Codename: BEAVER/MIGRATION) ───
  TASK: Migration tool evaluation + downtime analysis
  OWNERSHIP: research/migration/

─── TEAMMATE 3 (Codename: FOX/CRITIC) ───
  TASK: Challenge first two teammates' conclusions
  OWNERSHIP: research/risks/
  DEPENDENCY: Wait for OWL + BEAVER to complete
```

### Campaign 3: Security Audit & Fix

```text
GOAL: Find and fix all security vulnerabilities in the auth module.

ORDERS: Create a team of 2 teammates using Sonnet.

─── TEAMMATE 1 (Codename: EAGLE/AUDITOR) ───
  TASK: OWASP Top 10 scan + code audit
  OWNERSHIP: security/audit/
  DEPENDENCY: Submit issues to BADGER when done

─── TEAMMATE 2 (Codename: BADGER/FIXER) ───
  TASK: Fix all discovered security issues
  OWNERSHIP: src/auth/
  DEPENDENCY: Wait for EAGLE's issue list
```

---

## Quality Gates

### Systems Engineering Checklist

```
[Phase 0: Plan]
□ Tasks decomposed into parallelizable sub-tasks
□ Each sub-task has clear owner and boundary
□ Dependencies modeled

[Phase 1: Act]
□ Agents launched in parallel per plan
□ No file ownership conflicts
□ Inter-process communication normal

[Phase 2: Observe]
□ QA loop executed
□ Issues fed back to corresponding agent
□ Re-verified after fixes

[Phase 3: Iterate]
□ Quality met → exit loop
□ Not met → continue iteration
□ Max iterations exceeded → escalate to commander

[Phase 4: Learn]
□ Post-mission report generated
□ Lessons captured in knowledge base
□ Applicable to future campaigns
□ Teammates closed or explicitly handed off
```

### Diagnostic Matrix

| Symptom | Root Cause | System-Level Solution |
|---------|-----------|---------------------|
| Agent file overwrites | No ownership protocol | Enforce Own Territory |
| Task deadlock | Dependency cycle | Simplify dependency graph, avoid cycles |
| Token explosion | Agent count >10 | Limit to 3-5 agents |
| Insufficient context | Missing initial instructions | Full context in GOAL (like system prompt) |
| Resource leak | Lead didn't run cleanup | Enforce cleanup protocol |

---

## Evolution Timeline

- **2026-05-10**: Created. Agent Teams command system based on Karpathy Agentic Engineering framework. L1-L5 commander progression path. 3 classic engineering campaigns.