automation-shape-routinglisted

# $automation-shape-routing — Orchestration vs NTM vs Skill > **The trap this kills:** "I built a lot of skills; they should become > orchestration scripts." Mostly false. Most orchestration-looking skills are > either long-lived/human-attachable (stay NTM) or hard-sequential (stay skills). > The win is the routing rule, not a migration project. ## The three shapes | Shape | What it is | Mechanism | |---|---|---| | **Orchestration** | Deterministic, reproducible fan-out / pipeline / loop over sub-agents, each returning structured output | Codex orchestration — `codex exec` driving `spawn_agents` (parallel fan-out), staged pipelines, and loop-until-budget, with an `output_schema` per sub-agent. Headless, reproducible, bounded concurrency. | | **NTM swarm** | Long-lived, human-in-the-loop multi-agent run | `ntm` (the CLI) driven by $using-ntm — persistent tmux panes running whole $rpi/$evolve loops over a bead queue, with attach + nudge + kill/relaunch and mail/locks coordination. | | **Plain skill** | One model reasoning through a procedure or knowledge | A single `SKILL.md`. No fan-out, or a strictly sequential edit-loop. | ## The decision rule (three axes) Ask in order: 1. **Is there real orchestration at all?** (fan-out / barrier / multi-stage, OR a loop with parallelism to exploit) — if **no** → **plain skill**. Stop. 2. **Must a human attach and steer mid-run?** Or does it run for *hours*, do open-ended *file edits*, juggle a *fluid population* (rate limits, k