Making this multi-player + creating the right representation to collaborate with agents is in my opinion the next bottlenecks. I wrote a small article about my thoughts there https://x.com/mmabrouk_/status/2010803911486292154
Agent orchestration seems to be the new hot problem to be solved in the ecosystem. See also Steve Yegge's most recent posts [1]. Curious to see what tools emerge as the winners of the Cambrian explosion we're probably about to see.
Totally. Yegge's post was fascinating and there was quite a bit of chatter about it internally at my company . I have this feeling that if I could just figure out how to effectively direct 10-20+ coding agents at once, I could supercharge my productivity and bug squashing skills. In some ways his post introducing a suite of new terminology helps to set the stage for this being a whole new world of being a SW engr.
There won't be a single orchestration winner, orchestration will just become ubiquitous in LoB systems. Slack and Github will probably be the biggest targets but it's pretty simple to create a chat bridge that supports adapters to support discord/telegram/etc and you can already do webhook orchestration easily enough.
This is what we are looking at at one of my clients. A2A clients (Slack, Google Meet, considering email) to A2A Orchestrator server (in-house, might be open-sourced) with specialized subagents for e.g. GitHub issue creation following a specific teams patterns and conventions, hooked up to company-wide MCP gateway with federated OIDC trust for passthrough auth (https://www.gatana.ai)
Works pretty well so far. Biggest issue i foresee for success is user UX for average employee, and actually useful use-cases.
It does not. I opted for the flow of returning to dashboard to give the user the control over which context they wanted to launch themselves into. I'm not against considering the feature, but in my own work trying to wrangle multiple agents, I haven't found the idle worker switch feature to be something I wanted personally
I'm always curious how folks do status detection. Here you use tmux capture-pane and detect off that! Whew! Simple & direct!
I've been really enjoying how OpenCode is so extensible, how you can make great plugins that can for example read the session.idle event & then go do whatever they want. That does require dropping in some config asking for the plugin, which takes some effort & requires a restart (but your session will be right there & you can continue). It's technically elegant imo, and nice that there is the extensibility.
But hard to beat using screen as a framebuffer & just reading it out, for doing absolutely whatever it is you could possibly want to do! For example you can also detect permissions prompts, which I don't believe there is an event for!
Haha I'm all about the KISS principle. I also set up a snapshot testing framework so that people can submit screenshots of any messed up status reports and I can easily add them to the test suite to make sure we fix any issues that someone sees.
So I built a thing that looks _very_ similar to this a while back: http://pipie.io/agent-tracker (it doesn't orchestrate)
And what's really fascinating isn't that multiple people have built the same thing is just how convergent all the ideas are. This makes a heap of sense given that they are all vibe-coded and using similar libraries. It's just very real when you see it right in front of your face like this.
I think there's a heap of really interesting stuff when you start linking into hooks which can also create tmux splits and really make the agent the center of an ide which seems like this is on the way to.
I am building this -> https://www.youtube.com/watch?v=R30qlYpcmK4 wich is basically the same direction. I feel the addition of a Layer that manages consoles is very helpful and a think i want to explore further. Greetings Josh
I'm setting up a small orchestration around zellij (I have almost no experience with tmux, so I went with the "modern" alternative), upterm and qrencode that allows me to 1) generate a claude code instance in a persistent session 2) make it controllable remotely via upterm 3) scan a qr code to copy the upterm server's ssh url on my phone so that I can paste it in termux.
I wonder if it would be more ergonomic to connect to the aoe window on my phone for when I have more then one claude code session to keep track of. I'm not against switching the zellij part to tmux.
Tbh that's exactly what I'm using aoe for: termius on my phone ssh into my Mac mini and then use aoe to check in on each agent session. Just make sure you check out the readme if you do this because at least for termius there's a quirk to make tmux and TUI happy. The recommended approach is to run aoe itself inside a tmux session which then will spawn additional tmux sessions as needed.
After your comment I tried to do something with my phone but tmux + claude code is definitely not great on mobile though the main view of aoe works decently.
Thanks for giving it a try! If you can think of any improvements I'm certainly all ears. What i've been doing is using the ios + termius + aoe setup to just keep tasks moving forwards. I log in from my phone, see which sessions are waiting for me, and then type just enough to keep them moving forwards until I get back to my desktop where then I can use aoe again to keep them moving
So this is a tmux wrapper? Does it provide any additional goodies other than a UI? From the readme it looks like you select a session and then you're back in tmux?
Once you are attached to an agent session, correct it's just tmux! aoe does:
- gives you one screen that shows you all of your agents and shows you which one s are waiting for you to attach to them and give them a new task or answer a question
- Easy git worktree integration to help you manage branches when running multiple agents in parallel on the same repo.
I also plan on adding a lightweight docker sandbox integration to help give you the option to sandbox a session when you run it (but that part isn't ready yet)
For the sake of convenience we found ourselves in a tedious terrible place again and now we have to scrape to get out of it
If only we could have a clean API to programmatically control agents...
The best UI is no UI
I am seeing a lot of development working around the shitty experience that is being stuck in a terribly slow cli program, nothing against this particular project
Personally I'm actually feeling like the CLI agent is a great experience once you get used to it, and managing them in aoe honestly does sort of feel like my worker management strategy when I was trying to maximize my productivity in age of empires 2
How do you handle session persistence across reboots / restarts for self-hosted models? Does ollama support persistence out of the box? I tried using codex-oss which does support persistence but codex injects 6K of system setup context which I thought was too much for self hosted models.
Good questions! All of that is handled inside of the coding agent (Claude Code / OpenCode). `aoe` is responsible for managing the agent sessions: It does keep those sessions persistent in tmux even if you close `aoe`, but if you restart your system, resuming a sessions would rely upon opencode/claude code storing the conversation history for each session, which I believe they do but would need to be manually restored for each agent.
The best (for me) of these that I’ve tried so far is conductor.build
They have a different UI orientation, and it’s more locked into Claude code, but it might be good inspiration for your future plans. They get the git worktree setup and teardown and managing dev servers part of it right IMO.
Conductor build looked cool. For me, I wanted something a little lighter weight that stays in the terminal. When I looked at conductor it seemed like it was a standalone app
Regarding feedback on whether sandboxing would be useful, yes, please! Including something like Docker sandboxes would make isolating the agent env’s much less of a hassle.
As an aside, I’m curious how others are handling this now… Mostly just creating dedicated user accounts?
Thank you for the feedback! My general feeling is that people are not doing sandboxing. Those that are, generally use devcontainers or some docker based solution
Hmm, this looks interesting. I've wanted to try something like this with an API provider that's free. I wonder how difficult to setup and how good OpenCode can be if used together with Ollama/llama.cpp and/or DeepSeek-Coder or Quen?
THIS!!! I'm right there with you. Imo, using aoe (or whatever tool you can find for session management) is the key unlock to help give us all the patience to try out the ollama/lmstudio/mlx providers to see how they really perform. We're lacking information about what work is really being done with local coding models, at least somewhat because imo most github open source repos don't ask you to share what LLM you used to help you, and they should.
We need to start sharing our specific success and failure stories from using local llms for coding
Ah thanks I should have clarified, I generally meant that's why I wrote it in rust. Tmux has nothing to do with security for sure.
It works on top of tmux to monitor the coding agent state all in one place so that you can see whether the agent is waiting for you. Today I also added git worktree support so that you can easily create and manage branches to run agents in parallel on the same codebase.
This is quite nice but limited in that it is single-player. In my opinion, the next generation of AI agents will be multi-player. Ramp's background agent is a good example https://builders.ramp.com/post/why-we-built-our-background-a...
Making this multi-player + creating the right representation to collaborate with agents is in my opinion the next bottlenecks. I wrote a small article about my thoughts there https://x.com/mmabrouk_/status/2010803911486292154
Agent orchestration seems to be the new hot problem to be solved in the ecosystem. See also Steve Yegge's most recent posts [1]. Curious to see what tools emerge as the winners of the Cambrian explosion we're probably about to see.
[1] https://steve-yegge.medium.com/the-future-of-coding-agents-e...
Totally. Yegge's post was fascinating and there was quite a bit of chatter about it internally at my company . I have this feeling that if I could just figure out how to effectively direct 10-20+ coding agents at once, I could supercharge my productivity and bug squashing skills. In some ways his post introducing a suite of new terminology helps to set the stage for this being a whole new world of being a SW engr.
There won't be a single orchestration winner, orchestration will just become ubiquitous in LoB systems. Slack and Github will probably be the biggest targets but it's pretty simple to create a chat bridge that supports adapters to support discord/telegram/etc and you can already do webhook orchestration easily enough.
This is what we are looking at at one of my clients. A2A clients (Slack, Google Meet, considering email) to A2A Orchestrator server (in-house, might be open-sourced) with specialized subagents for e.g. GitHub issue creation following a specific teams patterns and conventions, hooked up to company-wide MCP gateway with federated OIDC trust for passthrough auth (https://www.gatana.ai)
Works pretty well so far. Biggest issue i foresee for success is user UX for average employee, and actually useful use-cases.
Does it have a . Hotkey for automatically switching to the next idle worker, like the namesake did?
I'm also seriously considering the ability to produce aoeii sound effects like "nuh nuh nuh"
1
it must be done
It has been scheduled https://github.com/njbrake/agent-of-empires/issues/23
It does not. I opted for the flow of returning to dashboard to give the user the control over which context they wanted to launch themselves into. I'm not against considering the feature, but in my own work trying to wrangle multiple agents, I haven't found the idle worker switch feature to be something I wanted personally
I built 3 MVPs on a neutral island
I'm always curious how folks do status detection. Here you use tmux capture-pane and detect off that! Whew! Simple & direct!
I've been really enjoying how OpenCode is so extensible, how you can make great plugins that can for example read the session.idle event & then go do whatever they want. That does require dropping in some config asking for the plugin, which takes some effort & requires a restart (but your session will be right there & you can continue). It's technically elegant imo, and nice that there is the extensibility.
But hard to beat using screen as a framebuffer & just reading it out, for doing absolutely whatever it is you could possibly want to do! For example you can also detect permissions prompts, which I don't believe there is an event for!
There is a PermissionRequest hook [1], along with Notification
https://code.claude.com/docs/en/hooks-guide#hook-events-over...
It must be newer because Opus never seems to know about it, and the claude-code-guide tool that fires occasionally misses it
Haha I'm all about the KISS principle. I also set up a snapshot testing framework so that people can submit screenshots of any messed up status reports and I can easily add them to the test suite to make sure we fix any issues that someone sees.
I'd love a cli subcommands that would just give me status, btw. Very neat to have.
I need to add some better docs but the CLI of aoe supports it already!
So I built a thing that looks _very_ similar to this a while back: http://pipie.io/agent-tracker (it doesn't orchestrate)
And what's really fascinating isn't that multiple people have built the same thing is just how convergent all the ideas are. This makes a heap of sense given that they are all vibe-coded and using similar libraries. It's just very real when you see it right in front of your face like this.
I think there's a heap of really interesting stuff when you start linking into hooks which can also create tmux splits and really make the agent the center of an ide which seems like this is on the way to.
I am building this -> https://www.youtube.com/watch?v=R30qlYpcmK4 wich is basically the same direction. I feel the addition of a Layer that manages consoles is very helpful and a think i want to explore further. Greetings Josh
I'm setting up a small orchestration around zellij (I have almost no experience with tmux, so I went with the "modern" alternative), upterm and qrencode that allows me to 1) generate a claude code instance in a persistent session 2) make it controllable remotely via upterm 3) scan a qr code to copy the upterm server's ssh url on my phone so that I can paste it in termux.
I wonder if it would be more ergonomic to connect to the aoe window on my phone for when I have more then one claude code session to keep track of. I'm not against switching the zellij part to tmux.
Tbh that's exactly what I'm using aoe for: termius on my phone ssh into my Mac mini and then use aoe to check in on each agent session. Just make sure you check out the readme if you do this because at least for termius there's a quirk to make tmux and TUI happy. The recommended approach is to run aoe itself inside a tmux session which then will spawn additional tmux sessions as needed.
After your comment I tried to do something with my phone but tmux + claude code is definitely not great on mobile though the main view of aoe works decently.
Thanks for giving it a try! If you can think of any improvements I'm certainly all ears. What i've been doing is using the ios + termius + aoe setup to just keep tasks moving forwards. I log in from my phone, see which sessions are waiting for me, and then type just enough to keep them moving forwards until I get back to my desktop where then I can use aoe again to keep them moving
So this is a tmux wrapper? Does it provide any additional goodies other than a UI? From the readme it looks like you select a session and then you're back in tmux?
Once you are attached to an agent session, correct it's just tmux! aoe does: - gives you one screen that shows you all of your agents and shows you which one s are waiting for you to attach to them and give them a new task or answer a question
- Easy git worktree integration to help you manage branches when running multiple agents in parallel on the same repo.
I also plan on adding a lightweight docker sandbox integration to help give you the option to sandbox a session when you run it (but that part isn't ready yet)
WARNING! I tried this and it corrupted my entire tmux session, leaving me to have to recreate the entire thing....
Steps to reproduce the bug that broke my tmux:
1. `aoe add .`
2. `aoe`
3. Attach to the session that was added
4. Close that pane with `<Prefix> x` then `y`
5. Tmux closes down
6. Attempt to reattach to any session within tmux: `open terminal failed: not a terminal`
7. `tmux kill-server` is the only viable option, losing all my sessions
Found the bug! I was using three handles to point to the same file descriptor. Fixed in https://github.com/njbrake/agent-of-empires/pull/27, i'll get a patch version out ASAP
Thank you for the bug report! I created https://github.com/njbrake/agent-of-empires/issues/26
Would you be able to share any additional information about what terminal you are using? I saw issues when using inside of termius.
I have https://github.com/njbrake/agent-of-empires?tab=readme-ov-fi... to try to explain how to use it inside of ios termius, if that helps.
Cheers! This happened in ghostty. Also posted a comment on GH.
Bug is patched in version 0.2.2, run `brew update && brew upgrade aoe` to grab the update
For the sake of convenience we found ourselves in a tedious terrible place again and now we have to scrape to get out of it
If only we could have a clean API to programmatically control agents... The best UI is no UI
I am seeing a lot of development working around the shitty experience that is being stuck in a terribly slow cli program, nothing against this particular project
Personally I'm actually feeling like the CLI agent is a great experience once you get used to it, and managing them in aoe honestly does sort of feel like my worker management strategy when I was trying to maximize my productivity in age of empires 2
How do you handle session persistence across reboots / restarts for self-hosted models? Does ollama support persistence out of the box? I tried using codex-oss which does support persistence but codex injects 6K of system setup context which I thought was too much for self hosted models.
Good questions! All of that is handled inside of the coding agent (Claude Code / OpenCode). `aoe` is responsible for managing the agent sessions: It does keep those sessions persistent in tmux even if you close `aoe`, but if you restart your system, resuming a sessions would rely upon opencode/claude code storing the conversation history for each session, which I believe they do but would need to be manually restored for each agent.
This looks cool, I’ll definitely try it out.
The best (for me) of these that I’ve tried so far is conductor.build
They have a different UI orientation, and it’s more locked into Claude code, but it might be good inspiration for your future plans. They get the git worktree setup and teardown and managing dev servers part of it right IMO.
Conductor build looked cool. For me, I wanted something a little lighter weight that stays in the terminal. When I looked at conductor it seemed like it was a standalone app
Have you tried Coder (coder.com)?
I haven't. Looks cool though!
Thank you for sharing this.
Regarding feedback on whether sandboxing would be useful, yes, please! Including something like Docker sandboxes would make isolating the agent env’s much less of a hassle.
As an aside, I’m curious how others are handling this now… Mostly just creating dedicated user accounts?
Thank you for the feedback! My general feeling is that people are not doing sandboxing. Those that are, generally use devcontainers or some docker based solution
Hmm, this looks interesting. I've wanted to try something like this with an API provider that's free. I wonder how difficult to setup and how good OpenCode can be if used together with Ollama/llama.cpp and/or DeepSeek-Coder or Quen?
THIS!!! I'm right there with you. Imo, using aoe (or whatever tool you can find for session management) is the key unlock to help give us all the patience to try out the ollama/lmstudio/mlx providers to see how they really perform. We're lacking information about what work is really being done with local coding models, at least somewhat because imo most github open source repos don't ask you to share what LLM you used to help you, and they should.
We need to start sharing our specific success and failure stories from using local llms for coding
how is this different than using tmux? i don't understand what it does
>relies on tmux for security how is it more secure than not using it?
Ah thanks I should have clarified, I generally meant that's why I wrote it in rust. Tmux has nothing to do with security for sure.
It works on top of tmux to monitor the coding agent state all in one place so that you can see whether the agent is waiting for you. Today I also added git worktree support so that you can easily create and manage branches to run agents in parallel on the same codebase.