Skip to main content

Notification-Driven Self-Paced Dispatch (the /loop Pattern)

In one line: A cadence layer over subagent dispatch — the orchestrator wakes only on observable events (a subagent finished, the build broke, a fallback heartbeat), acts, and sleeps, so a multi-wave plan runs unattended.

What: The /loop pattern is a cadence layer over subagent-driven development (Section 5.4). Instead of blocking on every subagent or requiring a human "go" between tasks, the session schedules itself to wake on observable events — primarily subagent task-completion notifications, secondarily fallback heartbeats. Between wakes it yields its turn entirely; neither the user nor the loop babysits progress.

Why: Sections 5.4 and 3.1 give subagent dispatch and wave parallelism but not temporal autonomy across a multi-wave plan. A large multi-wave plan takes hours of subagent execution. Without /loop, the human must sit at the keyboard saying "go" between tasks, or the session busy-waits (burning context tokens) on every subagent. Both waste the two scarcest things in the system: the human's time and the session's context window.

The /loop pattern resolves both. The session wakes only when something needs deciding (a subagent completed, the build broke, a fallback heartbeat fired), reviews the new state, takes the next action, and goes back to sleep. The user can step away for hours while the plan progresses; when they return, the work is at a checkpoint or a decision point worth their attention.

Three load-bearing rules. Everything else is implementation detail; these three rules are non-negotiable:

  1. Wake-signal hierarchy: notifications > monitors > heartbeats. The orchestrator's primary wake signal MUST be the most specific event available. When dispatching a subagent in background, the subagent's task-completion notification IS the wake signal — no separate Monitor needed (and arming one would cause double-wake on the same event). When watching external state (a CI job, a file change, a PR comment), arm a Monitor with persistent: true that fires on the matching event. Use a cron heartbeat ONLY as a fallback safety net for cases where the notification path might fail. Polling-as-primary-signal is an anti-pattern; the notification machinery exists for a reason.

  2. Cache-aware delay heuristic: 1200-1800s, never 300s. The Anthropic prompt cache has a 5-minute TTL. A loop firing every 4 minutes stays cache-warm but burns 12 cache loads per hour with no progress to show for it. A loop firing every 5 minutes pays one cache miss without amortising it (worst-of-both). The right cadences are under 270s (when actively watching something that's about to change — build finishing, log line about to fire) OR 1200-1800s (when there's no point checking sooner — fallback heartbeats, idle ticks). The 300-600s range is a trap: it feels reasonable in human time, but each fire pays a cold-cache penalty that dwarfs the work the wake actually does.

  3. Self-contained loop prompts: write for the future-you with no memory. The /loop prompt re-enters the session at each wake carrying no conversation context — only the prompt string and memory files. Every prompt MUST read as a cron-message-to-future-self: complete subject-verb-object, no "the X we discussed," explicit pointers to which files/task/wave to continue from. continue M5 fails (which wave? which task?); continue M5 Wave 1 — review pending subagent output, commit if green, dispatch T2→T3→T4 then the Wave 2 fan-out works because it is unambiguous regardless of conversation state.

Evidence: The wake signal IS the mechanism — a subagent's completion notification re-enters the session, which reviews state, commits, and dispatches the next task in well under a minute, with no human in the loop. Reproducible: dispatch a background subagent and observe the session wake on its completion event rather than on a poll. The non-obvious failure modes (stale prompts referencing completed work, redundant Monitors, tight polling) and worked examples are in skill:s4u-loop-dispatch.

The /loop pattern interacts cleanly with the rest of the methodology:

  • The design artifact (Section 3.1) decides what to dispatch; /loop decides when.
  • Wave dispatch (Section 5.4) parallelises within a tick; /loop sequences across ticks.
  • Memory (Section 6) survives loop wake boundaries; conversation context does NOT.
  • STATE.md (Appendix J) is the orientation document the future-you reads at wake — keep it current at every commit so loop wakes have a non-stale entry point.