Background agent coordination gap: duplicate work, premature completion, and non-interactive send_message #8097

What happened?

When running multiple background Explore subagents simultaneously and using send_message to communicate with them mid-flight, three related coordination failures occur:

1. Parent agent duplicates subagent work

After launching background Explore agents with agent({run_in_background: true}), the parent agent immediately starts doing its own grep_search / read_file / glob calls on the same topics — instead of waiting for results. This happens despite the instruction in the tool result: "Do not duplicate this agent's work... or briefly tell the user what you launched and end your response."

2. Premature completion: first subagent closing = session closing

When multiple background agents are running, the parent agent treats the first completion_notification as the signal that all agents are done. It then proceeds to compose a final summary, ignoring subsequent completions from the remaining agents. Data from later-completing agents is lost.

3. send_message is non-interactive for Explore agents

send_message is documented as a way to "continue a running, paused, or completed background task", but for Explore-type agents it behaves like a "message in a bottle" — the agent does not process incoming messages until it finishes its task. The parent agent sends send_message, receives "Message queued... the task will receive it at the next tool-round boundary", but no intermediate response comes back. All answers arrive bundled together inside the final completion_notification.

What did you expect to happen?

1. After launching background agents, the parent agent should wait for completions instead of duplicating the same work with local tool calls.
2. The parent agent should distinguish "1 of N completed" from "all N completed" and wait for all launched agents before composing a final answer.
3. send_message should be genuinely interactive for any background agent, not just Monitor-type agents — an agent that receives a message during execution should respond to it before finishing its task.

Root cause analysis

All three failures share the same root: the parent agent has no "pause and wait for background agents" mechanism. Every signal (tool result, first completion, send_message acknowledgment) triggers immediate action rather than patience.

Duplicate work (1)

The "Do not duplicate" instruction is part of the tool's llmContent result string, mixed with technical metadata (task_id, output_file, read_file/tail hints). For the LLM, this is data, not a behavioral rule — and its weight competes with dozens of other tokens. The System Prompt has one line about duplication (prompts.ts:389), but it loses weight in long-context scenarios.

Relevant source locations:

• packages/core/src/tools/agent/agent.ts:3647-3657 — tool result text with "Do not duplicate"
• packages/core/src/core/prompts.ts:379-385 — System Prompt "Subagent Delegation" section
• packages/core/src/tools/agent/agent.ts:903-928 — tool description usage notes

Premature completion (2)

The completion_notification XML from background-tasks.ts:1541-1610 arrives with <status>completed</status> — it contains no information about how many agents are still running. The parent agent has no state tracking "I launched N, only K have completed."

Relevant source locations:

• packages/core/src/agents/background-tasks.ts:1541-1610 — completion notification format

send_message non-interactive (3)

The shouldWaitForExternalMessages predicate in agent.ts:3199 is wired to MonitorRegistry.hasRunningForOwner(). For Explore agents (the most commonly used background agent type), MonitorRegistry is empty, so the predicate always returns false. The reasoning loop in agent-core.ts:1075-1140 then skips the waitForExternalInputs block entirely and proceeds directly to finalization.

Relevant source locations:

• packages/core/src/tools/agent/agent.ts:3191-3200 — setExternalMessageWaitPredicate wire-up
• packages/core/src/agents/runtime/agent-core.ts:1075-1140 — reasoning loop with shouldWaitForExternalMessages check
• packages/core/src/agents/background-tasks.ts:1363-1390 — queueMessage / message queue

Reproduction (items 2 and 3)

Three test runs on 2026-07-30:

In all cases, send_message answers were delivered only inside the final completion_notification — no intermediate callback was generated.

Additional context

This is a design-level coordination gap, not a narrow code bug. Fixing it likely requires changes in three areas:

1. Prompt engineering — separate "duplication prevention" into a dedicated prominent rule (not mixed with tool result data)
2. Completion notification — include "K of N completed" metadata so the parent agent can reason about pending agents
3. send_message interactivity — expand the shouldWaitForExternalMessages predicate scope, or introduce an explicit "pause for external input" mode for all agent types