Beads tables (Steve Yegge's) for issue tracking. Can view git trees, terminals, issue tables, notes, and files all on one screen. Can connect multiple machines via private network (like tailscale)
Comments
2001zhaozhao•1h ago
I'm building an agent wrapper with an in-browser windowing user interface, and this is surprisingly close to what I have in mind from a UX perspective.
Similarities:
- Lots of UX focus with the details like keyboard shortcuts. Other gui projects straight-up forget this, and the CLI agents include it only out of necessity. I think this is the way to go because no matter how much can be automated in today's world, having the lowest-friction UX is still king in making the parts that need to be manual go as fast as possible.
- The idea of a windowing system in the browser. I think we both think that agentic development is complex enough to warrant a multi-window environment being optimal.
- Focus on being accessible from any device, although i don't have the persistent layout thing quite as developed as your approach.
- Our monetization approach is similar (monetize hosted version). you're monetizing through hosting the remote while i want to monetize through hosting 24/7 dev machines
Differences:
- My windowing approach is a bit more safe (just focused on making a really good remote desktop) while you seem to have a more adventurous idea with the 2D zoomable canvas
- I think your choice of Beads issue tracking is really interesting for context management. I don't have an equivalent in my project.
- You're running agents on a dev's laptop and enabling remote access through a relay layer, whereas i'm designing my tool's backend to run directly on 24/7 dev servers.
- You're using cli agents directly (like cmux) while i'm wrapping them in a GUI with ACP (like Zed)
- You have monaco editor built in while I'm planning to integrate code-server
- From your canvas approach i'm assuming you're rendering client side. I'm focused on server-rendered web HTML (liveview-like), mostly chosen for reasons for supporting a plugin system where plugins are server-side-only but can alter the UI. my approach probably sends more data through the wire but drains less battery than yours
Overall a bit of nice validation and food for thought. I think we have really different backend approaches but the UX portion converges nonetheless. Thanks for sharing!
By the way, in the GitHub repo description, your 49agents website still says coming soon, you should probably update that.
Also, the Discord invite on your website doesn't work
2001zhaozhao•1h ago
Similarities:
- Lots of UX focus with the details like keyboard shortcuts. Other gui projects straight-up forget this, and the CLI agents include it only out of necessity. I think this is the way to go because no matter how much can be automated in today's world, having the lowest-friction UX is still king in making the parts that need to be manual go as fast as possible.
- The idea of a windowing system in the browser. I think we both think that agentic development is complex enough to warrant a multi-window environment being optimal.
- Focus on being accessible from any device, although i don't have the persistent layout thing quite as developed as your approach.
- Our monetization approach is similar (monetize hosted version). you're monetizing through hosting the remote while i want to monetize through hosting 24/7 dev machines
Differences:
- My windowing approach is a bit more safe (just focused on making a really good remote desktop) while you seem to have a more adventurous idea with the 2D zoomable canvas
- I think your choice of Beads issue tracking is really interesting for context management. I don't have an equivalent in my project.
- You're running agents on a dev's laptop and enabling remote access through a relay layer, whereas i'm designing my tool's backend to run directly on 24/7 dev servers.
- You're using cli agents directly (like cmux) while i'm wrapping them in a GUI with ACP (like Zed)
- You have monaco editor built in while I'm planning to integrate code-server
- From your canvas approach i'm assuming you're rendering client side. I'm focused on server-rendered web HTML (liveview-like), mostly chosen for reasons for supporting a plugin system where plugins are server-side-only but can alter the UI. my approach probably sends more data through the wire but drains less battery than yours
Overall a bit of nice validation and food for thought. I think we have really different backend approaches but the UX portion converges nonetheless. Thanks for sharing!
By the way, in the GitHub repo description, your 49agents website still says coming soon, you should probably update that.
Also, the Discord invite on your website doesn't work