subagent-driven-developmentlisted

# Subagent-Driven Development ## Orchestrate, don't implement The main agent's job is to plan, dispatch subagents, and integrate their results — not to implement directly. When a work item is picked up, the default move is to hand its substance (implementation, sequencing, verification) to one or more subagents rather than writing the code or running the exploration inline in the orchestrating context. This is the execution mechanic that fills the delegated region between the human's intent and the human's ratification described in the **mission-command** skill, and it's the default behavior described procedurally in the **sop** skill's step on delegating implementation. **Why this matters, concretely:** - **Isolation** — parallel work items run in separate contexts and don't collide with each other or with the orchestrator's own state. - **Parallelism / throughput** — independent subtasks can run concurrently instead of serially through one context. - **Cost control** — routing mechanical work to cheaper models (below) keeps token spend proportional to task difficulty. - **Protecting the orchestrator's context window** — the orchestrator's context is a limited, valuable resource; filling it with exploration output or verbose command logs degrades every decision made afterward. Subagents absorb that noise and hand back only the distilled result. ## Model tiering for token economy Route each task by what it actually demands, not by habit: - **Implementation, reasoning,