Repository navigation
[feat] True Async/Background Sub-Agent Delegation #5887
Description
Activity
This issue might be related to or build upon existing work in the following areas:
- [feat] Add "subagent" AI task delegation #1293: The foundational feature request for "subagent" AI task delegation, which this async delegation feature extends
- Primary agent responds in subagent view; delegated subagent views become inaccessible #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.
This looks like what Claude Code is doing.
Reacted by Danila Poyarkov, Jensen, mrh1997, Guilherme Bayer, Steffen, Somshubra Majumdar, Nick Pape, Mike, Aleksandr Baryshnikov, Cateds and 5 more+1 on this.
Think this would be a big productivity boost.
Reacted by Guilherme Bayer, Naufaldi, zero, Luka Finžgar, Cole Murray, gugaio, Shane Bishop, Mimo, alanspires, hollarob and 4 more+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!Reacted by Zeno Jiricek, Mike Kelly, Gautham Chandra, Daniel Maricic, Volod, Cateds, FilJed, Whisillus and Nebojsa KoturovicReacted by Zeno Jiricek, Daniel Maricic and marvReacted by Ted RobertsonIf plugins can do this then there's no need to divert core effort on this .
Reacted by Lopy, Guilherme Bayer, Maarten, Ji, Alexandre Amado de Castro, Muhammed Alkhudiry, Qio, Cole Murray, Spruce Bondera, Mike Kelly and 40 moreIf 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.
Reacted by Gareth Paul Jones (GPJ), Daniel Grigsby, Josh N., Guilherme Bayer, Gregory Leleytner, Ravil Bayramgalin, marv, Alberto Garcia Illera, Volod, Thomas Williamson and 12 moreReacted by Bala Bosch and Jonathan LeadersI'm also looking for this feature, looking forward to it!!!!
Reacted by Gregory Leleytner and Shobhit@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?
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 GlobalBusandInstance Busprovide a native event notification system- Session management supports parent-child relationships via
ACPSessionManager
Why this proposal is better than the Oh-My-OpenCode approach:
- No new dependencies: Uses existing Bus system instead of introducing new
delegate_task/background_outputtools - Native UI integration: Sub-agent progress can be displayed directly in the TUI without TMUX
- Event-driven design: Aligns with OpenCode's existing architecture patterns
Implementation approach suggestion (rough idea):
- Extend
TaskToolwithrun_in_backgroundparameter - Use
Bus.publish()for task completion notifications - Main agent subscribes to events and retrieves results via existing session APIs
Please consider this feature suggestion, thanks!
Reacted by Zhan Rongrui, Thomas Williamson and Dan DowdReacted by Alberto Garcia Illera, Oscar Serna, Dan Dowd, Alexandre Amado de Castro and FilJedReacted by KapK and Dan Dowd- The current
+1 I would love it too
Opened #13261, which takes an approach very similar to the one suggested by @ifrankwang.
Reacted by Frank Wang, Kevin Courbet and FilJed2 remaining items
I do not fully understand what is going on with opencode honestly. Paid claude sonnet 4.6 can spawn multiple subagents while local llama-cpp is forcefully insisting on sequential subagent spawning. I am not sure ... does opencode support it or not?
I do not fully understand what is going on with opencode honestly. Paid claude sonnet 4.6 can spawn multiple subagents while local llama-cpp is forcefully insisting on sequential subagent spawning. I am not sure ... does opencode support it or not?
To be honest, I don't appreciate the criticizing tone.
We should be grateful for open source projects like these.
You can use oh my openagent as an extension to get this and alot more.
Reacted by Jamius Siam@itse4elhaam Please stop getting personal when people are asking questions especially since you did not answer the question in any way or form. If english is not your first language and you see things online colored by the lenses of your personal background, then refrain from lecturing others. It's just inappropriate.
If someone else could comment and answer the question, I'll be happy to see that.
@itse4elhaam Please stop getting personal when people are asking questions especially since you did not answer the question in any way or form. If english is not your first language and you see things online colored by the lenses of your personal background, then refrain from lecturing others. It's just inappropriate.
If someone else could comment and answer the question, I'll be happy to see that.
You just proved my point through your response.
Reacted by allarac, Aristorias and Jamius SiamI do not fully understand what is going on with opencode honestly. Paid claude sonnet 4.6 can spawn multiple subagents while local llama-cpp is forcefully insisting on sequential subagent spawning. I am not sure ... does opencode support it or not?
I’ve noticed it too and was looking for a solution for way too long.
I’m not certain, but it likely comes down to how models invoke tools. When I tried debugging with Opus, models that support parallel sub-agents wrapped multiple tool calls inside<function_calls></function_calls>making it essentially a single call? Other models issued separate calls in one message (one per line), which then ran sequentially. I’m not sure if this can be changed via chat templates or other tweaks. I don’t use llama-cpp, but I assume it behaves similarly. Hope that helps.Reacted by allaracAnother strong +1 for this feature from a plugin developer perspective.
Use Case: Lightweight Async Doc Agent
Our exact workflow:
- Main agent modifies
src/modules/auth.ts - Main agent wants to fire-and-forget a "doc-agent" to update
README.mdand API docs - Main agent must not block — it immediately moves on to modify
src/modules/payment.ts - When doc-agent finishes, its output is piped back to main agent as a callback/message
Why the Current Task Tool Doesn't Fit
The current
tasktool is synchronous / blocking. Aftertask()returns, either:- The sub-agent has fully completed (slow, main agent wastes time waiting)
- Or the sub-agent is "detached" but the main agent receives only a
session_idand loses the ability to get results back naturally
Neither allows the main agent to continue its own work while the sub-agent runs.
Community Workarounds (and Their Limits)
Several plugins have tried to solve this, but all hit core limitations:
Plugin Approach Blocker Pocket-Universe Implements subagent()+broadcast()messaging with synthetic message injectionDepends on PR #9272 ( session.before.idlehook) and #7725 (tool scoping for subagents), both currently unmergedoh-my-opencode Heavy framework with its own session orchestration Too heavy, includes LSP/AST/MCP — overkill for simple fire-and-forget opencode-ensemble Lead agent acts as coordinator only The lead itself does no work — different paradigm What Would Help Most
We don't necessarily need opencode to build a full orchestration framework. What plugin developers need is a minimal core mechanism:
- A
fire_and_forgetflag ontask(orspawntool variant) — returns immediately withsession_id - Event-driven callback — when the sub-agent completes, emit a session event that can be intercepted by plugins (or injected as a synthetic message into the parent session)
- Sub-agent worktree isolation — so parallel agents don't stomp on each other's file changes
PR #13261 by @tomjw64 already explores the background subagent direction. If that lands, plugins like Pocket-Universe could become largely stateless wrappers rather than needing fragile core patches.
Thanks for considering this — it would unlock a whole category of parallel-agent workflows that today require heavy workarounds.
- Main agent modifies
Another strong +1 for this feature from a plugin developer perspective.
Use Case: Lightweight Async Doc Agent
Our exact workflow:
- Main agent modifies
src/modules/auth.ts - Main agent wants to fire-and-forget a "doc-agent" to update
README.mdand API docs - Main agent must not block — it immediately moves on to modify
src/modules/payment.ts - When doc-agent finishes, its output is piped back to main agent as a callback/message
Why the Current Task Tool Doesn't Fit
The current
tasktool is synchronous / blocking. Aftertask()returns, either:- The sub-agent has fully completed (slow, main agent wastes time waiting)
- Or the sub-agent is "detached" but the main agent receives only a
session_idand loses the ability to get results back naturally
Neither allows the main agent to continue its own work while the sub-agent runs.
Community Workarounds (and Their Limits)
Several plugins have tried to solve this, but all hit core limitations:
Plugin Approach Blocker Pocket-Universe Implements subagent()+broadcast()messaging with synthetic message injectionDepends on PR #9272 ( session.before.idlehook) and #7725 (tool scoping for subagents), both currently unmergedoh-my-opencode Heavy framework with its own session orchestration Too heavy, includes LSP/AST/MCP — overkill for simple fire-and-forget opencode-ensemble Lead agent acts as coordinator only The lead itself does no work — different paradigm What Would Help Most
We don't necessarily need opencode to build a full orchestration framework. What plugin developers need is a minimal core mechanism:
- A
fire_and_forgetflag ontask(orspawntool variant) — returns immediately withsession_id - Event-driven callback — when the sub-agent completes, emit a session event that can be intercepted by plugins (or injected as a synthetic message into the parent session)
- Sub-agent worktree isolation — so parallel agents don't stomp on each other's file changes
PR #13261 by @tomjw64 already explores the background subagent direction. If that lands, plugins like Pocket-Universe could become largely stateless wrappers rather than needing fragile core patches.
Thanks for considering this — it would unlock a whole category of parallel-agent workflows that today require heavy workarounds.
U can use https://github.com/kdcokenny/opencode-background-agents it runs in the background while you wait for this to maybe be implemented upstream
- Main agent modifies
Eagerly awaiting this one! Without this, the gap between opencode and claude code is quite wide on subagent orchestration and running background tasks :(
Eagerly awaiting this one! Without this, the gap between opencode and claude code is quite wide on subagent orchestration and running background tasks :(
Yeah would love this natively.
Have you tried oh my openagent extension though?
It's pretty smooth
Eagerly awaiting this one! Without this, the gap between opencode and claude code is quite wide on subagent orchestration and running background tasks :(
Yeah would love this natively.
Have you tried oh my openagent extension though?
It's pretty smooth
I used omo for a not long period ,and i think some times ,it is not so very well
you can see my some tests at https://github.com/smithyyang/omo-vs-opencode-benchmark- marked [FEATURE]: Non-blocking background timer / async ping #31335 as a duplicate of this issue
on Jun 8, 2026 the modal/blocking delegation is the core thing, agreed. the parent shouldnt have to stop and babysit a child to completion.
one external pattern that gives you this today: repowire (a cross-runtime agent mesh). a peer fires
askornotifyto another peer and carries on, the child runs in its own session, and the result comes back as a deferred ack rather than blocking the caller. un-acked asks resurface on the next turn so nothing gets silently dropped.honest framing: repowire peers are separate sessions on a daemon, not in-process background subagents, so its not the exact native shape youre asking opencode for. but if youre blocked on fire-and-forget delegation right now its a way to get it, and it works across runtimes too.
- added a commit that references this issue
on Jul 27, 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.
Problem
Currently, sub-agent delegation in
opencodeappears 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:
Related Issues & Community Interest
This feature aligns with high community interest in concurrency and background workflows:
Ctrl+b), which is a foundational requirement for non-blocking sub-agent work.Use Case
EDIT: Ofc, AI generated issue, but I did do a search of the docs and similar issues before