1.12 Multi-agent coding systems — The Orchestrator's Toolkit

Persistent runtimes are not the only place orchestration has become visible. A separate category has grown up around software development specifically: systems that coordinate several coding agents across repositories, branches, tasks, and review steps.

Steve Yegge’s Gas Town is an early, instructive example, and it is worth describing in its own vocabulary because the vocabulary is part of the contribution. Gas Town is a workspace manager for multiple coding agents whose architecture includes a Mayor that coordinates work, Rigs that contain projects, Polecats that perform assigned tasks, Witnesses and a Deacon that monitor agents, a Refinery that processes merges, and Beads that preserve structured work state, with Git worktrees and hooks giving the work somewhere to persist when an agent stops, restarts, or gets replaced.⁶⁸

Credit where it is due, and credit to the right people. Gas Town did not invent multi-agent coding: research systems and frameworks such as MetaGPT, ChatDev, AutoGen, and CAMEL had already demonstrated role-based collaboration among language-model agents.⁶⁹ What Yegge — who also wrote the book on vibe coding with Gene Kim — made tangible was a persistent, operator-facing design: named workers, durable tasks, queues, recovery, and a working environment an individual could install.

Gas Town is focused on development: work whose output is code in a repository and whose measure is throughput. That is an important use case, and an expensive one when many workers run at once. Yegge himself has called it “expensive as hell.” One early user reported a sixty-minute session costing roughly $100 in model tokens. That is an anecdote, without the agent count, duty cycle, or model mix needed to turn it into a rate. It does establish a useful operating question: how much productive work did the fleet buy for that spend? Chapter 15 makes that question part of the contract.

What Gas Town really did was make the coordination problem impossible to ignore. Running one coding agent is mostly a task-and-response interaction, while running twenty creates an entirely different class of problem: who owns each task, where state is stored, how stuck workers get detected, how branches stay isolated, how work is merged, and how a person knows what is happening without opening twenty terminals. Yegge named those problems and built a concrete architecture around them. Its operational history also shows how much that architecture depended on the behavior of the models inside it.

Gas City takes the more general approach. Its repository describes it as an orchestration-builder SDK that extracts the reusable infrastructure out of Gas Town into a configurable toolkit, providing declarative configuration, multiple runtime providers, work routing, formulas, orders, health supervision, packs, and project-scoped orchestration. Gas Town is an opinionated city; Gas City is a kit for building different ones.

The two projects have different trajectories. In April 2026, Yegge described Gas Town as largely in maintenance mode and directed new development toward Gas City. In August, he reported that Gas Town had failed for his own work after a model change, and that he had moved to Wheelhouse, a private harness for his game Wyvern. He also said he had given up building reusable harnesses. That is his account of his deployment and his change of direction; it does not establish that every Gas Town installation failed.⁷⁰

Gas City has continued separately: its community repository released version 1.5.0 on October 5, 2026. That is evidence of ongoing development, not evidence that it will operate reliably in your environment. Gas Town remains useful here as an architectural case and a failure lesson; Gas City is a continuing project to evaluate on its own record.⁷¹

Other systems make other choices. The comparisons below name each coordination model, its contribution, and the responsibility it leaves with the operator.

Gas Town — hierarchical workspace. Named workers, monitoring, persistent tasks, and merge processing make a coding fleet inspectable. The design supplies neither a general theory of orchestration nor a replacement for human review.

Gas City — configurable orchestration SDK. Runtime providers, routing, supervision, packs, and declarative configuration supply parts from which to build a system. The operator still has to design the workflow for the organization.

OpenAI Symphony — issue tracker as control plane. Tasks map to isolated agent workspaces, with state monitoring, stalled-worker recovery, and repository-owned instructions. OpenAI describes it as a minimal reference implementation, which limits what you should infer from the example.⁷²

Claude Code Agent Teams — lead and independent teammates. Shared tasks, direct messaging, plan approval, and lifecycle hooks support collaboration. The documentation calls the feature experimental; it is not a durable production scheduler.⁷³

OpenHands Agent Canvas and SDK — control center and programmable server. Multiple agent backends, scheduled or event-triggered work, tools, MCP, and sandboxes support different arrangements. The system does not prescribe a fixed hierarchy of worker roles.⁷⁴

SWE-agent and mini-SWE-agent — individual coding worker. A model uses tools to investigate and modify a repository issue. These workers need a separate coordinator if you want to run a fleet.⁷⁵

VS Code Agent Sessions — shared session interface. Local, background, cloud, and subagent work can be viewed together, with parallel subagents and handoffs. That visibility still leaves the organizational operating model to be designed.⁷⁶

GitHub Agentic Workflows — repository automation in Actions. Scheduled or event-triggered agents can triage issues, investigate failures, and propose changes through constrained outputs. The October 5 update adds work queues, ledgers, and tighter output controls. The workflow still needs an explicit objective, permissions, and a review path.⁷⁷

CrewAI — role-based crews. Agent roles, tasks, and tools support prototyping; Flows add persisted state and human feedback. Cross-system identity and records require further design.⁷⁸

LangGraph — stateful workflow graph. Durable execution, checkpoints, approval gates, and recovery support long-running work. Identity and policy need configuration and integration; the graph does not supply the organization’s authority model.⁷⁹

CrewAI and LangGraph are general-purpose frameworks rather than coding fleets. An orchestrator may use either to build the system. The distinction is between infrastructure that coordinates execution and the responsibility for deciding what the execution should accomplish.

A graph can preserve a decision and pause for approval. It cannot decide on its own whether the organization’s approval rules are the right ones. That work still belongs to the orchestrator: designing the objective, configuring agents and identities, defining boundaries, evaluating evidence, and deciding how the system should continue or stop.

The multi-agent space is much larger than coding-agent factories. Its tools already cover substantial parts of coordination, policy, isolation, and recovery; joining those parts into an operating system remains the practical work.

Buying a platform changes how much assembly you must do. It does not settle who owns the result, what authority each worker receives, or which evidence your organization needs. Those decisions belong in configuration, permissions, and records that the running system can enforce and produce, rather than only in a document beside it.

Starting next week. You can use these tools to orchestrate a bounded piece of work now: one repository, a clear objective, isolated workers, a budget, and a review path. Start there. Running a whole business function across several systems takes more design and operational investment, because you must join identities, state, policy, and recovery across the boundaries. A quickstart can launch workers. The questions below tell you whether you have built something you can operate.

A new framework seems to arrive every week, partly because people are using agentic frameworks to build more agentic frameworks — the tooling is now generating itself, and the easy ones are within reach of a hobbyist with a free weekend. Keeping up is not the job. Knowing what questions to ask of the twelfth new framework is the job.

Ask these questions of any system you are evaluating — or answer them, when the system is yours to build:

Which system owns the work queue?
Where does state survive an agent restart?
How are workers isolated from one another?
What happens when a worker stalls?
Who reviews and merges the result?
Which actions are automatic, and which require approval?
Can another person reconstruct the work without the original operator?

Answer those and a collection of coding agents becomes an operating system for development. Leave them unanswered and opening more agent sessions is not orchestration, whatever the dashboard says. Orchestration begins at the point where the work, the state, the permissions, the recovery, and the review path have been designed as one system.

The broader framework landscape is both exploding and consolidating at the same time: each platform now has a production framework (Microsoft merged AutoGen and Semantic Kernel into Microsoft Agent Framework, Google shipped version 2.0 of its Agent Development Kit, and AWS’s own teams build agents on its Strands Agents SDK), while the lightweight end keeps producing new entrants, each with a plausible claim to a niche and none dominant outside it — and every new one makes the questions in this chapter more important, not less.⁸⁰

One more category belongs in this chapter for the sake of equal time: the closed, full-stack proprietary options. Anthropic’s and OpenAI’s are two examples, and neither is merely a framework — they supply complete environments.⁸¹ A closed stack of this kind is a legitimate choice, especially where the convenience of a single vendor’s polished defaults outweighs the need to inspect components: you trade exit options and full inspectability for day-one reliability, integrated billing, and one throat to choke. What an orchestrator should not do is mistake either stack for the whole market, or assume that “we bought the enterprise plan” resolves any of the questions in this chapter — it does not; the vendor’s plan governs the vendor’s agents’ relationship with you, not your delegated systems’ relationship with your organization’s authority.

One more set of arrivals dates from late September 2026, and it changes what “full-stack proprietary” now covers. OpenAI’s DevDay on September 29 shipped twenty-five announcements in one morning, the consequential one being Dots — always-on agents that hold ongoing responsibilities, with state, schedule, and standing, rather than answering one prompt at a time; the same event added computer use to the Agents API and put a near-frontier coding model, GPT-6.1 Sol, on the price list at one-fifth of OpenAI’s Astra token prices.⁸² AWS followed the same day with Bedrock Managed Agents powered by OpenAI in public preview: OpenAI’s Agents API re-engineered to be AWS-native, each agent its own IAM role, durable sessions persisting messages and tool calls, and the data staying inside the customer’s VPC. Neither announcement changes the questions in this chapter — Dots is still a vendor governing its own agents’ relationship with you, and a managed agent in your VPC is still a machine you did not design asking for authority — but together they mark the moment the proprietary stacks stopped being frameworks and became places to run agents, priced and procured like the rest of the enterprise estate.

Business-application vendors are making the same move, with different starting points. Three September developments show why a coding-only survey misses part of the landscape:

Microsoft Copilot Autopilot — a persistent agent in the tenant. Microsoft’s September 25 announcement describes an agent with its own identity, memory, computer, and workspace, doing recurring work across Microsoft 365. Autopilot was expanding to private preview at month-end; the announcement does not establish general availability.⁸³

Salesforce Agentforce — longer-running business work. Its September 14 announcement describes a long-horizon runtime, with Hunter as the first agent using it, and lists multi-agent orchestration as generally available. Other capabilities have pilot or October release targets. Those stages need to be checked separately.⁸⁴

UiPath — agents that build and run agents. September release notes introduce advanced agents in preview, with file workspaces, subagents, and programmatic tool calls. Autopilot Agent, also in preview, builds and debugs agents and their evaluations in Studio Web. This is authoring and execution infrastructure inside an automation platform.⁸⁵

These announcements broaden the places an orchestrator may encounter delegated work. A private preview, a generally available feature, and a promised release are different evidence. For each, inspect the actual permission model, operating record, budget controls, and handoff before incorporating it into a design.

Yegge’s change of direction leaves a practical question for anyone using a reusable harness: what must be revalidated when the model changes? A durable queue can preserve the work while the workers stop converging on it. Reuse is a design choice to test against the workflow, the model, and the evidence of completed work.