3 ms·

I was there for the month or so when I could still talk to my sub-agent directly in opencode. Yes: the subagent couldn't talk to the parent anymore after a fir

I was there for the month or so when I could still talk to my sub-agent directly in opencode. Yes: the subagent couldn't talk to the parent anymore after a first return to it, but that didn't matter. That I could beget new useful interact able agents was amazing. I'm mad and bitter angry and won't ever stop being mad until opencode or I fix it so that opencode really has multiple agents that can work with each other, and that I can work with. I started doing some work on message passing mailbox systems, alike many of the other great https://github.com/joelhooks/swarm-tools https://github.com/joelhooks/swarm-tools or https://github.com/Dicklesworthstone/mcp_agent_mail_rust https://github.com/Dicklesworthstone/mcp_agent_mail_rust efforts , but super trailed off. I have high interest in scion too! I love the robust platform underneath. Yes please. I've spent a lot of time digging into the opencode data model underneath, & it's a moving inplementation defined system. Making the pieces of the system concrete like Scion has feels like a superpower.

verdverm 4mo ago
I like Scions "merging of three pieces" (harness/env, agent provider (LLM and related config), agent def (like agents in claude/opencode)) Scion OC support is not good on main, I have a (outdated) fork which vastly improves it. There are a number of OC plugins that try to add higher level orchestration as well as independent wrappers like https://kubeopencode.github.io/kubeopencode/docs/features/ https://kubeopencode.github.io/kubeopencode/docs/features/ It's debatable if you need multiple harness support like Scion or something more focussed like KubeOpenCode Checked out swarm tools for a few seconds until the main pages of the docs 404'd, not a good sign when the first three menu items do that... One cool thing about Scion, you can attach directly to the agents in the terminal or the web ui, even seeing real-time typing appear across them if you have both open (thanks tmux!). Scion also handles all the messiness of setting up a container with auth, git worktree, and tmux. I tried to get a simple version going but it became a rabbit hole of complexity and edge cases. You can run it in "workstation" mode which is all local.
- yaskou 4mo ago
  Cool, I only found Scion recently, so I may be missing a lot. The sandboxing part looks nice to me, and I like that there is some message-bus-ish thing between agents. One thing I keep getting stuck on with these systems though: they all seem to assume an agent lives in one worktree of one git repo. Maybe that is fine in a monorepo world. Outside of that, the repo boundary is often just not the task boundary. Some context lives next door, or two repos away, and the sandbox somehow has to know what to bring in. I'm wondering if there is a tool in the agent orchestration space that prepares multi-repository worktrees for a subagent out of the box?
  - jauntywundrkind 4mo ago
    Funny you should mention that. Don't hold your breath but I have been doodling with some stuff here. There's some share .scion space that allegedly your orchestrator / team is I think supposed to be able to share with other tasks, I think... Not sure. No idea how it works. But that's at least some cross worker scratch space... Again allegedly.
    - verdverm 4mo ago
      I think you should be able to 1. create a shared volume 2. populate that by attaching and running commands/scripts. It should outlive any agent, but not the project. You might be able to ask an agent, use a skill, or have it done on demand. I think there are hooks coming that we can tie into. Open an issue on GH, ptone is good about replying, just not timely all the time.

verdverm 4mo ago

I like Scions "merging of three pieces" (harness/env, agent provider (LLM and related config), agent def (like agents in claude/opencode)) Scion OC support is not good on main, I have a (outdated) fork which vastly improves it. There are a number of OC plugins that try to add higher level orchestration as well as independent wrappers like https://kubeopencode.github.io/kubeopencode/docs/features/ https://kubeopencode.github.io/kubeopencode/docs/features/ It's debatable if you need multiple harness support like Scion or something more focussed like KubeOpenCode Checked out swarm tools for a few seconds until the main pages of the docs 404'd, not a good sign when the first three menu items do that... One cool thing about Scion, you can attach directly to the agents in the terminal or the web ui, even seeing real-time typing appear across them if you have both open (thanks tmux!). Scion also handles all the messiness of setting up a container with auth, git worktree, and tmux. I tried to get a simple version going but it became a rabbit hole of complexity and edge cases. You can run it in "workstation" mode which is all local.

yaskou 4mo ago
Cool, I only found Scion recently, so I may be missing a lot. The sandboxing part looks nice to me, and I like that there is some message-bus-ish thing between agents. One thing I keep getting stuck on with these systems though: they all seem to assume an agent lives in one worktree of one git repo. Maybe that is fine in a monorepo world. Outside of that, the repo boundary is often just not the task boundary. Some context lives next door, or two repos away, and the sandbox somehow has to know what to bring in. I'm wondering if there is a tool in the agent orchestration space that prepares multi-repository worktrees for a subagent out of the box?
- jauntywundrkind 4mo ago
  Funny you should mention that. Don't hold your breath but I have been doodling with some stuff here. There's some share .scion space that allegedly your orchestrator / team is I think supposed to be able to share with other tasks, I think... Not sure. No idea how it works. But that's at least some cross worker scratch space... Again allegedly.
  - verdverm 4mo ago
    I think you should be able to 1. create a shared volume 2. populate that by attaching and running commands/scripts. It should outlive any agent, but not the project. You might be able to ask an agent, use a skill, or have it done on demand. I think there are hooks coming that we can tie into. Open an issue on GH, ptone is good about replying, just not timely all the time.