subagent-external-wait-orchestrator-takeoverlisted

Avoid orchestrator-budget burn when a subagent's main work is done but it's still polling an external event (CI completion, auto-deploy GHA workflow, Cloud Build, gcloud run revision rollout, long-running test suite, etc.). Use when: (1) you've dispatched a subagent with a final-step instruction like "verify auto-deploy" / "wait for CI green" / "poll until revision active", (2) the subagent has already done its substantive work (PR merged, artifact built) and is now in a polling loop, (3) you notice repeated `<task-notification>` events from that agent with `tool_uses: 0` and short `duration_ms` (a few seconds each) — each cycle says "still waiting" or "still in progress" with zero forward progress, (4) each notification forces the orchestrator to spend a turn responding (often dozens of these before the external event completes). The subagent isn't broken — it's doing what you asked — but the polling work belongs to the ORCHESTRATOR, not a subagent. Captures the takeover pattern: dispatch the subagent for th
wan-huiyan/agent-traffic-control · ★ 2 · AI & Automation · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Subagent external-wait → orchestrator-takeover ## Problem You dispatch a subagent with a brief that includes both substantive work AND a final verification step gated on an external event: > "1. Implement … 2. Open PR … 3. Merge … 4. **Verify auto-deploy: poll GHA > workflow + `gcloud run revisions list` until new revision is active.**" Step 4 is **wait work** — the subagent has nothing to compute, only to wait and check. The harness keeps the agent task open during this wait, and each heartbeat / external signal wakes the agent for a tiny no-op cycle: ``` status: completed · tool_uses: 0 · duration_ms: 2000 · result: "Still polling." status: completed · tool_uses: 0 · duration_ms: 2200 · result: "In progress." status: completed · tool_uses: 0 · duration_ms: 1800 · result: "Continuing to wait." ... × 10-20 ... ``` Each cycle costs: - **Subagent**: ~100-300 tokens of additional context per wake (small but accumulates) - **Orchestrator**: ~one full turn to acknowledge the notification (large — the orchestrator's context is bigger and every reply costs) The orchestrator's response cost dwarfs the subagent's polling cost. Over a 13-minute Cloud Build wait, this can be ~10-20 orchestrator turns of "still polling, will report when done" — a non-trivial budget tax for zero work. ## Context / Trigger Conditions ALL of the following: 1. You dispatched a subagent (Task tool with `run_in_background: true`) 2. The subagent's brief includes a "wait + verify" step at the end