[feat] True Async/Background Sub-Agent Delegation #3717

Open
opened 2026-02-16 17:41:12 -05:00 by yindo · 11 comments
Owner

Originally created by @ramarivera on GitHub (Dec 21, 2025).

Originally assigned to: @thdxr on GitHub.

Problem

Currently, sub-agent delegation in opencode appears to be synchronous or modal. When a primary agent delegates a task to a sub-agent, the interface typically switches context to that sub-agent, blocking the primary flow or requiring manual navigation. There is no native "fire-and-forget" mechanism where a sub-agent runs fully in the background while the main agent continues to be interactive, accepting new commands or performing other work simultaneously.

Proposed Solution

Implement a true asynchronous delegation flow:

  1. Delegation: The Main Agent delegates a task (e.g., "Run the integration tests and fix any timeouts").
  2. Async Execution: The Sub-Agent spins up in a dedicated background session.
  3. Non-Blocking: The Main Agent immediately regains control/interactive state, allowing the user to continue working on other tasks.
  4. Completion Notification: The Main Agent receives a signal, message, or callback when the Sub-Agent completes, allowing it to surface the results or integrate the changes.

Related Issues & Community Interest

This feature aligns with high community interest in concurrency and background workflows:

  • #5826 (Agent Session Tab Bar Navigation): Requests UI to manage "concurrent agent sessions" and an orchestrator pattern, highlighting the need to monitor parallel tasks.
  • #1970 (Background Bash Execution): Requests async execution for long-running bash tasks (similar to Ctrl+b), which is a foundational requirement for non-blocking sub-agent work.
  • #4790: Requests fully autonomous systems working with multiple agents concurrently.
  • #4278 (File locks): Proposes safety mechanisms (locking) specifically to handle the "multiple agents/tools in parallel" scenario.

Use Case

  • Orchestration: A main "Architect" agent delegates coding tasks to "Developer" sub-agents and a "QA" sub-agent simultaneously.
  • Efficiency: A user asks the agent to "fix the build" (delegated to sub-agent) and immediately asks "explain this other file" (main agent) without waiting for the build fix to finish.

EDIT: Ofc, AI generated issue, but I did do a search of the docs and similar issues before

Originally created by @ramarivera on GitHub (Dec 21, 2025). Originally assigned to: @thdxr on GitHub. ### Problem Currently, sub-agent delegation in `opencode` appears to be synchronous or modal. When a primary agent delegates a task to a sub-agent, the interface typically switches context to that sub-agent, blocking the primary flow or requiring manual navigation. There is no native "fire-and-forget" mechanism where a sub-agent runs fully in the background while the main agent continues to be interactive, accepting new commands or performing other work simultaneously. ### Proposed Solution Implement a true asynchronous delegation flow: 1. **Delegation:** The Main Agent delegates a task (e.g., "Run the integration tests and fix any timeouts"). 2. **Async Execution:** The Sub-Agent spins up in a dedicated background session. 3. **Non-Blocking:** The Main Agent immediately regains control/interactive state, allowing the user to continue working on other tasks. 4. **Completion Notification:** The Main Agent receives a signal, message, or callback when the Sub-Agent completes, allowing it to surface the results or integrate the changes. ### Related Issues & Community Interest This feature aligns with high community interest in concurrency and background workflows: * **#5826 (Agent Session Tab Bar Navigation):** Requests UI to manage "concurrent agent sessions" and an orchestrator pattern, highlighting the need to monitor parallel tasks. * **#1970 (Background Bash Execution):** Requests async execution for long-running bash tasks (similar to `Ctrl+b`), which is a foundational requirement for non-blocking sub-agent work. * **#4790:** Requests fully autonomous systems working with multiple agents concurrently. * **#4278 (File locks):** Proposes safety mechanisms (locking) specifically to handle the "multiple agents/tools in parallel" scenario. ### Use Case * **Orchestration:** A main "Architect" agent delegates coding tasks to "Developer" sub-agents and a "QA" sub-agent simultaneously. * **Efficiency:** A user asks the agent to "fix the build" (delegated to sub-agent) and immediately asks "explain this other file" (main agent) without waiting for the build fix to finish. EDIT: Ofc, AI generated issue, but I did do a search of the docs and similar issues before
Author
Owner

@github-actions[bot] commented on GitHub (Dec 21, 2025):

This issue might be related to or build upon existing work in the following areas:

  • #1293: The foundational feature request for "subagent" AI task delegation, which this async delegation feature extends
  • #4422: Specific issues with subagent view context and delegation problems that would be addressed by proper async delegation architecture

The issues you've already referenced (#5826, #1970, #4790, #4278) are excellent foundational work for this feature.

Feel free to ignore if this issue has a specific scope different from those above.

@github-actions[bot] commented on GitHub (Dec 21, 2025): This issue might be related to or build upon existing work in the following areas: - #1293: The foundational feature request for "subagent" AI task delegation, which this async delegation feature extends - #4422: Specific issues with subagent view context and delegation problems that would be addressed by proper async delegation architecture The issues you've already referenced (#5826, #1970, #4790, #4278) are excellent foundational work for this feature. Feel free to ignore if this issue has a specific scope different from those above.
Author
Owner

@HelloGGX commented on GitHub (Dec 21, 2025):

This looks like what Claude Code is doing.

@HelloGGX commented on GitHub (Dec 21, 2025): This looks like what Claude Code is doing.
Author
Owner

@itse4elhaam commented on GitHub (Jan 2, 2026):

+1 on this.

Think this would be a big productivity boost.

@itse4elhaam commented on GitHub (Jan 2, 2026): +1 on this. Think this would be a big productivity boost.
Author
Owner

@kdcokenny commented on GitHub (Jan 2, 2026):

+1 on this.

Think this would be a big productivity boost.

https://github.com/kdcokenny/opencode-background-agents
i made this plugin that does this while we wait for an official solution, lmk what you think!

@kdcokenny commented on GitHub (Jan 2, 2026): > +1 on this. > > Think this would be a big productivity boost. https://github.com/kdcokenny/opencode-background-agents i made this plugin that does this while we wait for an official solution, lmk what you think!
Author
Owner

@airtonix commented on GitHub (Jan 3, 2026):

If plugins can do this then there's no need to divert core effort on this .

@airtonix commented on GitHub (Jan 3, 2026): If plugins can do this then there's no need to divert core effort on this .
Author
Owner

@mikekelly commented on GitHub (Jan 17, 2026):

If plugins can do this then there's no need to divert core effort on this .

Totally disagree. Async subagents should be a fundamental affordance of the harness. A lot of additional capability and UX can/will be developed around it.

@mikekelly commented on GitHub (Jan 17, 2026): > If plugins can do this then there's no need to divert core effort on this . Totally disagree. Async subagents should be a fundamental affordance of the harness. A lot of additional capability and UX can/will be developed around it.
Author
Owner

@metka495 commented on GitHub (Jan 20, 2026):

I'm also looking for this feature, looking forward to it!!!!

@metka495 commented on GitHub (Jan 20, 2026): I'm also looking for this feature, looking forward to it!!!!
Author
Owner

@RunFMe commented on GitHub (Jan 29, 2026):

@kdcokenny hi! what do you think about supporting log-monitoring tasks in your plugin? stuff which requires agent to manually go to sleep like

  • looking after ML training run with wake ups every 5 minutes to check no errors are present or fix the source of errors and restart the trainig
  • look at service logs until it starts properly to go and run some other script

It seems that all these tasks can be automated by writing special agents for such polling with specific prompts to instruct them to use "sleep" + turned off doom protection. Wdyt? would you accept such PR to your plugin and help develop it?

@RunFMe commented on GitHub (Jan 29, 2026): @kdcokenny hi! what do you think about supporting log-monitoring tasks in your plugin? stuff which requires agent to manually go to sleep like - looking after ML training run with wake ups every 5 minutes to check no errors are present or fix the source of errors and restart the trainig - look at service logs until it starts properly to go and run some other script It seems that all these tasks can be automated by writing special agents for such polling with specific prompts to instruct them to use "sleep" + turned off doom protection. Wdyt? would you accept such PR to your plugin and help develop it?
Author
Owner

@ifrankwang commented on GitHub (Feb 1, 2026):

Hi OpenCode team, I've analyzed the existing architecture and related issues:

Architecture Alignment:

  • The current TaskTool (packages/opencode/src/tool/task.ts) already supports subagent delegation
  • GlobalBus and Instance Bus provide a native event notification system
  • Session management supports parent-child relationships via ACPSessionManager

Why this proposal is better than the Oh-My-OpenCode approach:

  1. No new dependencies: Uses existing Bus system instead of introducing new delegate_task/background_output tools
  2. Native UI integration: Sub-agent progress can be displayed directly in the TUI without TMUX
  3. Event-driven design: Aligns with OpenCode's existing architecture patterns

Implementation approach suggestion (rough idea):

  1. Extend TaskTool with run_in_background parameter
  2. Use Bus.publish() for task completion notifications
  3. Main agent subscribes to events and retrieves results via existing session APIs

Please consider this feature suggestion, thanks!

@ifrankwang commented on GitHub (Feb 1, 2026): Hi OpenCode team, I've analyzed the existing architecture and related issues: **Architecture Alignment:** - The current `TaskTool` (`packages/opencode/src/tool/task.ts`) already supports subagent delegation - `GlobalBus` and `Instance Bus` provide a native event notification system - Session management supports parent-child relationships via `ACPSessionManager` **Why this proposal is better than the Oh-My-OpenCode approach:** 1. **No new dependencies**: Uses existing Bus system instead of introducing new `delegate_task`/`background_output` tools 2. **Native UI integration**: Sub-agent progress can be displayed directly in the TUI without TMUX 3. **Event-driven design**: Aligns with OpenCode's existing architecture patterns **Implementation approach suggestion (rough idea):** 1. Extend `TaskTool` with `run_in_background` parameter 2. Use `Bus.publish()` for task completion notifications 3. Main agent subscribes to events and retrieves results via existing session APIs Please consider this feature suggestion, thanks!
Author
Owner

@PawelAdamczuk commented on GitHub (Feb 2, 2026):

+1 I would love it too

@PawelAdamczuk commented on GitHub (Feb 2, 2026): +1 I would love it too
Author
Owner

@tomjw64 commented on GitHub (Feb 12, 2026):

Opened https://github.com/anomalyco/opencode/pull/13261, which takes an approach very similar to the one suggested by @ifrankwang.

@tomjw64 commented on GitHub (Feb 12, 2026): Opened https://github.com/anomalyco/opencode/pull/13261, which takes an approach very similar to the one suggested by @ifrankwang.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3717