Scheduled vs on-demand

Almost every other section of the Playbook teaches on-demand Claude. You trigger, you review, you move on. That’s the right default for most of the work the Playbook covers, but it’s a design choice for a specific use case, not a universal principle. A smaller category of workloads sits better as scheduled, asynchronous Claude — and the diagnostic for telling which is which is worth naming.

On-demand is the Playbook’s default

The Playbook’s whole shape assumes you’re at the keyboard. You write a prompt, Claude works, you read the output, you commit or redirect. The Plan Gate, session hygiene, the 4-prompt flow, the command centre’s anti-cron guidance — all presume a human in the loop, in the same minute as the work. The default is right because most of the work is context-sensitive, the outputs need judgement, and the cost of acting on a wrong output is high enough that auto-applying changes is the wrong shape.

When scheduled fits

A workload genuinely fits a schedule when all four conditions hold:

• Input is bounded and reliable. The job knows what to read; the inputs don’t shift unpredictably between runs.
• Output is always reviewed before any action is taken. The job produces a draft, a report, or a proposed change — never a sent message, a committed merge, or a deployed artefact.
• Failure is observable, not silent. When the job fails, you notice. It logs visibly, opens a draft PR with no body, or sends a “today’s run produced nothing” line into a channel you read.
• The work has a recurring rhythm that doesn’t depend on context that drifts day to day. What you wanted yesterday is what you’ll want tomorrow; today’s project state doesn’t change the rules of the job.

When any one of these is missing, the work belongs on demand. The conditions don’t compose loosely — partial fits are usually traps.

Two examples of legitimate scheduled use

An overnight code-quality pass that produces a draft PR. Run a sub-agent across the codebase at 3 a.m. It checks for one specific class of issue — say, missing return types in TypeScript — and opens a PR with mechanical fixes. The scope is bounded (one issue class), the output is a draft a human reviews and merges, and a failed run produces an empty PR rather than a destructive commit. The four conditions all hold.

A scheduled digest of content you’ve chosen to consume. A morning pull of new RSS items, summarised against a profile you maintain. The inputs are bounded (the feeds), the output is a digest you read (no action taken on your behalf), failure is visible (no digest arrives), and the work doesn’t depend on today’s shifting context. Same shape.

Both examples have the same property: the schedule is doing rote work that would otherwise need you to remember and trigger. Neither one acts on the output; both produce something you read.

When on-demand fits — the command centre as the counter-example

On-demand fits everywhere the four conditions don’t all hold. The Command Centre is the worked example, and its overview names this directly: “Don’t put this on a cron. Run it on demand, when you’re at the keyboard and ready to review outputs. Auto-running multiplies the risk of acting on stale context.”

The command centre’s inputs are personal — your inbox, your calendar, the people you work with, your active projects — and the context that shapes any decent output drifts daily. Running the same workflow against yesterday’s context produces drafts you wouldn’t have endorsed even if they’d been generated yesterday. The command centre fails the four conditions on input stability and context drift, so it stays on demand.

The smaller category of legitimately-scheduled work is real, but it isn’t the default. When in doubt, on demand.