agent-teams-command

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

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

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

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.

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"        → Tes