Did you build this out of pure interest in what's available or to be able to chime on threads like these on Reddit and HN when someone builds the same thing once again?
Here are the things I would love to see:
- supported tooling (e.g. built in browser)
- interaction type ( chat ui, terminal, booth)
- context size added (how large is the additional context so that the agent knows the ADE)
- extensibility (plugins possible)
- completely free, paid possible
- range of harness support (some only support claude and codex)
- installation type (own server + n clients, only clients and properitary server)
- connectivity support of multiple machines (tailscale, SSH, wireguard, proprietary)
- age of project, commit count, PR count
- multiselect of possible platforms (e.g. windows + android)
I guess that's all that is broadly comparable without going into too much detail.
Yeah, to be honest I'm looking for ways to make the list more useful, but it's not that easy.
I'd love a way to track "popularity", but only 64% of the tools are on Github, so we can track their star counts, and less than half are installed via Homebrew or npm, which could let us track their install numbers.
Another option would be to let users say which tool(s) they use and calculate popularity based on that, but probably some tool authors would tell their community to go and vote for them and the result would be a ranking by which community is most engaged...
we are focusing on human attention - managing multiple agents leads to approval fatigue and human-in-the-loop design goes for a toss. We are making sure that agentic engineers are focused on building the right product without worrying about assembling tools to build the right product.
On a lighter note - our biggest differentiator(which my CTO won't agree with) is that we have an in-built radio in the product that the user can listen to while agents are running.
That's great, but from my experience, 90% of Rubyists I met are working with Rails.
"Divorcing" from Rails is therefore absurd, just stuff people say who don't like DHH for one reason or another.
We work with Rails but there is more to programming (and Ruby) than work. Sinatra micro services were a thing for a while. Hanami is decent. But the reason we use Rails is pretty simple…it’s great, easy to onboard developers, it’s battle tested, well maintained and has a massive ecosystem.
I don’t even care that DHH is a Nazi because you know what I can use it for non-Nazi stuff and there’s nothing he can do about it. I get his labour for free. He’s like my little Nazi monkey slave.
my take I use ruby a lot too - DHH might be disagreeable - but the one thing is one bright light i.e Rails ends up dimming the others. so when it cracks - like it did - people go to the next room, even though the current room has enough light.
Hmm, I don’t think sharing my personal experience would be that useful. For one, I’ve only used a handful of these tools long enough to give a meaningful assessment. More importantly, though, these tools evolve so quickly that anything I wrote would likely be outdated almost immediately.
I'd rather give folks an overview over which tools exist and some info about their popularity, price point etc.
Maybe it would be cool to add links to the founder's accounts on X, Youtube etc. where they share new releases and what they're working on...
> Good list, but gosh the term "agent orchestrator" is really being diluted endlessly these days.
Yeah, there's a lot happening in this space... but I think those 13 tools which are one the list right now all try to do the same thing - make it easier to run multiple agents (mostly over multiple apps) at the same time.
Are there any tools you would add or remove?
> Also, putting Zed and Cursor in the same "freemium" bucket is really unfair...
Sure, the "free" plans of some of the tools are not really comparable, but I think that's out of scope for this list. :)
Hearing people still mention "monkey patching" always makes me chuckle...
I haven't "monkey patched" anything in Ruby in > 5 years, and I don't see it in any of the popular libraries/gems anymore either.
You can pin a gem to a specific version, of course.
`gem "mygem"` installs the latest version.
`gem "mygem", "~> 4.0.0"` installs >= 4.0.0 but < 4.1.0, which is what you probably want when using Semantic Versioning, which most gems adhere to, to get the latest patch version.
`gem "mygem", "4.0.10"` installs exactly that version.
reply