work-items(work): loop orchestrator implements issues inline instead of dispatching per-issue subagents

[kyle-sexton]

Plugin: work-items (skill: work) · Category: behavioral/operational
Source: live loop-lane observation (overnight issue-work lane, 2026-07-19)

Observed

Running /loop /work-items:work, the main loop agent performs the actual issue implementation inline — reading code, editing, building — in its own context, rather than dispatching each picked issue to an isolated subagent and acting as orchestrator.

Why it matters

• Context bloat: implementation detail accumulates in the long-running loop session; quality degrades across cycles until the next restart.
• No parallelism: issues execute serially even when independent (worktree isolation already required per-issue by lane rules).
• Failure isolation: one confusing item pollutes the orchestrator context for every subsequent item.
• Autonomy-ladder posture (L3): orchestrator should manage a hierarchy, not do the work — token-efficient loop sessions are a stated progression requirement.

Fix direction

Codify dispatch posture in the skill: the loop/orchestrating invocation picks the issue, spawns an implementation subagent (seam candidate: implementation:implement-dispatch) with the issue + plan as its brief and worktree isolation, collects the result (PR link / parked-decision payload), and handles only bookkeeping inline. Consider a userConfig knob for max concurrent dispatches (default 2-3). Applies to any skill intended to run under /loop — audit triage (T2 planning pass) for the same inline tendency.

[kyle-sexton]

Live instance, 2026-07-19 loop lane

Concrete confirmation: in this overnight /loop /work-items:work lane the orchestrator did implement #327 fully inline (read/edit request_review.py + babysit_review_trigger.py, wrote regression tests, ran engine.test.sh, bumped version, opened PR #452) before a mid-loop user correction switched it to dispatch posture. After the correction, #373 and #403 were each dispatched to an isolated per-issue-worktree subagent (2 concurrent) with the issue as the brief; the orchestrator retained only pick/claim/bookkeeping. The contrast within one session illustrates the fix direction: the inline item bloated context with full source detail, while the dispatched items kept the loop lean. Supports codifying dispatch posture (with a max-concurrent knob) directly in the work skill so the correction isn't needed manually.

Category: behavioral/operational. Lane: work.

[kyle-sexton]

This was generated by AI during triage.

Triage → needs-human. Behavioral redesign of /work-items:work dispatch posture: the loop/orchestrating invocation should pick the issue, spawn an implementation subagent (seam candidate implementation:implement-dispatch) with the issue+plan as brief and worktree isolation, collect the result, and handle only bookkeeping inline — plus a userConfig max-concurrent-dispatch knob. Autonomy-ladder L3 (orchestrate, don't do the work). Applies to any /loop-run skill. Priority: medium (work-items outside the north-star set). Note: this triage lane already dispatches its T2 planning to subagents, so the pattern is proven.

[kyle-sexton]

This was generated by AI (needs-human queue pass).

Subsumed by umbrella #513 — reclassifying as covered, not separately actionable. This issue asks that the /work-items:work loop dispatch each picked issue to an isolated per-issue subagent instead of implementing inline. #513 (work-lane mini-SDLC) carries an operator decision (2026-07-19 interview) that makes exactly that the design: "the orchestrator spawns an Opus dispatcher that EVALUATES the item's complexity, then spawns the right worker chain … chains of subagents with management hierarchies that divvy work … root agents stay high-level and clean," with implementer ≠ reviewer ≠ verifier as the invariant. The inline-vs-dispatch posture this issue raises is a strict subset of that accepted design, and #513 already lists #451 as its dispatch prerequisite.

One detail here that #513 addresses only implicitly — a max-concurrent-dispatch cap (this issue's proposed userConfig knob, default 2-3) — is a loop-level concurrency limit, distinct from #513's per-item chain composition. Flagging so it is carried into #513's design rather than lost when this closes.

No labels changed. Recommend closing as subsumed by #513 (or folding this thread's dispatch-cap detail into #513).

[kyle-sexton]

Operator decision (2026-07-19, decision-session final batch; relayed). CLOSED AS SUBSUMED by #513 — the operator-accepted mini-SDLC ruling there mandates dispatched, role-separated, fresh-context per-ticket agent chains, a superset of this issue's dispatch ask; #513 already lists this issue as prerequisite context. The loop-level max-concurrent-dispatch cap detail is carried to #513.