Comment by brushfoot
1 month ago
I'm not trolling. I'm just not aware of major differences between them.
When I make a change with a Copilot Agent, it checks for issues, builds my project, runs tests, and iterates until things work. Multiple agents can do that in parallel.
My impression was that this does more or less the same thing.
That said, I'm definitely open to learning more about them both.
What are the advantages of this in your experience?
It is worth an install; it works very differently than an agent in a single loop.
Beads formalizes building a DAG for a given workload. This has a bunch of implications, but one is that you can specify larger workloads and the agents won’t get stuck or confused. At some level gas town is a bunch of scaffolding around the benefits of beads; an orchestrator that is native to dealing with beads opens up many more benefits than one that isn’t custom coded for it.
Think of a human needing to be interacted with as a ‘fault’ in an agentic coding system — a copilot agent might be at 0.5 9s or so - 50% of tasks can complete without intervention, given a certain set of tasks. All the gas town scaffolding is trying to increase the number of 9s, and the size of the task that can be given.
My take - Gas town (as an architecture) certainly has more nines in it than a single agent; the rest is just a lot of fun experimentation.
> Beads formalizes building a DAG for a given workload
> gas town is [...] an orchestrator that is native to dealing with beads
Thanks - this is very helpful in deciding when and where to use them. Steve's descriptions sounded to me like more RAM and Copilot Agents:
> [Beads:] A memory upgrade for your coding agent
> [Gas Town:] a new take on the IDE for 2026. Gas Town helps you with the tedium of running lots of Claude Code instances
Yes he is on an extended manic episode right now - we can only sit back and enjoy the fruits of his extreme labor. I expect the dust will settle at some point, and I think he’s right that he’s on to some quality architecture.