AI agents are often good at finding the next action, but timing still matters. A change window is a small, explicit period when state-changing automation is allowed to run because the scope, owner, rollback path, and verification checks are known.

For local-first tooling and scheduled automation, change windows do not need heavyweight process. They can be a short note in the runbook that tells the assistant when to act, when to wait, and what evidence must exist before the window closes.

Why timing belongs in the runbook

  • Risk is not constant: the same edit can be safe during a quiet maintenance period and noisy during active use.
  • Retries need boundaries: a job that keeps trying after the window ends can turn a small failure into operational drift.
  • Humans need context: a compact timing note explains why the assistant changed state now instead of later.
  • Verification is easier: post-change checks can be grouped while logs, alerts, and expected outputs are still fresh.

A compact change-window checklist

  • Define the allowed window in generic terms: now, scheduled maintenance, low-traffic period, or human-approved session.
  • Name the exact state changes allowed inside the window.
  • List actions that remain forbidden even during the window, such as destructive cleanup or public notifications.
  • Confirm preflight checks before the first change: current state, inputs, permissions, backups or rollback notes, and expected result.
  • Set a stop time or stop condition so retries do not continue indefinitely.
  • Require a verification receipt before declaring the window closed.

Change-window note template

Change-window note
Task: <generic operation name>
Allowed changes: <small list of state changes>
Window rule: <now, scheduled period, or explicit human approval>
Do not do: <actions still out of scope>
Preflight: <read-only checks before action>
Rollback: <safe undo or restore path>
Stop condition: <time limit, retry limit, or uncertainty trigger>
Verification: <checks required before closing the window>

Good defaults for agent-run change windows

  • Small scope: one artifact, one workflow, or one deployment unit per window.
  • Read-only first: inspection and planning can happen anytime; mutation waits for the window.
  • No silent expansion: if the assistant discovers extra work, it records a follow-up instead of widening scope.
  • Receipt required: the final answer includes what changed, what was skipped, and how success was verified.

Copyable prompt for safe delegation

Before changing state, write a change-window note: allowed changes, window rule, forbidden actions, preflight checks, rollback path, stop condition, and verification. If the current time or context is outside the allowed window, perform read-only diagnostics only and propose the next safe window.

Rule of thumb: agents can investigate almost anytime, but they should mutate only when the runbook says the timing, scope, and rollback path are ready.