The Power and the Danger
The heartbeat will run any prompt on a timer — that’s the point, and that’s the danger. The right workflows on a schedule save you hours every week. The wrong ones run destructive or irreversible actions while you’re asleep, with no one watching. This guide is the decision layer that sits on top of the heartbeat mechanics: what makes a good scheduled job, what must stay on-demand, and how to convert a risky workflow into a safe one. For the schedule formats and how jobs are parsed, see Heartbeat & Scheduling.The One Rule That Matters
Heartbeat jobs auto-approve every tool call. The Amygdala confirmation dialog — your safety net forrm -rf, sudo, sends, payments, and every other destructive action — is bypassed for scheduled runs (see Job Execution). On-demand, a risky call pauses and asks you. On the heartbeat, it just happens.
So every scheduling decision comes down to one question:
Good Candidates
The safest scheduled jobs are read-mostly and reversible — they observe, summarize, and report, or they produce new files without touching existing ones. If the worst case of a buggy run is “it wrote a slightly wrong summary,” it’s a great fit.Read-only / reporting
Reads state and tells you about it. Nothing is modified, so nothing can break.
Idempotent / additive
Produces new output (a file, a digest) and leaves originals untouched. Running it twice is harmless.
Draft, not send
Prepares something for your review — a draft reply, a saved file — without taking the outward-facing action itself.
Bounded blast radius
Scoped to a specific folder, a small batch, or a single account, so even a mistake stays contained.
What NOT to Schedule
These are the red-light categories. Each one assumes the auto-approval rule above — there’s no dialog to stop it once it fires.Destructive / irreversible
Deletes, uninstalls, migrations, overwrites, formatting. Once a scheduled job deletes something, there’s no approval gate and no undo. That kind of excision is a deliberate, one-time, human-approved act — never a timer.
Money / financial
Purchases, trades, transfers, subscription changes, anything that moves funds. Never automate. Full stop.
Outward-facing, unreviewed
Sending email, posting publicly, messaging people, opening PRs — anything others see and you can’t fully take back. Schedule the draft, not the send.
Privileged / system-changing
sudo / Administrator actions, firewall changes, editing system configs, package upgrades that could break a working setup.Judgment-heavy / ambiguous
Tasks where the right move is “it depends” and a wrong guess is costly. The model has no one to ask at 3 AM, so it will guess.
High blast radius
Anything that could touch a wide, unbounded set of files, accounts, or recipients in one run. Scope it down first, or keep it manual.
Make a Risky Workflow Safe to Schedule
Most “no” workflows have a “yes” version. The trick is to schedule the safe half and keep the acting half on-demand:The Pre-Schedule Checklist
Before you paste a prompt intoheartbeat.md, run it through this:
- Read-only or reversible — the worst case is a wrong summary, not lost data
- No money — no purchases, trades, or transfers
- No unreviewed sends — outward-facing actions produce drafts, not final sends
- No privileged commands — no
sudo/ Administrator / destructive shell - Bounded scope — limited to a known folder, batch, or account
- Comfortable unattended — you’d accept this running at 3 AM with no confirmation
See Also
- Heartbeat & Scheduling — schedule formats, job execution, and how jobs are parsed
- Safety Patterns — how the Amygdala classifies and gates tool calls