You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: parent agent should observe background subagent's real-time progress and streaming output #27898
Allow the parent agent to observe a background subagent's real-time progress and streaming output while it is still running.
Current Behavior
With OPENCODE_EXPERIMENTAL_BACKGROUND_SUBAGENTS=true, a parent agent can launch a background subagent via task(background=true, ...). But once launched, the subagent is a black box — the parent can only poll task_status(task_id="...") which returns the state (running, completed, cancelled) but no intermediate output or progress information.
The only way to interact with a running subagent is task(task_id="...", prompt=...), which resumes/resumes the session but interrupts the agent's current work (it stops what it was doing and responds to the new prompt).
Proposed Feature
Add a mechanism for the parent agent to stream or poll the subagent's real-time output without interrupting it. Options to consider:
Stream endpoint: A way to subscribe to the subagent's tool call outputs and text generations as they happen (similar to tailing logs).
Progress poll: task_status could include a snapshot of the last N tool outputs or the current step description, e.g. task_status(task_id="...", include_progress=true) returning {state: "running", last_output: "Searching the web for X...", tools_called: 3}.
Shared scratchpad: An append-only buffer that the subagent writes to and the parent reads from, without mutual interruption.
Use Case
A parent agent launches multiple background subagents for parallel research tasks and wants to:
See which ones are making progress vs. stuck
Decide which results are ready early to start consolidating
Provide progress feedback to the user without waiting for all subagents to finish
I have searched existing issues and confirm this is not a duplicate.
Related
Builds on the background subagent delegation feature (PR #24174 / issue #21384).
Re-submitted from #27828 — the original issue was closed due to triage bot not assigning labels/staff.
For tasks requiring parent-child agent collaboration — especially when the parent depends on real-time feedback from its subagents to make decisions — being able to observe the subagent's live output would be essential. Without it, the parent has no way to react to intermediate results until the subagent fully terminates.
As I mentioned, regarding scenarios where the parent agent needs to supervise child agents:
First, concerning proactive supervision and early interruption: In certain cases, a child agent might not fully grasp the parent agent's instructions or requirements. In such instances, it is ideal for the parent agent to be able to proactively cancel these sub-tasks. This is also applicable when the parent agent is clearly unsatisfied with the child agent's output, or when the user explicitly requests the parent agent to oversee and guide the child agent until a high-quality deliverable is produced. This is especially true in document-writing scenarios, which often require ongoing mid-course corrections and prompting. For automated workflows where users prefer a hands-off approach, allowing the parent agent to periodically monitor the child agent after receiving the initial command is a much better alternative. Timely interruption and correction of the child agent's reasoning can also significantly save tokens.
Second, concerning asynchronous collaboration and pipelining: Certain workflows require two agents to collaborate—for example, one agent writing code and another writing documentation, where each document corresponds to a code chapter, and all subsequent docs/code depend on previous ones. Based on my experience with similar tasks, in the current implementation, once a child agent finishes, the parent agent collects the output, spins up the next child agent for the next chapter, and then resumes its own tasks. However, in reality, the two agents may operate at different speeds. A child agent might finish its next chapter much earlier, but because the parent agent only assigns one chapter at a time, it sits idle waiting for the parent agent to finish writing, review the progress, and assign the next task. Conversely, sometimes the parent agent finishes first and waits for the child agent, depending entirely on the workload of each chapter, which can vary drastically.
This setup leads to wasted overhead in spinning up child agents repeatedly and idle waiting times on both sides. Efficiency could be significantly improved if this mutual waiting time were utilized. Furthermore, for some workflows, executing all tasks in a single pass feels much more natural. If the parent agent is allowed to fetch the child agent's task progress at any time, it could dispatch all tasks at once while concurrently monitoring them for accuracy and completeness. If the performance falls short, the parent agent can interrupt immediately and provide more detailed guidance. Meanwhile, the parent agent can fetch the child agent's latest results whenever it completes its own chunk of work, allowing the child agent to keep running and the parent agent to advance the overall workflow with the retrieved data. This would make the entire process much more fluid and natural.
One clarification: this request is not primarily about UI visibility (#22233), and it is also broader than post-hoc execution metadata (#23474).
The key missing primitive here is:
the parent agent being able to inspect incremental output/progress from a running subagent without interrupting it.
Concrete use cases:
Early partial-result consumption
A parent launches several research subagents and wants to start consolidating as soon as one of them has produced a usable partial result, instead of waiting for full completion.
Detecting wrong direction early
A subagent may spend a long time exploring an unhelpful branch. If the parent can see intermediate progress, it can decide whether to stop, re-plan, or ignore that branch before the full budget is wasted.
Pipeline workflows
In workflows like code/doc generation or chapter-by-chapter production, the parent should be able to consume completed milestones from the child while the child continues with the next milestone, instead of forcing a strict stop-and-wait loop.
Reacted by SodaWithoutSparkles, Dmitrii-Software-Testing and Riko Ophorst
Activity
YoungJurry commentedon May 16, 2026
For tasks requiring parent-child agent collaboration — especially when the parent depends on real-time feedback from its subagents to make decisions — being able to observe the subagent's live output would be essential. Without it, the parent has no way to react to intermediate results until the subagent fully terminates.
(migrated from original issue #27828)
github-actions commentedon May 16, 2026
This issue might be a duplicate of existing issues. Please check:
nexxeln commentedon May 18, 2026
what are the use cases for this?
YoungJurry commentedon May 18, 2026
As I mentioned, regarding scenarios where the parent agent needs to supervise child agents:
First, concerning proactive supervision and early interruption: In certain cases, a child agent might not fully grasp the parent agent's instructions or requirements. In such instances, it is ideal for the parent agent to be able to proactively cancel these sub-tasks. This is also applicable when the parent agent is clearly unsatisfied with the child agent's output, or when the user explicitly requests the parent agent to oversee and guide the child agent until a high-quality deliverable is produced. This is especially true in document-writing scenarios, which often require ongoing mid-course corrections and prompting. For automated workflows where users prefer a hands-off approach, allowing the parent agent to periodically monitor the child agent after receiving the initial command is a much better alternative. Timely interruption and correction of the child agent's reasoning can also significantly save tokens.
Second, concerning asynchronous collaboration and pipelining: Certain workflows require two agents to collaborate—for example, one agent writing code and another writing documentation, where each document corresponds to a code chapter, and all subsequent docs/code depend on previous ones. Based on my experience with similar tasks, in the current implementation, once a child agent finishes, the parent agent collects the output, spins up the next child agent for the next chapter, and then resumes its own tasks. However, in reality, the two agents may operate at different speeds. A child agent might finish its next chapter much earlier, but because the parent agent only assigns one chapter at a time, it sits idle waiting for the parent agent to finish writing, review the progress, and assign the next task. Conversely, sometimes the parent agent finishes first and waits for the child agent, depending entirely on the workload of each chapter, which can vary drastically.
This setup leads to wasted overhead in spinning up child agents repeatedly and idle waiting times on both sides. Efficiency could be significantly improved if this mutual waiting time were utilized. Furthermore, for some workflows, executing all tasks in a single pass feels much more natural. If the parent agent is allowed to fetch the child agent's task progress at any time, it could dispatch all tasks at once while concurrently monitoring them for accuracy and completeness. If the performance falls short, the parent agent can interrupt immediately and provide more detailed guidance. Meanwhile, the parent agent can fetch the child agent's latest results whenever it completes its own chunk of work, allowing the child agent to keep running and the parent agent to advance the overall workflow with the retrieved data. This would make the entire process much more fluid and natural.
YoungJurry commentedon May 18, 2026
One clarification: this request is not primarily about UI visibility (#22233), and it is also broader than post-hoc execution metadata (#23474).
The key missing primitive here is:
the parent agent being able to inspect incremental output/progress from a running subagent without interrupting it.
Concrete use cases:
Early partial-result consumption
A parent launches several research subagents and wants to start consolidating as soon as one of them has produced a usable partial result, instead of waiting for full completion.
Detecting wrong direction early
A subagent may spend a long time exploring an unhelpful branch. If the parent can see intermediate progress, it can decide whether to stop, re-plan, or ignore that branch before the full budget is wasted.
Pipeline workflows
In workflows like code/doc generation or chapter-by-chapter production, the parent should be able to consume completed milestones from the child while the child continues with the next milestone, instead of forcing a strict stop-and-wait loop.
github-actions commentedon Jul 18, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Dmitrii-Software-Testing commentedon Aug 27, 2026
neeed thiss :(