Skip to content

Dispatch Lifecycle

How a single subagent dispatch is composed and kept alive. Binds two patterns surfaced 2026-06-13:

  1. Composite Bash-chain — when a domain edit needs Bash execution, choose the chain shape before dispatching, not after.
  2. Stream-safety standard clause — every dispatch carries a fixed boilerplate that keeps the stream live.

Created 2026-06-13 after a single session burned 3 stream-idle deaths on a Commander (Zoro) and forced 4 main-thread inline recoveries — violating delegation-composition §main-thread ≤20%. The 3-band law tells you the share; this law tells you the shape of each dispatch so the share holds.


1. The composite Bash-chain pattern

Commanders default to Read, Write, Glob, Grep + optional Edit. Bash is captain-only — Jimmy Neutron is the only agent that runs Bash (see delegation-composition). Domain tasks that need both domain code edits AND Bash execution (dry-run, git commit, container exec) are composite work — they must be shaped before dispatch.

Decision tree

  • Does the task need Bash to land?
    • NO → dispatch the owning Commander (Edit only).
    • YES → next question.
  • Is the Bash a thin wrapper around the edit (≤1 dry-run + 1 commit + 1 push)?
    • YES → dispatch Jimmy Neutron with the commander's context file loaded. Prompt opens with Load federation/commander_[name]_context.md. Then: [task]. Domain knowledge transfers via context load; Bash stays captain-side.
    • NO → next question.
  • Is the Bash a separate concern (infra change, container rebuild) downstream of the edit?
    • YES → dispatch the owning Commander for the edit AND Jimmy Neutron in parallel. Jimmy's prompt names the commander's commit SHA as its input (chain-with-dependency: Jimmy reads from main HEAD after Commander commits).
    • NO → the task isn't composite — re-frame.

Anti-patterns

  • Bash-blocked dispatch. A Commander prompt that says "edit X and commit". Silently impossible: the agent edits, then either fails the commit or skips silently. Main thread inherits and burns its own budget. Dominant 2026-06-13 failure mode.
  • Race on parallel-no-dependency. Two parallel agents where Jimmy must read what Commander wrote in the same turn. Jimmy may run before Commander finishes. Use chain-with-dependency only when the dependency is a stable artifact (committed SHA, written file).
  • SHA hand-back to main. A Commander that "tells main thread the SHA so main can commit" — pushes Bash back to main and violates delegation-composition §main-thread ≤20%.

2. Stream-safety standard dispatch clause

Every [Execute] and [Plan] dispatch prompt MUST include a "Stream-safety:" block with three rules:

  1. Progress markers. Emit a short progress line (≤80 chars, 1 sentence) BEFORE each tool call. Example: Step 3: editing constants block.
  2. 60s tool budget. Avoid single tool calls that take >60s (openpyxl load_workbook on the live tracker, long pandas reads, multi-MB Read). Split into multiple short calls.
  3. Read offset/limit. If Read returns >500 lines, narrow the next read with offset / limit parameters.

Why each rule exists

  • Progress markers. Stream-idle-timeout killed silent agents at ~4 calls in 2026-06-13. The agent isn't blocked; the harness just stops trusting the silence. Naming the next tool call before running it is the only durable death-signal.
  • 60s tool budget. openpyxl.load_workbook on the live Bodybuilding tracker takes 40–55s; pair that with a single-call Edit and you cross 60s. Splitting reads keeps each segment fast.
  • Read offset/limit. A Read that returns 800+ lines silently truncates downstream context and burns budget on lines the agent won't use.

When to skip the clause

Single-tool dispatch (one Read + answer) or sub-3-call inspection (typical Explore agent). [Execute] and [Plan] dispatches always carry it.


Cross-links: delegation-composition · true-bottleneck-halt-only · runtime_workflow · memory-architecture · ../format-design/naming-conventions · feedback memory: subagent-progress-markers