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**
```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.

## Success Metrics

- Team plan names each role, owner, write scope, IPC channel, integration point, and stop condition.
- Every delegated workstream has at least one verification gate before integration.
- Final report states integrated status, unresolved risks, and which agents can be closed.

---

## 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.

## Antifragile Swarm Gate

Before spawning agents, assume the environment has fog and friction: incomplete context, stale assumptions, noisy outputs, tool failures, and permission risk. Command the team as a risk-budgeted swarm, not a pile of helpers.

| Gate | Command rule |
|---|---|
| Survival first | Define the maximum acceptable blast radius per teammate. |
| No hero node | No single teammate owns planning, execution, verification, and write-back for a high-risk path. |
| Replaceability | Each teammate has a narrow role, bounded tools, and a handoff format another agent can continue. |
| Mechanical rebalancing | Define when to downweight, kill, replace, or add a reviewer based on cost, error rate, risk, or blocked state. |
| OODA low friction | Observe few signals, orient with the shared plan, decide from finite actions, act in reversible steps, and write back evidence. |

If you cannot name blast radius, kill condition, and verification evidence for a teammate, do not spawn that teammate.

## Antigravity-Style Swarm Boundary

Google I/O '26 described Antigravity as an agent-first development surface with subagents, hooks, async task management, and very large token budgets. Treat this as a cautionary operating pattern: swarm execution is useful only when the harness can prove progress.

Use a swarm only when all are true:

- tasks can be split into independent owned territories
- every territory has objective verification
- an async task queue or visible task list exists
- token, time, and request budgets are capped
- integration happens through a join gate, not direct file collision

Do not scale agent count to create momentum. Scale only when isolation plus verification reduces wall-clock time or improves review quality.

## Dynamic Workflow Choice Gate

Agent teams solve communication and coordination. Dynamic workflows solve width: a reviewed script launches many independent workers, then a synthesis step merges outputs.

Use a dynamic workflow instead of an agent team only when all are true:

- the work shards into many independent files, sources, tests, or review targets
- workers do not need frequent peer communication
- synthesis can merge results from structured outputs
- the generated script can be reviewed before execution
- agent count, model choice, files/directories, wall-clock, and token budget are capped
- runtime state exposes active workers, tool calls, cost, errors, and stop controls
- the workflow is archived in the project only if it is worth reusing

Choose an agent team when roles need IPC, debate, dependency handoffs, shared judgment, or iterative repair. Choose a long-running goal when the hard part is depth: keep