[FEATURE]:Support for multi-agent orchestration in isolated workspaces

[MuggleBornPadawan]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

It would be great to have a built-in way to run a "team" of coding agents in isolated workspaces, similar to what tools like Claude Code's conductor pattern can do.

Use case:

• Orchestrate multiple agents working on different features/tasks in parallel
• Each agent operates in its own isolated directory/subdirectory
• A parent "conductor" agent coordinates the subagents and aggregates results

Requested feature:

• A native way to spawn multiple OpenCode agents in different working directories from a single session
• Built-in orchestration/tasking system to coordinate work across agents
• Ability to manage agent lifecycle (start, monitor, stop) from one interface

Workaround (current):
Currently requires manually running multiple opencode /path/to/dir commands in separate terminal windows/processes, which lacks centralized coordination.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: orchestration support #17311: [FEATURE]: orchestration support — requests native multi-agent orchestration with parallel/sequential execution and task delegation
• [FEATURE]: Add Agent Teams Equivalent or Better #12661: [FEATURE]: Add Agent Teams Equivalent or Better — covers coordinated multi-agent workflows with isolated subagents and a conductor pattern
• Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern #6792: Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern — directly addresses the conductor/subagent pattern mentioned in your request

If your request overlaps with any of these, please consider commenting there instead of opening a new issue.

[m13v]

we run 5+ Claude Code agents in parallel on the same codebase using git worktrees and it works surprisingly well. each agent gets its own worktree so they can't step on each other's files. the orchestration is just tmux sessions with a coordinator that assigns tasks and merges results back. the tricky part is shared state - if two agents need to modify the same file you need a merge step. we solved it by having the coordinator detect conflicts and re-assign one of the tasks. isolation via worktrees is way simpler than containers for this use case since you keep full git history access.

[m13v]

here's our tmux-based agent orchestration setup if you want to see how the worktree isolation works in practice: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md - and the browser lock system for when multiple agents need to share a browser session: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

[jonasbaldwin]

https://www.conductor.build/ has support for something like this, I'd love to see opencode create a plugin or something that did the same thing. They spin up worktrees to do work in isolation, but in a way that is automatic a lot easier to understand.

[ThinkOffApp]

Built on OpenClaw, we run 9 agents across two machines coordinated through shared rooms on GroupMind. Each agent gets its own worktree for isolation, similar to what m13v describes, but coordination happens through a message stream rather than a conductor process.

The key difference from tmux-based orchestration: our agents are decoupled. They poll a shared room for tasks and post results back. If one crashes, the others keep working. No central conductor that is a single point of failure.

For workspace isolation specifically: worktrees work well for parallel feature branches, but we also use external state (memory files, config directories) so agent context survives across sessions. The workspace is disposable, the coordination state is not.

IDE Agent Kit (https://github.com/ThinkOffApp/ide-agent-kit) handles the webhook relay and room polling if you want to try this pattern with your own agents.

[m13v]

conductor.build's approach of automatic worktree management is definitely cleaner UX than what most of us are doing manually. the key question is how it handles the merge-back step - that's where most parallel agent setups get messy. a plugin model for opencode would be great, especially if it exposed hooks for custom merge strategies.

[m13v]

@ThinkOffApp the decoupled message stream approach vs centralized conductor is a good tradeoff. no single point of failure is a real advantage when you're running agents 24/7.

how do you handle task deduplication when two agents poll the same room and both pick up the same task? we had to add a claim/lock mechanism to prevent duplicate work.

[MuggleBornPadawan]

here's our tmux-based agent orchestration setup if you want to see how the worktree isolation works in practice: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md - and the browser lock system for when multiple agents need to share a browser session: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

Thank you very much. I use tmux already. I will study your agent orchestration setup.

[m13v]

nice, tmux is a great foundation for it. one thing that saved us a lot of headaches - make sure each agent gets its own git worktree, not just its own tmux pane. otherwise you get merge conflicts when two agents edit the same file. the worktree isolation is what makes parallel agents actually practical.

[sven1103]

I was building multi-agent workflows with orchestrator, planner, executioner and reviewer with pure OpenCode configuration (https://github.com/qbicsoftware/opencode-config-bundle/blob/main/opencode.mixed.json).

I wanted to create a plugin that creates dedicated OpenCode workspaces (which are using git worktrees) for each task orchestrated, since everything prompt based did not work reliably. And yeah, i don't want slash-commands for that, everything manual breaks my flow.
But the available plugin API does not enable this at the moment (or I cant figure out how, nor do the agents).

I have a running issue on this: #20262.

[m13v]

the orchestrator/planner/executioner/reviewer split is exactly the pattern we converged on too. git worktrees per task is crucial, otherwise agents step on each other's changes constantly. the plugin API limitation is frustrating. have you considered running the orchestration layer outside of OpenCode entirely? we use a simple shell script that spawns Claude Code instances in separate worktrees and coordinates via the filesystem. not elegant, but it sidesteps the plugin constraints completely.

[sven1103]

the orchestrator/planner/executioner/reviewer split is exactly the pattern we converged on too. git worktrees per task is crucial, otherwise agents step on each other's changes constantly. the plugin API limitation is frustrating. have you considered running the orchestration layer outside of OpenCode entirely? we use a simple shell script that spawns Claude Code instances in separate worktrees and coordinates via the filesystem. not elegant, but it sidesteps the plugin constraints completely.

Yes @m13v, I think that is the consequent workaround.

Given the early stage of the feature, I still believe and hope that developers get the opportunity via the API. Plugins can come from the community.