Stop Babysitting the Babysitter

A controller that repeatedly asks an agent to continue can become another system to maintain. Native continuation and scheduling commands reduce that work. They do not remove the need to define authority, verify results and handle failure honestly.

Three mechanisms, separate responsibilities

Current Claude Code documentation distinguishes condition-driven continuation, session scheduling and durable cloud routines. Select the mechanism by where execution must happen and what should trigger it. The command name does not establish a verification or security guarantee.

Composition is a design, not magic syntax

A backlog controller can select ready work and start a bounded worker. That worker may use native continuation for a task. Treat this as conceptual composition: verify which commands, tools and permissions are available in the selected runtime instead of pasting an interactive recipe into every cloud or SDK environment.

One task with observable acceptance

# vibe — the evaluator has nothing to check
/goal make the auth flow better

# checkable — every clause is an exit code or a fact in the transcript
/goal implement password reset. done means:
  - pnpm test auth-reset exits 0
  - pnpm lint exits 0
  - the reset email carries a single-use token
  - the API test rejects an expired token

The example’s checks are a starting point. They must test the requested behavior on the accepted revision, and the worker must not be able to replace the only acceptance mechanism with a weaker one. A transcript evaluator can read test output, but it does not independently inspect the system.

Use relevant hooks to surface evidence without repeatedly running unrelated tests. Keep failures visible. Native /goal reduces per-turn prompting; its evaluator still makes a model judgment and has documented error, pause and clearing behavior.

Fresh workers for a larger queue

# Illustrative controller: helper interfaces need an implementation.
# Oracle statuses: 0 verified complete, 1 work remains, other = verification failure.
# An external supervisor must also enforce wall-clock and spend limits.
attempt=0
while :; do
  ./done_oracle.sh "$BATCH"
  status=$?
  case "$status" in
    0) exit 0 ;;
    1) ;;
    *) printf '%s\n' 'Verification unavailable; stopping.' >&2; exit 2 ;;
  esac
  if [ "$attempt" -ge 20 ]; then
    printf '%s\n' 'Attempt budget reached; work is not complete.' >&2
    exit 6
  fi
  ticket="$(./ready_set_next.sh "$BATCH")" || exit 3
  [ -n "$ticket" ] || exit 4
  ./run_one_ticket.sh "$ticket" || exit 5
  attempt=$((attempt + 1))
done

This controller is illustrative and requires implementations for its helper interfaces. It distinguishes incomplete work from unavailable verification and applies an attempt bound. A supervisor must additionally enforce time and resource limits, since a single worker can hang or consume substantial resources.

Fresh context at launch reduces accumulated conversation history. A worker still loads instructions and sources, and one invocation can fill or compact its own window. Persist enough task evidence to recover without treating every previous conclusion as established fact.

Local and cloud boundaries

A cloud routine or CI runner can execute independently of a laptop. Its effective exposure depends on supplied credentials, mounts, network access and repository permissions. A worktree only separates working files; a container or runner name does not by itself establish security isolation.

Unattended execution does not inherently require a permission-bypass flag. Configure allowed operations for the task and keep unsupported actions denied or gated. Test cancellation and recovery as carefully as the successful path.

The verifier remains your responsibility

Separate the worker’s report, the controller’s scheduling state and independently checked acceptance evidence. A label saying Done is not independent when the worker can set it. Missing evidence remains unknown, even when the process exits normally.

A hash can detect changes only when the expected value and checking mechanism are protected. Deterministic checks can still be incomplete or based on stale inputs. Preserve the scope and limitations of each check in the final report.

What native commands replace

Native commands can replace portions of custom scheduling and continuation code. Keep the controls that establish acceptance, authorization and resource boundaries. A concise condition helps communicate the goal; it does not substitute for implementing the checks behind that condition.

The practical result should be less repeated prompting and clearer evidence. Measure verified outcomes, failure recovery and intervention reasons before describing a workflow as reliable unattended execution.

Sources: Goals; Session scheduling; Cloud routines. Documentation checked September 20, 2026.