[myleshenderson]

Given the infancy of all of these tools, it makes sense to experiment. So trying out everything that is not gas town is reasonable.

I haven't yet tried gas town (or any of the mentioned tools) as I don't need so many agents that I need something like that plus the cost concerns. I've been rolling my own very light orchestrator (mostly just worktrees/branches/instructions) and relying on claude itself to manage the sub agents as necessary.

I was a bit surprised by the "ripping out beads" sentence from all of the article, as beads does seem to serve a purpose independent of the orchestration tools. Giving agents a ticketing system independent of what us humans use makes a lot of sense to me.

I've experimented with using Jira/Linear to handle the "current work todos" and using beads just seems so much better. No mcps and remote api calls is pretty great.

I'll be curious to see how the other orchestration tools are handling this, because it seems like they will have to handle it.

[markferree]

Replaced beads with a skill reminding Claude it could use gh cli to manage GitHub issues and never really looked back. I had already noticed on smaller projects that a markdown punch list plus the built in todo tool was usually more than enough and between those two didn’t feel the need for beads anymore.

[myleshenderson]

I appreciate the follow up. I'm using Jira as the primary work tracker for my day job, so I'm hesitant to interact with that any more than is necessary. Though we do have a skill for Jira primarily for humans to tell the LLM "hey create a ticket...".

I'll play with that a bit to see what happens.