Agent Teams Command

Agent Teams Command — 安德智能体集群指挥系统 (V8.1)

<skill_contract> <input>A mission with independently ownable workstreams, time SLA requirements, pre-flight task list, token budget, interfaces, permissions, and an integration owner.</input> <output>An isolated worker fleet (5 to 100+ agents), typed IPC ledger, pre-allocated token ledger, serial integration, cleanup, and evidence receipts.</output> <done>Pre-flight task list is 100% reconciled, integrated artifacts pass mission checks, token consumption is within TCLR boundaries, and cleanup gates pass.</done> <non_goals>Parallelism without a task list, unbounded token burn, overlapping writers, or worker self-certification.</non_goals>

Strategic intent and final integration remain serial; owned execution runs in dynamically scaled parallel squadrons (5, 10, 50, 100+ agents). Use the Ender lens for commander intent and squad autonomy, Palantir for operational objects/actions, and von Neumann for executable process architecture. Detailed patterns: references/ender-palantir-command-patterns.md; examples: references/classic-campaigns.md.

Usage Template

Provide: mission, time SLA, task list candidate, workstreams, scaling tier (5/10/50/100+), dependencies, acceptance criteria, token budget (ETC limit), permissions, runtime capabilities, and integration owner.

Workflow

<intake>

1. Mission Intake & Scale Triage: Analyze mission complexity and select the smallest supported tier: Tier 1 (Squad: 5 agents), Tier 2 (Squadron: 10 agents), Tier 3 (Battle Group: 50 agents), or Tier 4 (Fleet: 100+ agents). If the runtime exposes fewer slots, cap the active fleet to that observed limit.
2. Pre-flight Task List & Token Gate: Generate structured task list with explicit owner, territory, expected output, verification command, and token budget (ETC).
3. Territory Mapping: Partition work into non-overlapping directories or git worktrees. Every worker gets strictly exclusive write boundaries.

</intake>

<unknowns_gate>

If dependencies, write ownership, or verification commands are ambiguous, return NEEDS_INPUT or INSUFFICIENT_EVIDENCE. Do not launch parallel workers before pre-flight task list and token ledger are fully reconciled.

</unknowns_gate>

<execute>

1. Launch Workers: Dispatch workers in parallel across isolated worktrees. Each receives a typed context_manifest containing only its objective, dependencies, territory, inputs, output schema, budget, and verifier.
2. Typed IPC & Command Board: Workers report state transitions (pending -> active -> review -> accepted -> closed) to shared command board.
3. Independent Verification: Evaluator and reviewer agents verify worker outputs against objective criteria. No worker self-certification.
4. Serial Integration & Join Gate: Integrator aggregates verified artifacts and receipts in dependency order. Do not merge private branch transcripts into the integration context. Run regression tests.
5. Durable Write-back & Cleanup: Persist execution receipts, update system logs, and clean up temporary worktree branches.

For high-risk operations or cross-repo modifications, require independent review and human approval. Prepare a rollback plan before applying writes.

</execute>

<evaluate>

Audit total token consumption against the mission-declared TCLR: verified tasks resolved per 10,000 effective tokens consumed. Higher is better; do not invent a universal threshold. Verify all workstreams reached accepted or closed state, no file ownership conflicts occurred, and the declared regression suite passed.

</evaluate>

<retry_policy>

max_attempts: 2. Stop on repeated failure signature or NO_PROGRESS. If a worker stalls or fails, reassign territory or downgrade to serial execution rather than launching unbudgeted retries.

</retry_policy>

<state_contract>

Persist {mission_id, run_id, status, attempt, budget, token_ledger, task_list, worker_fleet, context_manifest, command_board, evidence, unknowns, next_action} in durable storage.

</state_contract>