[Feature Request]Goal rounds busy-loop while long-running subagents are still active

[uxtracer]

Goal rounds busy-loop while long-running subagents are still active

Problem

When a goal spawns a long-running subagent asynchronously, the parent agent can become idle while the child is still running.

At that point, goal-round-driver immediately starts another goal round because the parent agent is idle and the goal is still active/armed.

For long-running subagents, for example tasks that take 10–30 minutes, this can create a busy loop of effectively empty goal rounds:

Goal round N
  -> child is still running
  -> parent decides there is nothing to do
  -> turn ends / parent becomes idle
  -> goal-round-driver immediately starts round N+1
  -> repeat

I tried explicitly instructing the parent agent not to poll or inspect subagent status while a child is running.

The model follows that instruction correctly. For example, it may conclude:

The subagent is still running. No settlement notification has arrived in this round. Remain idle, make no tool calls, keep the goal active, and end the round.

However, this only prevents polling inside the goal round.

It does not prevent goal-round-driver from creating the next goal round, so the parent model is still repeatedly invoked just to conclude that it should continue waiting.

Why this matters

This is especially expensive for local inference and long-context sessions.

Each empty goal round can cause:

• another large-context prefill for the parent model;
• competition between parent and child agents for the same GPU, unified-memory bandwidth, or inference server;
• slower execution of the long-running child agent;
• unnecessary growth of the session history;
• earlier or more frequent context compaction;
• misleading use of goal-round count as a proxy for elapsed waiting time.

In my workload, individual subagents commonly run for around 10 minutes, so this behavior becomes very noticeable.

For example:

Parent goal round
    |
    +-- spawn child agent (~10 min)
    |
    +-- parent becomes idle
            |
            +-- Goal round N+1: "still waiting"
            +-- Goal round N+2: "still waiting"
            +-- Goal round N+3: "still waiting"
            +-- ...

Even if each round produces only a few output tokens, the parent may still pay the cost of repeatedly prefilling a large session context.

Suggested behavior

The goal-round admission logic should distinguish between:

1. the parent agent being truly settled, with no outstanding child work; and
2. the parent agent being locally idle because it is waiting for one or more owned child activations.

Conceptually:

if goal is active + armed
  and parent is idle
  and no owned child activation is still running/waiting:
      start next goal round

else if an owned child is still active:
      do not invoke the parent LLM yet

Ideally, this should be event-driven.

Parent spawns child
    |
    +-- child running
    |
    +-- parent becomes waiting/idle
            |
            +-- no new goal rounds
            |
            +-- child settlement event
                    |
                    +-- wake parent
                    +-- start next goal round

If needed, a wall-clock watchdog could still wake the parent after a configurable timeout to handle stuck or unusually long-running children.

Why prompt-level instructions are not enough

This cannot be solved efficiently through the goal prompt alone.

A prompt can tell the model:

Do not poll while the child is running.

But that instruction only takes effect after the parent LLM has already been invoked.

The unnecessary cost happens one layer earlier, when goal-round-driver decides to start another goal round.

Therefore the suppression needs to happen in goal-round-driver or the equivalent scheduling/admission layer.

Expected behavior

While a goal is waiting on a long-running owned subagent, the parent agent should remain genuinely dormant and consume no LLM inference.

The next goal round should start when:

• a relevant child agent settles/completes;
• all required child agents settle;
• or an explicit timeout/watchdog condition is reached.

This would make /goal much more efficient for agent-team workflows and long-running subagent tasks.

[denial123789]

I traced this against 0.1.1-rc.2 (b150a55). The cost boundary is indeed earlier than the prompt:

• goal-round-driver requests a drive pass from the exact parent Agent’s agent/status: idle event.
• readyToDrive() checks that local Agent status and competing inbox work, but not outstanding child activations.
• The subagent seam already publishes parent-scoped, paired subagent/start / subagent/end edges with a stable runId for both one-shot runs and continuable activation epochs.

That suggests a narrow event-driven repair: keep an active owned-run set per exact parent lifecycle, include its generation in the existing post-checkpoint and pre-step stale-work fences, and reserve the next Goal round only when the set is empty. The final subagent/end should request one coalesced drive pass. An inactive continuable child should not block; the activation epoch, rather than durable child existence, is the scheduling unit.

For current rc.2 containment, synchronous foreground collection avoids the idle admission checkpoint when the parent genuinely cannot progress before the child. Explicit Goal pause/resume also stops automatic rounds, but requires a deliberate resumption owner. A prompt-only “do not poll” policy reduces work inside the round but cannot avoid the parent prefill.

I wrote up the source path, race cases, ownership semantics, observability, and a 16-case regression matrix here: https://sandbaseai.github.io/deepseek-harness-handbook/goal-round-subagent-wait.html

Disclosure: I maintain the SandBase DeepSeek Harness Handbook.

[weijiafu14]

Confirmed at source, and there is a companion report of the same defect filed hours before yours: #4664 hits the identical busy-loop with a long-running background job instead of a subagent. Same handler, same cause. Worth cross-linking so they get fixed together rather than as two special cases.

The mechanism. In @deepseek-ai/dsh-goal-round-driver, the agent/status listener does this on 0.1.1-rc.2:

ctx.on('agent/status', ({ agent, status }) => {
  if (status === 'idle') {
    // …only a "goal was cancelled" branch here…
    requestDrive(state)

requestDrive fires unconditionally. The driver has no concept of "this agent is waiting on something it already started". Your diagnosis that instructing the model not to poll cannot help is exactly right — the instruction governs what happens inside a round, and the re-arm happens between rounds, where the model has no say.

The general shape is that idle is being used as a proxy for "has nothing to do", and it is not one. It only means no turn is currently running.

Now the part that matters for your case specifically: the two reports do not have the same fix, and yours is the harder one.

For #4664's background jobs, the check is cheap and synchronous — JobsService.list(caller?: Agent): JobSnapshot[].

For subagents it splits, and the split is documented in the source. packages/subagent/subagent/src/run-settlement.ts opens with:

Settlement of one ONE-SHOT subagent run into a background-Task outcome. Only the one-shot background path uses Jobs; continuable children have no Task, no per-message result, and no Task cancellation.

So:

• One-shot background children are registered through jobs.start(...) (tool-subagent/src/index.ts:406), which means a jobs-based admission check would cover them for free.
• Continuable children have no Jobs registration at all. The only public way to see them is SubagentsService.listChildren(parentSessionId, signal): Promise<SubagentListEntry[]> — and note the return type. It is async, while the agent/status handler above is a synchronous ctx.on. That is a real design question for whoever implements this, not a detail: either the admission check becomes async (and then "is the agent still idle by the time the answer arrives?" needs an answer), or continuable children need a cheap synchronous liveness signal they do not have today.

If your 10–30 minute children are continuable, the cheap version of the fix will not cover you.

My suggestion for how to frame the request (and I would say the same on #4664): ask for the admission check to be "is this agent waiting on anything it already started", with jobs and subagents as the first two answers, rather than for a subagent special case. Otherwise the next mechanism that lets an agent legitimately stand still — a pending approval, an external wait — arrives and reopens this thread a third time.

One detail from #4664 worth adding to your cost list: their transcript shows the model, forced to speak with nothing new to say, inventing elapsed time ("~15/20/25 min in"). Those sentences land in the session history and later rounds read them as fact. So the empty rounds are not merely expensive, they degrade the context they are paying to re-prefill.

Interest disclosure: I maintain a third-party DSH plugin (a Pi-ecosystem compatibility layer). Goal, jobs and subagents are all DSH's own components — we do not touch them and could not fix this; everything above is source verification.

[Jstn-1g]

Thanks for the precise report, @uxtracer, and for the source-level split called out above by @denial123789 and @weijiafu14. I implemented and independently reviewed a reference against the current 0.1.1-rc.2 base (b150a551b8d):

• exact commit: Jstn-1g@8792231
• reference branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4715-subagent-wait-admission

The reference adds a generic synchronous agent/step-admission bail boundary immediately before durable step/start; there is no await between that check and the commit. goal-round-driver then uses it to revalidate an automatic round against the exact parent lifecycle:

• parent-scoped subagent/start / subagent/end activation epochs fence both one-shot and continuable children while their activation is live;
• exact-owner kind: 'subagent' Jobs additionally close the one-shot provider-start and post-subagent/end disposal gaps;
• the final Job transition schedules one deferred, coalesced recheck after the completion reporter can queue/inject the parent notice;
• owner teardown, session replacement, stale reservations, post-waterfall child start, projection failures, duplicate/stale end events, and other-parent activity all fail closed without consuming a goal round.

Verification includes 114 focused core/goal lifecycle tests, 70 whole-goal/invariant tests with 100% source statements/branches/functions/lines, and real Loader composition in source and built-lib modes proving delayed provider start/result/dispose, no parent goal overlap, and the quiet-completion wake. Host build/lint, client typecheck, Knip, package/constraint/runtime-closure invariants, generated graphs/catalogs/scoped events, type equivalence, and 1003/1003 translation pairings also pass. The pre-push host build and contract typecheck passed on the exact public commit.

Scope is deliberately narrower than “all background work.” A continuable child blocks only while an observed activation epoch is active and relies on the existing continuation-manager settlement delivery to wake its parent. Unowned/generic Jobs and merely discoverable settled continuable sessions are not treated as goal dependencies; the general arbitrary-Job policy remains #4664. Full pnpm run hygiene also still hits an unrelated stale rescope-vendor:check condition present on the untouched official base; all patch-caused hygiene findings are resolved.

This is a reproducible reference implementation for review, not an upstream merge or adoption claim.