From agentops
Routes automation requests to the correct shape (inline, Workflow, ATM swarm, or plain skill) based on reusability and orchestration needs. Prevents over-engineering one-shot tasks into heavy automation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agentops:automation-shape-routingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **HEADLINE TRAP — don't orchestrate a one-shot task.** Before standing up ANY
HEADLINE TRAP — don't orchestrate a one-shot task. Before standing up ANY ATM swarm or Workflow, ask: is this a reusable automation, or a single deliverable I just need produced once? A one-off task ("generate 9 content ideas", "draft this section", "summarize these files") is not an automation — orchestrating it stands up machinery that costs more time than the task. The verdict for a one-shot is shape 0 below: do it inline, or fan out 2–3 in-session Agent subagents. Real failure (2026-06-15): an operator pointed a heavy ATM-codex swarm at a ~9-idea content task; it wedged on codex boot and cost more than doing it inline would have. In-session Agent fan-out later worked in one pass. If you are reaching for ATM or a Workflow, confirm you are not here.
The other trap this kills: "I built a lot of skills; they should become workflows." Mostly false. Most orchestration-looking skills are either long-lived/human-attachable (stay ATM) or hard-sequential (stay skills). The win is the routing rule, not a migration project.
| Shape | What it is | Mechanism |
|---|---|---|
| Shape 0 — inline / in-session fan-out | A one-shot deliverable, not a reusable automation | Just do the task inline. If you want independent drafts / fresh eyes, fan out 2–3 in-session Agent subagents (lightest parallel path — no persistence, no worktrees, read-only-friendly, dies with the session). No ATM, no Workflow, no SKILL.md authored. This is the target of axis-1 "no orchestration." |
| Workflow | Deterministic, reproducible orchestration of subagents | Claude Workflow tool — agent({schema}), parallel(), pipeline(), phase(), loop-until-budget. In-process, headless, ~16 concurrent. |
| ATM swarm | Long-lived, human-in-the-loop multi-agent run | atm (the CLI) driven by /using-atm — 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 reusable procedure or knowledge | A single SKILL.md — authored only when the procedure will be re-run. No fan-out, or a strictly sequential edit-loop. Not the home for a one-off task; that's shape 0. |
Litmus zero — reusable automation, or a one-shot? Ask this FIRST. Are you building something that will be re-run, or just producing one deliverable? One-shot → shape 0: do not route. Do the task inline, or fan out 2–3 in-session Agent subagents. Don't stand up ATM or a Workflow for a single deliverable. Only continue to the axes below if the answer is "reusable automation."
Then ask in order:
Cost-check on axes 2–3 (before committing to fan-out). Parallel buys independence / fresh eyes, not wall-clock at small N — a measured 3-way fan-out tied a single sequential agent (191s vs 180s) and cost ~2.7× the tokens, because the synthesis barrier eats the parallel gain. So at small N, parallel is a tax unless you actually want independent verification. If you just want the answer once, the cheapest correct shape is shape 0 — often a single inline pass. (Full evidence under "Spike-validated nuances" below.)
One-line litmus:
one-shot deliverable, not reusable → shape 0 (inline / in-session Agent fan-out) deterministic DAG + structured JSON + no human-attach + headless-wanted → Workflow long-lived + attachable + open-ended file edits / fluid population → ATM reusable procedure, no fan-out, or hard-sequential edit loop → plain skill
Zeroth question, before the three axes: is this an automation at all, or a
constraint — a "must never regress" rule promoted from a learning? A constraint
is not a process to run; it is a check that blocks. Shape = gate: a warn-only
script under scripts/ + a bats case, flipped to blocking after a soak (the
ratchet ladder's rungs 3-4). Route it through operationalize (its gate
route target), not through the three shapes below.
A live three-legged spike (~/dev/agentops-3cat-spike/) measured the same task on
all three backends. Two findings refine the rule:
Workflow when you
want independent verification / fresh eyes, not for speed. For speed, you need
large N and no barrier — use pipeline() (no barrier), not parallel().Degradation (ATM → Claude-native → beads floor) is governed by the
OrchestrationPort selector; opt out entirely with AGENTOPS_ORCHESTRATION=off →
beads floor, which always works.
loop-until-budget Workflow only once each step
returns structured output instead of free-form edits, and you want it
headless/reproducible.→ Workflow (deterministic fan-out / synthesize, structured returns):
council (N judges → consensus — near-trivial port), the planning half of
rpi, judge/refutation panels, any "fan out N analyses → triangulate" task.
→ Stay ATM (long-lived, attachable, open-ended edits, fluid population):
the *-with-atm family (hypothesis research, cross-model review swarms, browser
testing), plus swarm/crank in full epic-execution mode — they touch the
working tree and need wave-validity gating + human review.
→ Stay plain skill (no exploitable parallelism, or knowledge/one-shot): deliberately one-at-a-time loops (progressive reapply, multi-pass bug hunting); all reference docs; all single-shot transforms (jargon scrub, README authoring).
.claude/workflows/operating-loop.js is the worked example — a real Workflow-tool
script using agent(prompt,{schema}) with JSON schemas, parallel([thunks])
barriers (framing-lenses / judges / refutation / slices), phase() markers,
budget-scaled FANOUT, and bounded re-plan/retry. Start from it when porting a
Workflow. It is also the proof that the AgentOps operating loop has two
conformant runtimes (skill-driven via rpi/crank/swarm/council, and
Workflow-driven via this script) — the basis of the agentops-core-sdk
portability thesis. See operating-loop-workflow for the install+run path.
This skill is the front door. It does not build; it routes. Once the shape is decided, hand off:
| Verdict | Next | What it does |
|---|---|---|
| shape 0 (one-shot) | (no builder — stop routing) | Do the task inline, or fan out 2–3 in-session Agent subagents for independent drafts. Author nothing. |
| plain skill | skill-builder | Scaffold a new SKILL.md against the unified template → then skill-auditor → heal-skill. |
| Workflow | workflow-builder | Scaffold a new .claude/workflows/*.js from the operating-loop.js template. |
| ATM swarm | atm + /using-atm | Stand up + tend an ATM swarm running AgentOps loops (/rpi//evolve) over a bead queue. |
| gate | operationalize (gate route) | Emit a warn-only check script + bats case + CI wiring; flip to blocking after soak. For promoted must-never-regress learnings. |
State the verdict and the deciding axis in one line, then invoke the chosen builder. Do not scaffold here.
A Workflow is a composite capability (an orchestration of sub-capabilities
with typed control flow); a skill is a leaf. The portable contract for this —
a shape: skill|workflow discriminator, a StepGraph, a control_flow enum, a
budget, and an OrchestrationPort interface — is net-new SDK work. Port the
shape, not the engine: keep concrete orchestrators (Codex subagents, swarm
dispatch, scheduler — BC4/BC5) behind adapters.
npx claudepluginhub boshu2/agentops --plugin agentopsAuthors a reusable, deterministic agent orchestration workflow as a self-contained .mjs script for Claude Code's Workflow tool, with structured phases, fan-out, and verification.
Analyzes user tasks to recommend and execute optimal agent orchestration patterns: Sequential Pipeline, Parallel Subagent, Team Mode, Ralph Loop. For complex multi-step tasks or /agent-orchestrate invocation.
Composes valid looplia v0.7.0 workflow YAML/Markdown files from skill recommendations and user preferences. Final step for /build commands, workflow creation, or automation pipelines.