Fire-and-Forget Dispatch

The executor dispatches work items (as subagent spawns) and exits immediately. It does not wait for completions. Work status is tracked via external state (GitHub labels, PR status), not in-session acknowledgment.

When to Use

• Batch dispatch of independent work items (e.g., 3–6 issues to fix in parallel)
• The executor is a cron job with a timeout — blocking on subagent completions would hit the timeout
• Completion tracking already exists externally (GitHub PR created = done, CI green = verified)

Architecture

┌──────────────┐     spawn          ┌──────────────┐
│  Executor    │ ──────────────▶   │  Worker 1     │ → creates PR
│  (cron, 3h)  │ ──────────────▶   │  Worker 2     │ → creates PR
│  sonnet      │ ──────────────▶   │  Worker 3     │ → creates PR
│  dispatches  │                    └──────────────┘
│  then exits  │
└──────────────┘
        │
        ▼
     NO_REPLY

Key Design Points

• Claim before dispatch. Update the work item's status label (e.g., status:ready → status:in-progress) before spawning the subagent, not after. This prevents a second executor run from picking up the same item.
• Exit after dispatching. The executor's job is to select work, claim it, and spawn workers. It should not monitor worker progress — that's the job of a separate review cron or manual check.
• Hard timeout on the executor cron. Without an explicit timeoutSeconds, the system default (often 1 hour) applies. An executor that finishes in 2 minutes but has no timeout blocks the lane unnecessarily.
• NO_REPLY when queue is empty. If there's no work to dispatch, return NO_REPLY and stop. Don't post "no work found" messages.
• Workers are independent. Each spawned worker operates in isolation. If one fails, the others are unaffected. Failed items stay status:in-progress until a stale-state detector resets them.

Failure Modes

• Stale in-progress locks — a worker crashes or times out, leaving the item permanently in-progress. Fix: a periodic sweep that resets items stuck in-progress for longer than a threshold.
• Duplicate dispatch — executor doesn't claim before spawning, so the next executor run picks up the same items. Fix: atomic claim (label update) before dispatch.
• Thundering herd — executor dispatches too many workers at once, overwhelming API rate limits or concurrent session limits. Fix: cap dispatches per run (e.g., max 6) and sequence work within the same package/scope.
• Executor blocks on workers — prompt doesn't clearly say "dispatch and exit." The agent waits for worker completions, hits the cron timeout. Fix: explicit fire-and-forget instruction in the cron prompt.

Related

• Multi-Stage Pipelines — fire-and-forget is typically the executor stage of a pipeline
• Specialized Subagents — the workers are usually specialized subagents