Using octomux

Schedules & loops

Two mechanisms for work that runs without you watching. A loop repeats until a command passes; a schedule fires on a cron.

Loops

A loop is a task with a verify command attached. The agent works, octomux runs the command, and if it exits non-zero the agent restarts in fresh context holding just the failure. It repeats until the command passes, the iteration cap is hit, or it stops making progress.

octomux loop-start --task <id> --verify "npm test" --max-iterations 8

The loop ledger records what each pass changed, whether verify went green, and what it cost.

Fresh context is the point. Re-prompting the same session with a growing transcript is how agents talk themselves into a wrong fix. Restarting with only the failure is what gets a loop through a hard bug.

Schedules

Put a task on a cron and stop remembering to kick it off. Trigger builder, timezone, model and timeout are all in the UI — no YAML to hand-write. Attach a verify command and a schedule becomes a loop that fires on time.

Kinds that ship today: prod-log-triage, overnight-log-summary, doc-drift, daily-plan, weekly-update, slack-watcher, and custom.

Orchestrator

Hand an agent a goal and it writes the spec, splits it into independent tasks, and dispatches each into its own worktree. Each child arrives as a plan naming the files it intends to touch, and nothing starts until you approve it.

What to run unattended

Published guidance on unattended agents is consistent, and it matches what works here: bounded scope, a defined success criterion, isolated changes, reviewed before merge.

Works well	Avoid
CI failure triage, test backfill, dependency bumps, doc drift, issue triage, digests	Auth, payments, infrastructure, production database migrations, and anything shaped like “refactor the codebase”

If you cannot write the verify command, the job is not ready to run unattended. Run it at your desk instead.