Orchestrating Coding Agents in 2026
I am gratified to see some of my musings on the direction of coding agents are proving accurate. In September of last year I speculated that, given the non-deterministic and faulty nature of LLMs, folks might be served by adopting fault-tolerant architectures to orchestrate coding agents:
From everything I've seen, we're not yet in a situation where it's either practical or economical to execute multiple coding agents in parallel or orchestrated. However I think in a couple years the technology will be cheap enough that we'll start needing to think about how to orchestrate groups of agents, and the idea of leaning on Erlang's learnings intrigues me. Constructing the agents and their execution frameworks as individual actors for concurrent execution, while arraying some as supervisors and others as workers, seems rich for investigation.
Four months later, people are already attempting to orchestrate multiple agents together, regardless of the cost. Steve Yegge has written a few articles about a system called Gas Town, exploring an approach to multi-agent orchestration.
If we take Steve's word for it that Gas Town is fully functional, it turns out that at current LLM performance you need multiple levels of supervisors to keep the system going. There's a Witness agent that pokes at the basic worker agents as well as the merge-queue agent when they get stuck and aren't making progress. Additionally, there's a Deacon agent that propagates a heartbeat throughout the various agent roles, waking them up to recheck whether they have work to do. To achieve this, Steve's spending roughly $600 a month.
Gas Town is also expensive as hell. You won’t like Gas Town if you ever have to think, even for a moment, about where money comes from. I had to get my second Claude Code account, finally; they don’t let you siphon unlimited dollars from a single account, so you need multiple emails and siphons, it’s all very silly. My calculations show that now that Gas Town has finally achieved liftoff, I will need a third Claude Code account by the end of next week. It is a cash guzzler.
Aside from Gas Town, we're starting to hear about other orchestration systems. Cursor put out a controversial article, Scaling long-running autonomous coding, where they claim to have built a functioning web browser, as well as migrated their website infrastructure from Solid to React. I find their results on locking fascinating — that locking and optimistic concurrency control over shared state produced poor outcomes. I haven't had a chance to watch this interview with one of the involved engineers, but I am looking forward to any other findings that shake out.
Two Things
1. Gas Town is Inevitable
I agree with Steve Klabnick that Gas Town is inevitable. Given how quickly these systems produce usable code, and the general problem-solving ability of today's state-of-the-art LLMs, people will want to run many agents in parallel to solve problems. Running them in parallel, but working on shared problems, will require orchestration of some kind.
2. State is Important
Theoretically, state matters: coding agents working on shared problems need to coordinate their efforts. But we also have early results suggesting state matters in practice — Gas Town leans heavily on Beads (the inspiration for Knowledge Bases) to delineate discrete tasks and facilitate communication between agents, as well as on Git's commit history as a centralized state-of-the-project. We also have the Cursor team's result that locking shared state leads to brittleness and low throughput, with agents failing to unlock and the system bottlenecking behind locks.
I expect that breaking agents up into some kind of hierarchy with specific jobs, and bulletproofing the inter-agent communication system, will be an important way these systems distinguish themselves and produce good results.