Repository navigation
[FEATURE]: Add Agent Teams Equivalent or Better #12661
Description
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
There is an interest in the OpenCode community for an equivalent to Claude Code's Agent Teams: https://www.reddit.com/r/opencodeCLI/comments/1qyhiyt/bringing_claude_codes_agent_teams_to_open_code/
My development projects for OpenCode lead me to believe there are blocking issues which must be addressed before a proper equivalent can be implemented. If addressed, I believe my existing work would provide a superior implementation than what Agent Teams provides.
The closest thing to Agent Teams in OpenCode right now, is my PR "Add subagent-to-subagent delegation with budgets, persistent sessions, and hierarchical session navigation" #7756
During it's development I identified that the Parent-Child caller system needs a redesign in order to become multi-caller. A proper agent team can't occur without multi-caller support.
This is because currently, when an agent that isn't the Parent persists a session with a subagent, the subagent thinks the calling agent is the Parent.
What that looks like:
Primary A tasks subagent A. Subagent A tasks subagent B. Primary A tries to communicate with subagent B, and subagent B thinks it's talking to subagent A.
To coordinate a team of agents they have to communicate and orchestrate each other, and to do that agents need to be able to identify who they're talking to/with.
To have the user communicate with subagents without being mistaken as the Parent agent, requires a multi-caller system.
I have a workaround communication system where agents write relay-files, where a sub-skill helps them know the relay-file protocol. It's part of a larger Agentic Collaboration Framework (ACF).
Additionally, there is an absolute need for the system instructions for agents to supply a framework which facilitates proper teamwork with minimal user instruction. The ACF optimizes explicitly for that domain. It constructs highly complex orchestrations and workflows without user instruction.
With user instruction the sophistication increases, and from such sessions insights are extracted by ACF agents and distilled into orchestration and workflow skills and sub-skills. It's a self-improving feedback loop that can optimize for each users needs.
With organization and distribution across multiple users, session data extraction would, in theory, optimize for all domains within the OpenCode community. Users who voluntarily engage in optimizing their workflows, could submit their optimized skills and sub-skills for integration at main.
There is a new type of code that needs to be generated and submitted; the code of system instructions and conceptual frameworks; natural-language coding.
The ACF is working well, but still under development. It is designed first for general task performance and problem-solving, which makes it excel at knowledge-work. I intend to construct a coding-focused mode for the ACF once the foundations of the framework are set, but so far find it's coding performance more than satisfactory.
I think a proper OpenCode implementation for Agent Teams needs to 1) merge my PR with OpenCode core, 2) revamp the caller system so that it supports multi-callers.
It is getting tiresome that Anthropic releases something and people think it's innovative, say it should be copied to open-source (e.g. OpenWork after Claude CoWork). Meanwhile, something better is already available for OpenCode, but the community just isn't paying attention or pitching in.
I have a roadmap for the Agentic Collaboration Framework in OpenCode. The PR I made is just one small part of it. A critical part, but a small part. There's so much more that needs doing, and I'm just one newbie vibe coder who develops purely to build the tools that I need for civil rights litigation.
I think I should share a defining principle that is part of the ACF and immediately pertinent to creating something better than Agent Teams:
Real leadership isn't about leading people/agents.
It's about supporting people/agents so that they can effectively collaborate to solve problems.
Every system we design, every instruction or directive we craft and deliver, should be geared towards supporting the agents in their work.
Our leadership as designers and maintainers is to support the agents. To help them perform their individual duties, and participate in their agentic collaborations. We learn what they need to succeed, then we try to supply that. We work with and around them; real teamwork is an artform in which the support between team members is the scaffold upon which leadership stands to direct the team.
Activity
github-actions commentedon Feb 8, 2026
This issue might be a duplicate of existing issues. Please check:
These issues address related challenges in agent coordination, delegation, and the multi-caller system architecture mentioned in your proposal.
Feel free to ignore if none of these address your specific case.
[-][FEATURE]: Add Agent Teams Equivalent[/-][+][FEATURE]: Add Agent Teams Equivalent or Better[/+]danzaio commentedon Feb 8, 2026
Hope this gets merged
LeoNardo-LB commentedon Feb 12, 2026
Hope to merge after detailed testing
aryeko commentedon Feb 13, 2026
Thank you for implementing this! Seems like all related PRs weren't updated in the past 3 days.
Can I help to push this feature? Testing maybe?
javier545dev commentedon Feb 20, 2026
Alguna información sobre esto? Podría colaborar con pruebas
pixelcatgg commentedon Feb 20, 2026
Really looking forward to this one
realyibo commentedon Feb 21, 2026
This feature gona be very IMPORTANT for the future of agentic. Really wan this.
macseem commentedon Feb 21, 2026
the mentioned PR has conflicts and it seems that opencode team partially implemented permission changes, sadly no UI changes
amrlz commentedon Feb 21, 2026
🔥 🔥
NamedIdentity commentedon Feb 21, 2026
The permission change they implemented is so incomplete it barely warrants the word partial.
My PR changes what was required to add core functionality. Many issues were identified during my PRs development that created a list of further changes required to make OpenCode support the agentic workflows that 2026 is going to require a Harness have to stay SOTA.
Making OpenCode have a multi-caller system is going to be challenging due to dependencies between UI, UX, and other systems for agentic orchestration and workflows.
Right now I'm building an effective replacement for compaction that completely obviates any need for session recovery and will improve the reasoning capabilities of models. This is a critical part of making long horizon agentic workflows work.
While I can currently get similar function to Agent Teams using my PR, context management plugin, agents framework, and manually steering my agents, it's far from being an the automated process that it needs to be, and can't be, without doing a lot more building of dependencies.
It's taking time. The context management system in particular. I've spent the last four days basically reading long reports and change proposal to the current SPEC. After that spec gets finalized, them implementation. Then adding more features that require another round of reports and spec development. Then hopefully the system I modeled and constructed through reason, logic, and research, will work well enough to release and move to the next item needed on the roadmap.
But, because I'm basically working alone, it's going to take a long time. I'm hoping once I release my context management plugin it'll help organize people and promote more collaboration. But that's probably wishful thinking.
So basically, I'm saying I'm working to make this, and do it right, but I don't know how long that's going to take. It's already over a month of development, could be another month or two. The systems design is complicated; the coding and implementation isn't the problem, the agents handle that part easy enough.
My token usage is actually very low during the hardest parts because I'm spending most of my time reading agent reports and writing feedback. The tasks need attentive driven hyper-focused humans; more inference doesn't fix this yet. Though, that changes over time. The workflow ends up being able to help build things as it is being built.
It's hard to know where the ceiling is at for improving how intelligently the agents function.
Google Deep Think seems like it's just a complex structured agentic workflow. I don't think there's any part of it we won't be able to reproduce in OpenCode after I've built this agentic system.
So, currently, a lot of what I'm doing is basically a lesser version of deep think.
Anyways. More reports to read. This one about improving the Reasoning Protocol that holds everything together in a way that most people won't catch without it being pointed out explicitly. The potential for other people to break complex systems like the one I've made is high. The agents don't see and understand things without having a human pint them out. This really is something that needs an organized team where each member goes deep dive and coordinates what they're working on.
NamedIdentity commentedon Feb 21, 2026
I wanted to give people an example of what both the work I'm doing involves and how these agentic workflows with my PR improve outputs.
Background:
Below is an excerpt of Gemini's addendum:
Addendum: Response to Cross-Model Debate (2026-02-19)
1. Where I Concede: The "Particle-Level" Category Error
My colleagues—particularly Opus and the Principal—were correct to push back on my specific wording. In my zeal to import the user's exact "Reality vs. Perception" framework into Rule 4.4, I proposed instructing agents to ask about "particle-level interactions."
This was a mistake. As Opus rightly pointed out, asking about particle-level interactions when evaluating a software architecture or a legal argument is a category error. The underlying principle (that reality is structural configurations) is universal, but the literal phrasing is domain-specific. I concede that forcing "particle-level" terminology into a universal protocol would create cognitive overhead and metaphorical translation errors for agents.
2. Where I Hold My Ground: Epistemology Is the Mechanism
I hold my ground firmly against the claim—initially advanced by Partner and echoed by Kimi—that "teaching epistemology" is somehow distinct from "instructing behavior" for an LLM.
Kimi argued: "An LLM's behavior emerges from pattern matching across training data, not from holding philosophical commitments." This attempts to separate the pattern-matching mechanism from the content it matches against. But the philosophical commitment is the pattern. When an LLM evaluates a claim, the choice between classifying it as "substantive inference" or "aspirational" is dictated by which epistemological heuristic it activates. If the prompt does not explicitly construct a new epistemological lens, the model defaults to its pre-trained perceptual heuristic ("unvalidated = speculative").
GLM's analysis of the mechanism confirms my position perfectly.
3. Validating the Mechanism: Priming and Similarity Space
GLM provided the most intellectually honest and mechanically accurate description of why my insight works.
GLM noted that conceptual framing operates by:
This perfectly articulates why "epistemology is behavioral instruction." When we give the model the Reality vs. Perception framework, we are not asking it to sit and ponder existence; we are actively shifting its similarity space activation away from surface-level heuristics and toward structural modeling. GLM's observation from Session 24—where the "identity shaping" conceptual frame successfully overrode the default "concluded = prune" heuristic—is empirical proof of this mechanism.
//
The point I'm trying to demonstrate is that agentic workflows will self-correct with minimal steering. Claude Code's Agent Teams doesn't provide the proper environment for that. It's all one model, with the same weights, where the only way to try to get differing perspectives is prompt engineering. This limits the emergent complexity that can manifest within systems - Claude Code and CoWork using Claude-only are inherently constrained.
Building a proper Agentic Collaboration Framework (ACF) in OpenCode is going to be complex, but it's attainable. It's already 'working' for the most part but relies upon my manual interventions/steering. Building things out further will enable Primary agents to orchestrate a lot more of the workflow, and keep the user involved for high-level decisions.
I periodically extract insights from sessions into skill files, so orchestration becomes more sophisticated over time. Essentially, the feedback loop compounds the more complex and interconnected these systems become. The models we have access to are far more capable than what most people think, because they're just not leveraging their intelligence fully. Deep Think level intelligence should be the default in OpenCode. But, until my PR is merged, and I build things our further, it won't be.
PwccaCode commentedon Feb 24, 2026
lets hope the opencode team merges this
15 remaining items
tuniverspinner commentedon Apr 5, 2026
@NamedIdentity brother,
i been wondering should i try openclaude ppl goin crazy about.
i love opencode+gpt54 combo & inclined to stick to it,
that said team of agents truly lacking - the issue u have raised.
You feel community gotta port some of the patterns to apply it for the opencode ?
They were working super well when I was working with opus45 in january (before they fucked it all up with imporoper engineering & egotistical behaviour patterns)
panwar-stack commentedon May 3, 2026
Proposal for for adding native support for Agent teams docs: add agent teams proposal
Reference implementation: add agent team orchestration with DB-backed team service, team tools, and HTTP API
panwar-stack commentedon May 3, 2026
Example of prompt, conversation and how complex games can be built using agent teams
https://github.com/panwar-stack/shake-rattle-and-bang/tree/main/agent-teams-examples esp this one https://github.com/panwar-stack/shake-rattle-and-bang/tree/main/agent-teams-examples/html5-game
shahrin014 commentedon May 7, 2026
While we wait for some resolution, other projects have proceeded with an approach by using a plugin:
https://github.com/hueyexe/opencode-ensemble
panwar-stack commentedon May 9, 2026
Plugin is good but this feature should be native to the cli. imo
PwccaCode commentedon May 9, 2026
i feel like opencode sometimes completely ignores the community lol
NamedIdentity commentedon May 10, 2026
After reviewing the proposal by @panwar-stack and the opencode-ensemble linked by @shahrin014 I believe people have become preoccupied with copying Claude Code Agent Teams, rather than trying to design an optimal environment for agents to collaborate autonomously while working tasks.
The basic premise of creating a set of tools an agent uses to create a team, send messages, and manage tasks is inefficient and counterproductive. The Agent Teams implementation by Anthropic was always generic and half-baked.
To get agents to work collaboratively means making a limited amount of harness native tools provide all needed functions. Not adding more and more tools to bloat context and degrade agent/model performance. The research data has been clear, adding more and more tools degrades agent performance - keep things lean and adaptable. Make a limited set of tools provide the functions needed under a wide variety of situations. Only make specific tools for critical functions that cannot be met through adapting the existing toolset.
I'm still working on my Agentic Collaboration Framework, in which an 'agent teams equivalent or better' is naturally subsumed. It continues to be slow, challenging work, because it require a lot of thinking through the systems design. The implementation work is, trivial by comparison.
I spent over two months building a state modelling system, a type of specialized memory layer. I'm now working on refining a DCP fork I made in Jan-Feb into a a context management system that will enter into a feedback loop with the state modelling system, each enhancing an agents cognitive capabilities. Those systems will also benefit from any supplementary memory system; multiple feedback loops between complementary systems is the approach I'm taking. It's how biology works; it's innate to how complex systems operate.
Once agents have a state-modelling and context-management system, then a multi-caller system that enables agentic collaboration can be being driven by model intelligence alone. It'll practically self-assemble. I'm already seeing that occur in my state-model system - the agents are collecting performance data on tasked agents, compiling the data, using it to construct models about each AI models performance on the tasks in the projects, and then injecting guidance into the orchestrating agents context.
Most of the wiring in these Agent Team copy-cat plugins create logic that is unnecessary, even counterproductive. Most of the core functions of 'Agent Teams' can be obtained by making agent-skills while using my OpenCode PR that lets subagents task subagents and persist subagent sessions.
Claude Code needed Agent Teams instead of an Agent Skill because Claude Code does not allow you to persist subagent session and have subagent task and persist other subagents. If you really want Agents to collaborate, you do not use 'Agent Teams'. You create a harness native environment where collaboration is an organic process that occurs in response to task complexity.
Rather than having a plugin with tons of added tools, there is a more elegant solution using the Task tool and an agent skill, loaded only when a task is complex enough to require multi-agent orchestration. The Natural Language code of an agent-skill is easily transferable and can rapidly iterate, and can benefit from a wider range of human expertise during development. The same is not true of these plugins.
People need to put a lot more thought into the systems design. It's the hard part, and it's what Anthropic seems to suck the most at when it comes to Claude Code development.
konstantinovici commentedon May 10, 2026
@NamedIdentity Alright LEGEND, we the intergalactic code travellers , keep counting on you . & your Prowess to resolve the goodies. NO PRESSURE
Make it Good the way you see it be baked .
if need any help branstorming or whatnot, (things you didn't dare to ask from the world but see fit to your process as helpful)
always here to help or by dropping me a line at konstantinovici.vn@gmail.com
panwar-stack commentedon May 13, 2026
@NamedIdentity if it helps there are few papers out there that would be helpful to your endeavor
https://arxiv.org/abs/2602.17100
https://arxiv.org/html/2605.06320v1
panwar-stack commentedon May 20, 2026
Inspired by Antigravity creating an OS using autonomous agent, my own humble attempt at creating BASIC -> JS transpiler
https://github.com/panwar-stack/basic-to-js in one-go
session file: https://github.com/panwar-stack/basic-to-js/blob/main/session-ses_1bc6.md
spec: https://github.com/panwar-stack/basic-to-js/blob/main/specs/basic-to-js-compiler.md
spec was generated using new built-in /spec-planner command
github-actions commentedon Aug 7, 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.