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
Integrate Agent2Agent (A2A) Protocol for Enhanced Inter-Agent Communication #3023
Is support for the A2A Protocol currently in scope for OpenCode, or planned on the development roadmap? If not, what considerations might influence its inclusion?
OpenCode currently facilitates agent-based workflows through configurations, rules, and subagents, with support for protocols like MCP for agent-tool interactions. To extend this capability, incorporate the Agent2Agent (A2A) Protocol—an open standard for secure, interoperable communication between AI agents across frameworks. This would enable OpenCode agents to collaborate with external agents (e.g., via task delegation, message exchanges, and asynchronous notifications) while maintaining opacity and security. Key benefits include streamlined multi-agent orchestration in software engineering tasks, such as distributed TDD or IaC deployments.
what considerations might influence its inclusion?
In addition to the question about user demand. The contributing guidelines suggest such a core feature would need to pass through a design process with the core team.
@taqtiqa-mark I think this is an extremely interesting space, but each time I think about it I am hard pushed to figure out the tangible benefits a distributed multi-agent system can provide.
The only very clear use case to me is around data exposure, if for example you only wanted your agent to share some partial information with a 3p agent - but I am not clear where that would be beneficial for coding agents, since if the receiving agent only has partial information it is less likely to be able to as good a job as the original agent which would have more information available.
Anyway, would love to hear what ideas you had for why this would be useful for opencode.
Anyway, would love to hear what ideas you had for why this would be useful for opencode.
Definitely wet paint all around. I suppose I have a view of opencode that is probably more like openagent. As you say the "coding-only" use case is probably limited. It'll be interesting to see if opencode is code-only use cases or if the view is that is one of several use cases.
Reacted by Dennis, Tom Daniel, zak and Matt Sparks
Would be great opportunity to have opencode server as an agent via the universal a2a prototol. With human-in-the-loop integration, etc. Have been searching for 3rd party implementations but seems like there are none yet
Also its good because you can create any architecture you want. Not just 1 to many
I absolutely support this feature request. IMO A2A will be the dominant protocol for the integration of agents across technology stacks they are build on. For example, the popular agent framework Agno has adopted it. This feature would allow calling Agno agents to do stuff and vice versa use opencode as an agent for code related tasks in multi-agent solutions built with Agno or any other framework that adopted A2A. As @Melodeiro said, it would enable us to use opencode as an agent in any agentic architecture you want. It's a huge game changer.
Reacted by Melodeiro, Chris Rock, Richard C, Jensen, Marco Dizo, Tom Daniel, cfchou, Luqmaan, zak, FreshStage and 3 more
A2A is backed by the linux foundation so I'm more likely to believe its a protocol that isn't just a fad. I could think of a couple of coding uses cases for a multi-agent system like subagent parallelization and complex orchestration.
I have a ton of A2A agents, it would be super awesome if opencode could leverage the supplied agent skills from the A2A agent card to know how to use that agent. It would make opencode the ultimate developer agent orchestrator.
+1 vote for A2A on this framework. It's the first thing I looked up when discovering this project.
Chiming in to add my support for this or something similar. Similar to @taqtiqa-mark's POV, at our company we're beginning to see opencode as more of an openagent and want to build our agents platform around it. Very intrigued by Dax's tweet about a company that's already doing this (with some reported friction, I wonder if this topic is related).
The rationale being opencode is basically a general purpose computer-using agent, it's extremely powerful and easy to morph into whatever you want it to be (I don't need to convince anybody here of that) -- unlike going the framework route (Langchain, AI SDK, etc. which has its benefits, sure). Unsurprisingly, people are naturally gravitating towards opencode as their "framework" of choice, probably because it's the easiest way to build an agent that works similar to how those people work right now (with files, CLI tools, etc.) and it's extremely easy to iterate on because coding is not a requirement.
Teams within the company are already making opencode agents that are really good at operating within a specialized domain; e.g, we're building an opencode powered agent for answering questions about our data lake via a combination of tacit knowledge encoding (markdown files/skills informing the agent on how to think about and query the data) and various CLI + MCP tools to actually perform queries. Again, no code needed except for helper functions, which is why this route is so lucrative.
The thing is these agents are running on people's laptops and we want to productionize them (presumably using the opencode SDK). Figuring out auth, service accounts, interaction logic, etc. are problems we can work on internally but it seems like a major missing piece is the ability for opencode sessions to call upon remote agents as if they were local subagents.
This is where A2A or some similar "remote subagent" system could help us.
Reacted by FreshStage, Max Hillaert, tx1ee, thuanpham582002, kfox1111 and Fahim Ali Zain
unlike going the framework route (Langchain, AI SDK, etc. which has its benefits, sure).
I've been pushing in various issues for PocketFlow to be adopted, which would simplify implementation of lots of functionality - they have a A2A PoC in their cookbooks folder.
I'm starting to get strong not-invented-here vibes around this project... hopefully I'm wrong.
@zxkxyz, one issue I've been running into that is a concern in production settings, and fatal in regulated settings, is prompt injection attacks from the project: I turn off everything I can, and the LLM still gives me the OC spiel. I believe this would also break any non-trivial A2A use cases.
Similar to @taqtiqa-mark's POV, at our company we're beginning to see opencode as more of an openagent and want to build our agents platform around it.
In the spirit of calling out excellent engineering and design....
I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues:
Chiming in to add my support for this or something similar. Similar to @taqtiqa-mark's POV, at our company we're beginning to see opencode as more of an openagent and want to build our agents platform around it. Very intrigued by Dax's tweet about a company that's already doing this (with some reported friction, I wonder if this topic is related).
The rationale being opencode is basically a general purpose computer-using agent, it's extremely powerful and easy to morph into whatever you want it to be (I don't need to convince anybody here of that) -- unlike going the framework route (Langchain, AI SDK, etc. which has its benefits, sure). Unsurprisingly, people are naturally gravitating towards opencode as their "framework" of choice, probably because it's the easiest way to build an agent that works similar to how those people work right now (with files, CLI tools, etc.) and it's extremely easy to iterate on because coding is not a requirement.
Teams within the company are already making opencode agents that are really good at operating within a specialized domain; e.g, we're building an opencode powered agent for answering questions about our data lake via a combination of tacit knowledge encoding (markdown files/skills informing the agent on how to think about and query the data) and various CLI + MCP tools to actually perform queries. Again, no code needed except for helper functions, which is why this route is so lucrative.
The thing is these agents are running on people's laptops and we want to productionize them (presumably using the opencode SDK). Figuring out auth, service accounts, interaction logic, etc. are problems we can work on internally but it seems like a major missing piece is the ability for opencode sessions to call upon remote agents as if they were local subagents.
This is where A2A or some similar "remote subagent" system could help us.
I second this. I'm using opencode as a computer-using general purpose agent as well as a coding agent. It processes emails, documents , using my browser , etc. All I'm missing is orchestration between opencode instances beyond sub agents and A2A seems like the missing piece.
Reacted by Timo, rsdenijs, Maxim Crabbé, El AI and Melih Yıldız
Activity
github-actions commentedon Oct 8, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
rekram1-node commentedon Oct 8, 2025
haven't heard much of a stir for this, but if a lot of people start asking for it, it may be prioritized, but afaik you are the first to ask for it
taqtiqa-mark commentedon Oct 8, 2025
In addition to the question about user demand. The contributing guidelines suggest such a core feature would need to pass through a design process with the core team.
ydennisy commentedon Oct 25, 2025
@taqtiqa-mark I think this is an extremely interesting space, but each time I think about it I am hard pushed to figure out the tangible benefits a distributed multi-agent system can provide.
The only very clear use case to me is around data exposure, if for example you only wanted your agent to share some partial information with a 3p agent - but I am not clear where that would be beneficial for coding agents, since if the receiving agent only has partial information it is less likely to be able to as good a job as the original agent which would have more information available.
Anyway, would love to hear what ideas you had for why this would be useful for
opencode.taqtiqa-mark commentedon Oct 25, 2025
Definitely wet paint all around. I suppose I have a view of
opencodethat is probably more likeopenagent. As you say the "coding-only" use case is probably limited. It'll be interesting to see ifopencodeis code-only use cases or if the view is that is one of several use cases.Melodeiro commentedon Nov 12, 2025
Would be great opportunity to have opencode server as an agent via the universal a2a prototol. With human-in-the-loop integration, etc. Have been searching for 3rd party implementations but seems like there are none yet
Also its good because you can create any architecture you want. Not just 1 to many
olafgeibig commentedon Nov 16, 2025
I absolutely support this feature request. IMO A2A will be the dominant protocol for the integration of agents across technology stacks they are build on. For example, the popular agent framework Agno has adopted it. This feature would allow calling Agno agents to do stuff and vice versa use opencode as an agent for code related tasks in multi-agent solutions built with Agno or any other framework that adopted A2A. As @Melodeiro said, it would enable us to use opencode as an agent in any agentic architecture you want. It's a huge game changer.
mdizo commentedon Dec 2, 2025
A2A is backed by the linux foundation so I'm more likely to believe its a protocol that isn't just a fad. I could think of a couple of coding uses cases for a multi-agent system like subagent parallelization and complex orchestration.
bjesuiter commentedon Jan 11, 2026
Since ACP is now part of A2A under the Linux foundation, we might be able to standardize on A2A.
https://github.com/orgs/i-am-bee/discussions/5
I don't know how the integration was/is done though, whether ACP as a Standard is kept or if it is deprecated now and fully disolves into A2A.
Knucklessg1 commentedon Jan 17, 2026
I have a ton of A2A agents, it would be super awesome if opencode could leverage the supplied agent skills from the A2A agent card to know how to use that agent. It would make opencode the ultimate developer agent orchestrator.
+1 vote for A2A on this framework. It's the first thing I looked up when discovering this project.
zxkxyz commentedon Jan 21, 2026
Chiming in to add my support for this or something similar. Similar to @taqtiqa-mark's POV, at our company we're beginning to see
opencodeas more of anopenagentand want to build our agents platform around it. Very intrigued by Dax's tweet about a company that's already doing this (with some reported friction, I wonder if this topic is related).The rationale being opencode is basically a general purpose computer-using agent, it's extremely powerful and easy to morph into whatever you want it to be (I don't need to convince anybody here of that) -- unlike going the framework route (Langchain, AI SDK, etc. which has its benefits, sure). Unsurprisingly, people are naturally gravitating towards opencode as their "framework" of choice, probably because it's the easiest way to build an agent that works similar to how those people work right now (with files, CLI tools, etc.) and it's extremely easy to iterate on because coding is not a requirement.
Teams within the company are already making opencode agents that are really good at operating within a specialized domain; e.g, we're building an opencode powered agent for answering questions about our data lake via a combination of tacit knowledge encoding (markdown files/skills informing the agent on how to think about and query the data) and various CLI + MCP tools to actually perform queries. Again, no code needed except for helper functions, which is why this route is so lucrative.
The thing is these agents are running on people's laptops and we want to productionize them (presumably using the opencode SDK). Figuring out auth, service accounts, interaction logic, etc. are problems we can work on internally but it seems like a major missing piece is the ability for opencode sessions to call upon remote agents as if they were local subagents.
This is where A2A or some similar "remote subagent" system could help us.
taqtiqa-mark commentedon Jan 22, 2026
I've been pushing in various issues for PocketFlow to be adopted, which would simplify implementation of lots of functionality - they have a A2A PoC in their cookbooks folder.
I'm starting to get strong not-invented-here vibes around this project... hopefully I'm wrong.
@zxkxyz, one issue I've been running into that is a concern in production settings, and fatal in regulated settings, is prompt injection attacks from the project: I turn off everything I can, and the LLM still gives me the OC spiel. I believe this would also break any non-trivial A2A use cases.
taqtiqa-mark commentedon Jan 22, 2026
You might find these projects of interest:
taqtiqa-mark commentedon Feb 6, 2026
In the spirit of calling out excellent engineering and design....
I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues:
maxhillaert commentedon Feb 22, 2026
I second this. I'm using opencode as a computer-using general purpose agent as well as a coding agent. It processes emails, documents , using my browser , etc. All I'm missing is orchestration between opencode instances beyond sub agents and A2A seems like the missing piece.
laiweihwa commentedon Mar 29, 2026
This exists now, BTW. I have not audited or tried it yet. It dropped this week: https://github.com/shashikanth-gs/a2a-opencode