Conductor / Swarm — Operator Guide

What it is, in one line: a crew of persistent AI workers (“the Swarm”) that Wednesday can hand missions to, run from the workspace web app — your command center at http://100.72.93.65:3000 (Tailscale), the Swarm screen.

The Swarm is a helper layer. It does not replace anything — Wednesday still works the way she always has. The Swarm is for when you want several workers running tasks in parallel, on a board you can watch, instead of one job at a time.

How it’s invoked: everything below is a screen action — a button or field in the Swarm / Conductor screens of the workspace web app. None of it is a chat trigger or prompt you type at Wednesday.

The workers

What it is: six persistent workers — swarm1 (PR/Issues), swarm2 (Backend), swarm4 (Research), swarm5 (Builder), swarm6 (Reviewer), swarm7 (Docs). Each is a long-lived Hermes session on the Mac, running on the SuperGrok subscription (grok-4.3). They keep memory across missions — a worker accumulates knowledge of its area.

Practical case: you open the Swarm screen and see six worker cards. Each shows its state (idle, executing, blocked, …). You don’t create them — they’re already provisioned.

Dispatching a task to a worker

What it is: hand one bounded task to one worker.

How: in the Swarm screen, pick a worker, type the task, dispatch. The task is delivered straight into that worker’s live session; it works, then posts a checkpoint (a short structured report: what it did, files changed, result, any blocker, next action).

Practical case: you give swarm5 (Builder) the task “add a --json flag to the report script and show me the diff.” It runs, and its card flips to a green DONE checkpoint with the diff in the result.

Running a Conductor mission

What it is: hand a bigger goal to the Conductor. It spawns an orchestrator that breaks the goal into tasks and farms them out to several workers at once.

How: the Conductor screen — type the mission goal, submit. Watch the kanban board fill: tasks move backlog → running → review → done.

Practical case: mission “audit the workspace for dead routes and write a short report.” The Conductor splits it — swarm4 researches, swarm6 reviews, swarm7 writes the report — and you watch all three on the board.

Manual vs Auto mode

What it is: the master safety switch. Manual (the default, and the safe resting state) — every dispatch needs your explicit greenlight; nothing runs un-watched. Auto — workers run without a per-task greenlight.

How: the mode toggle in the safety bar at the top of the Swarm screen.

Practical case: you leave it on manual day-to-day. When you have a batch of trusted work and want to let the crew run, you flip to auto, watch a mission, then flip back. After any kill-switch it returns to manual on its own.

The kill-switch

What it is: stops everything, now. It kills every worker session and forces manual mode — so it halts both running work and new work.

How: the red “Kill all workers” button in the safety bar.

Practical case: a mission is going sideways — a worker is editing things you didn’t expect. You hit Kill all workers. Every worker stops, mode drops to manual. Nothing runs again until you deliberately restart it.

The token budget

What it is: a per-day ceiling on Grok token spend across all workers. When the day’s usage hits the ceiling, dispatch is refused — a runaway swarm can’t quietly burn the subscription.

How: the budget readout (used / ceiling) in the safety bar. The ceiling lives in _infra/workspace/.runtime/swarm-safety.json (tokenCeilingPerDay, default 2,000,000); edit that file to change it.

Practical case: you glance at the safety bar mid-day and see 1.4M / 2.0M — plenty left. If it ever reads full, dispatches return a “ceiling reached” error until the 24h window rolls.

The sandbox

What it is: workers write only inside _infra/workspace/ by default. A task that needs to touch the wider vault must say so explicitly ("unsandboxed": true on the assignment). A worker can’t wander into the rest of the vault by accident.

How: automatic — there’s nothing to switch. A dispatch whose worker would land outside the sandbox is refused with a clear message.

Practical case: you dispatch a normal task — it runs in the workspace. You dispatch one that genuinely needs to edit _raw/, marked unsandboxed — it’s allowed. Anything else outside the workspace is blocked.

Checkpoints

What it is: every worker ends a task with a structured checkpoint — STATE (DONE / BLOCKED / NEEDS_INPUT / HANDOFF / IN_PROGRESS), files changed, result, blocker, next action. The latest one is also saved to _infra/config/last_checkpoint.json.

How: read them on the worker cards / the activity feed in the Swarm screen.

Practical case: a worker comes back BLOCKED — the checkpoint tells you exactly what blocked it and what it recommends, so you can unblock and re-dispatch.

Emergency rollback — swarm-excise

What it is: the full teardown. If the Swarm itself needs to go away, this stops every worker, forces manual, and prints exactly what to remove — it deletes nothing on its own.

How: a terminal command, not a screen action: bash _infra/scripts/swarm-excise.sh EXCISE (the literal word EXCISE is required).

Practical case: you’ve decided to retire the Swarm. You run the command; it halts everything and prints the profiles, runtime files, and git commits to remove — you then remove them deliberately.

Subsystem adopted in Phase 3.2 (2026-05-21). Design spec: _infra/docs/superpowers/specs/2026-05-21-conductor-swarm-adoption-design.md.