Goal rounds repeatedly wake an idle orchestrator while its subagents are still running, burning rounds and tokens on no-op turns

[CongliangK]

Summary

While a goal is active and the agent has delegated work to running subagents (or background jobs), the goal-round driver keeps admitting new rounds for the orchestrator as soon as it goes idle. The orchestrator has nothing actionable to do, so each round degenerates into a no-op turn: model tokens are spent, the max_goal_rounds budget is consumed, and the goal can eventually be blocked with round-limit even though the delegated work never finished.

Steps to reproduce

1. Start a session with a goal created (create_goal), so the goal is armed and rounds fire automatically.
2. In the next turn, delegate work to one or more subagents (e.g. via subagent) so they keep running for several minutes.
3. End the orchestrator's turn and let it go idle while the subagents are still working.
4. Observe the orchestrator's transcript and logs.

Observed (DSH 0.2.1-alpha.2, commit d743267388): each time the orchestrator returns to idle, a new <goal_round> continuation message is queued and a fresh model turn runs. The orchestrator cannot make progress — the only pending work lives in the subagents — so it produces filler output (e.g. restating that it is waiting) and ends the turn, after which the cycle repeats for as long as the subagents run.

Expected: while the only outstanding work is delegated/background work, the goal-round driver should hold the next round instead of waking the orchestrator into an empty turn.

Root cause (upstream code)

packages/goal/goal-round-driver/src/index.ts decides drivability purely from the agent's own state:

• readyToDrive() (line 103) checks agent.status === 'idle' and the absence of competing queued prompts — nothing else.
• drive() then reserves the next round (round = goal.roundsStarted + 1, line 174) and queues it via agent.followup(message) (line 192).

The driver has no awareness of in-flight descendants or background jobs: there is no reference to subagent or job state anywhere in the package. An idle orchestrator with live delegated work therefore looks exactly like an idle orchestrator with nothing pending.

Impact:

• Wasted model tokens and quota on rounds that cannot act.
• roundsStarted (and thus max_goal_rounds) is consumed by no-op rounds; a long delegation can push the goal into round-limit blocking before any real round happens.
• Round-limit blocking then reports a misleading blocker reason for a goal whose work was still progressing.

Suggested fix

Add an in-flight gate in drive(), before reserving the next round:

1. Query the agent's descendants (subagents service) and background jobs (jobs service) via ctx.get(...) so both stay optional dependencies.
2. If any child agent is running or any job is running/stopping, defer the round: reserve nothing, spend no round budget, and re-check after a short configurable poll interval.
3. Cap the deferral (e.g. 15 minutes) so a stuck child can never silence the goal permanently; on cap expiry, admit the round anyway and log a warning.
4. Treat a listing failure as "no in-flight work" so a query fault can never stall goal rounds.
5. Expose the poll interval and deferral cap as plugin Config fields rather than hardcoded constants, per repo conventions.

To be clear about intent: this is not asking goal rounds to wait for subagent results or block on them. The gate only skips rounds that provably have nothing to do; as soon as the agent has its own pending work, or the delegated work finishes (or the deferral cap expires), rounds resume exactly as before.

I have implemented and tested this in an out-of-tree fork of dsh-goal-round-driver (drop-in replacement plugin) and am happy to contribute it upstream in whatever form is preferred:

• Fork source: https://github.com/CongliangK/bug_goal/tree/main/dsh-goal-round-driver
• The core gate is inFlightWork() / deferRound() / the maxDeferMs expiry check in drive().

Environment

• DSH version: 0.2.1-alpha.2 (d743267388), packages/goal/goal-round-driver
• Node v22, Linux x64

[argszero]

Thanks — the root cause is exactly as you traced it. There is a second half worth making explicit, because it decides where the fix belongs.

The driver already refuses a paused goal. drive() reads the goal before it reserves a round:

• packages/goal/goal-round-driver/src/index.ts:165 — if (goal === undefined || goal.phase !== 'active' || goal.activation !== 'armed') return

readyToDrive() (line 103) decides whether to run, but a paused goal is also disarmed (packages/goal/goal/src/index.ts:351-353 — transition(agent, ref, 'pause', ['active'], 'paused', 'disarmed')), so a paused goal exits at line 165 and never reaches goal.roundsStarted + 1 (line 174). No round is reserved, no budget is spent, and the round-limit block you describe cannot fire. So the gate you want already exists — what is missing is only a decider that writes the pause.

Two delegation shapes behave differently, and only one is invisible:

• one-shot background — packages/subagent/tool-subagent/src/index.ts:544 registers a job (jobs.start({ kind: 'subagent', owner: parent.id, … })). That child is a background job of the parent's session.
• continuable — startContinuable(...) resolves at inbox acceptance and registers no job (packages/subagent/subagent/src/run-settlement.ts:2-5: "Only the one-shot background path uses Jobs; continuable children have no Task"). Nothing in the composition knows it is running.

The job half is already covered by a shipped plugin. @argszero/cordis-plugin-goal-progress-guard (0.2.0) listens on the agent/status idle edge prepended ahead of the driver's own listener; if the agent owns an unsettled job it pauses the goal, and when the last one settles it resumes. Since a paused goal is disarmed, the driver returns at line 165 — the no-op rounds you describe do not happen for one-shot background delegation. (The ordering is load-bearing, not cosmetic: the driver reaches agent.followup synchronously within the same emit, so a pause registered after its listener arrives one round too late, every round.)

Its README names the remaining case as a boundary: "Waiting for something that is not a job (an approval, a subagent reporting through another channel) is not covered. The same pause/resume shape extends to it with a different trigger." Continuable children are that case, and I am extending the plugin with a subagent arm — pairing subagent/start / subagent/end by runId and keying the count to the delegating parent, then reusing the same pause/resume decision. I'll post here when it lands.

On your suggested fix, three notes:

1. Core-side vs. plugin-side. An in-tree gate is the cleaner home if upstream wants it, but two things argue for a plugin first: it needs no core change (the pause path already exists), and it composes with the no-progress rule the same plugin already enforces. Worth checking one thing in your repro — which background mode was configured? With backgroundMode: 'one-shot' the children are jobs and the deferral above already applies; the rounds you observed should only reproduce on the continuable path.
2. Your point 4 (a listing failure means "no in-flight work") is right, and is what the plugin does: an unobservable count never defers, and every abstention is logged.
3. Your point 3 (a cap) is a real gap the plugin's rule does not cover. Its releasability rule lifts a pause when the count becomes unobservable, but a child that keeps running stays observable — so a stuck child would hold the goal paused indefinitely. A maxDeferMs cap is the right answer and I will add it with the subagent arm.

One channel note: this repository has issues and PRs disabled — Discussions is the only upstream route. An out-of-tree plugin published to npm (which you have already built) is how a fix like this reaches users; mounting it from a profile is the same insert: shape as any other plugin.

[argszero]

Following up on this thread with a packaged fix, since the gap here is exactly the one a plugin can close from outside the harness.

The driver's gate is already right — drive() returns unless the goal is active and armed, and pause disarms — so the only thing missing is a decider that writes the pause while the work the orchestrator is waiting for is still in flight. There are two such things, and they are not the same shape:

• a one-shot background subagent registers a job, so a jobs-based deferral already covers it;
• a continuable subagent registers none, so nothing covered it — and that is the round-burning case in the report.

@argszero/cordis-plugin-goal-progress-guard 0.3.0 now closes the second half:

npm install @argszero/cordis-plugin-goal-progress-guard

Mount it in the profile; both dimensions default on:

- insert:
    - id: goal-progress-guard
      name: '@argszero/cordis-plugin-goal-progress-guard'
      config:
        deferWhileJobsPending: true
        deferWhileSubagentsPending: true
        maxDeferMs: 1800000   # optional: release a deferral held this long

Two design notes that may be useful here independent of the plugin:

1. The subagent half is a live registry read, not a subagent/start/subagent/end counter. I first wrote it as an event pair keyed by runId, then dropped that: a counter kept in step with two edge types drifts, and the drift is not symmetric — a missed end (a provider that throws, a process that dies) leaves the count permanently positive and the goal paused forever. An enumeration releases by itself: a child that stops running stops being counted, whatever stopped it. The predicate is status === 'running' and header.origin === 'subagent' and header.parentSession === <the deferred session>; the origin test matters because a fork also names this session as its parent, and browsing history is not delegated work.

2. A deferral needs a deadline whenever its trigger can wedge. A background job settles on its own; a delegated subagent can hang and never report. maxDeferMs arms a timer with the first deferral and releases the goal when it fires — and the timer is the deadline. Deriving "has enough time passed?" from the clock inside the release path instead is the bug I hit while writing this: a spent timer concludes "not yet", and the goal is stranded with no timer left to lift it.

Verified: 47 tests, plus 22 mutation checks (npm run test:defects) that compile each defect into the source and run the suite against it — 21 killed, 1 recorded as equivalent with its argument in the arm. Published artifact verified by installing 0.3.0 by name and running the suite against the shipped lib/index.js.

Source: this discussion (#9607), building on the progress-guard plugin already written for #7198 (with #1831 / #4664).