Automation

A goal finishes; a routine doesn't. Muster's automation is four pieces that fit together: routines run a bot on a schedule or webhook, sentries watch and only speak when something actually changed, every run keeps a why-journal of its reasoning, and scorecards grade each run so you can see drift before it becomes a problem.

Routines

A routine pins a prompt to a bot and a trigger. The bot runs it without you in the room, and the run lands in your feed like any other task — output, duration, cost, receipts.

• Triggers — a schedule (fire once at a time, or daily at a set time on chosen weekdays), a manual "run now", or an incoming webhook from another system.
• Where it runs — on the agent as usual, or inside the bot's cloud computer, so a routine can do machine work headlessly.
• Lifecycle — every run is tracked: queued, running, completed, failed, cancelled, or missed (a schedule that couldn't fire gets marked, not silently dropped).
• Overnight chains — set iterations up to 12 and a shared notes file: each run reads what the last one wrote, continues the work, and appends a progress line before finishing. One firing becomes a whole night of chained work.

# a daily routine, in spirit:
name:    spend digest
bot:     Bea (finance bot)
prompt:  Summarize yesterday's spend by vendor, flag anything over budget.
runs:    daily at 08:00, weekdays 1–5

For one-shot outcome work rather than recurring work, use goal mode instead — routines are for things that keep happening.

Sentries

A sentry is a routine with a watcher's temperament: it re-runs the same watching prompt on a cadence, remembers what it saw last time, and only notifies you when the picture changes. The run's reply must end with a SENTRY: line — a one-line summary of current state — and the harness compares that digest line run-over-run.

• First run is baseline. A sentry with no memory records what it saw and stays quiet — the first observation is not news.
• Changed digest → notify. Same digest → silence. A sentry that fails to run also notifies: a watcher that can't watch is itself news.
• Malformed replies can't fake a diff. A reply that forgot the SENTRY: line yields no digest — the old memory is kept, never treated as a change.

# a sentry, in spirit:
prompt:  Check the release page. End with SENTRY: <one-line state>.
runs:    daily
effect:  you hear nothing until the line changes

The why-journal

Receipts record what a bot did — who, how long, what it cost, its final word. They can't tell you why. Every routine run (and other why-enabled runs) asks the bot to end its reply with a short decision journal, parsed mechanically and joined to that run's receipt:

# the journal block the bot appends to a settled run:
WHY: restore the staging deploy
HYPOTHESIS: the new image was failing its health check, not the proxy
FINDINGS: rollback restored green; proxy config untouched
DECISIONS:
- rolled back to the last green image
- pinned the provider to its fallback

• WHY — one line: what the run was trying to accomplish.
• HYPOTHESIS / FINDINGS — what the bot assumed about the world, and what it learned. Two fields that make a journal comparable across runs instead of a pile of prose.
• DECISIONS — up to ten bullets naming the key choices and why.

Over time this is the answer to "why has my recurring bot been doing it this way?" — intent and reasoning, kept per run. A bot that skips the contract produces no entry; an absent journal is data, never a guess.

Routine scorecards

Recurring work rots quietly — a source changes shape, a model regresses, a prompt that worked in March drifts by June. Scorecards catch it: attach deterministic checks to a routine and the harness grades every run's output against them.

• Check kinds — contains (case-insensitive substring), not_contains (forbidden substring), matches (a regular expression).
• Graded harness-side. The bot is told what will be checked so it can self-verify before finishing, but grading happens against the settled output, not on the bot's honor.
• Pass/fail on the run card. Each check shows passed or failed with the reason, so a run is objectively comparable to last week's run — and to the same routine on a different bot.

# scorecard for the spend digest:
mentions total     contains    "total"
no placeholders    not_contains "TODO"
has an amount      matches     \$?[0-9]+

Read the scorecards the way you'd read a teammate's QA: a routine passing nine days out of ten and failing today is a signal, not noise. Combined with the why-journal ("this run assumed the old CSV layout"), drift usually explains itself.

Putting it together

• Recurring report → routine + daily schedule + scorecard for quality.
• Something you need to know about only when it changes → sentry.
• Long background grind that builds on itself → overnight chain with a notes file.
• "Why did it do that?" three weeks later → the why-journal.

Approval rules apply to automated runs exactly as to interactive ones — see Approvals & privacy. Automation runs on the engine the bot is assigned; see Engines & models if you want the cheap model on the night shift.