The Orchestrator

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 the clearest 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 system you could actually run: named workers, durable tasks, queues, recovery, and a working environment an individual could install. The move from demonstration to operating model matters.

It is also narrow in two ways. Gas Town is focused on development, and specifically on developers, on vibe coding, and on work whose output is code in a repository and whose measure is throughput — a real and important use case that is nonetheless not the only one. And in its current form, running Gas Town at scale is one of the most expensive things a human being can do. Yegge himself has called it “expensive as hell.” One early user reported a single sixty-minute session costing roughly $100 in model tokens — an anecdote, not a rate card. What the anecdote does establish is the order of magnitude: this is not hobbyist territory. That is not a criticism of Gas Town so much as a statement about where the economics currently sit. The costs will come down. For now, the cost structure tells you who gets to play, and today the answer is well-funded teams who can absorb the spend.

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 working answer to them, which is not the same as creating the whole category — and Gas Town is not the only useful design.

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.⁵¹

Other systems make other choices:

System	Coordination model	What it contributes	What it is not
Gas Town	Hierarchical workspace and worker system	Persistent work, named roles, monitoring, task tracking, and merge processing	A general theory of orchestration or a replacement for human review
Gas City	Configurable orchestration SDK	Reusable runtime, routing, supervision, packs, and declarative composition	A ready-made workflow for every organization
OpenAI Symphony	Issue tracker as control plane	Maps tasks to isolated agent workspaces, watches state, restarts stalled work, and uses repository-owned workflow instructions	A general multi-agent platform; OpenAI describes it as a minimal reference implementation52
Claude Code Agent Teams	Lead plus independent teammates	Shared tasks, direct teammate messaging, plan approval, and lifecycle hooks	A durable production scheduler; the documentation calls it experimental and lists limits53
OpenHands Agent Canvas and SDK	Agent control center and programmable agent server	Multiple agent backends, scheduled or event-triggered automations, workspaces, tools, MCP, and sandboxed execution	A fixed hierarchy of worker roles54
SWE-agent and mini-SWE-agent	Single coding-agent worker	A model uses tools to investigate and modify a real repository issue	A coordinator for a fleet of agents55
VS Code Agent Sessions	Unified local, background, cloud, and subagent interface	Session visibility, parallel subagents, custom agents, and handoffs	A complete organizational operating model56
CrewAI	Role-based multi-agent crews	Fast prototyping with defined agent personas, tasks, and tools; intuitive mental model of a crew of specialists; Flows add persisted state and human feedback	A cross-system identity, policy, or governance-grade records layer57
LangGraph	Graph-based stateful workflows	Durable execution, checkpointing, human-in-the-loop approval gates, and mid-execution failure recovery for long-running stateful work	An authority-management or governance layer; the orchestration still belongs to a person58

The last two rows come from a different category than the coding-focused systems above them, and they illustrate the confusion of the moment better than any other pair. CrewAI and LangGraph are general-purpose frameworks for building agent systems, which existed long before anyone was talking about AI orchestration as this book defines it — LangGraph was first released in January 2024, when the discussion was still about “workflow automation” — and they belong here not because they are orchestration systems in the sense of this book, but because they are the tooling an orchestrator will most often reach for first, and knowing what they actually do keeps you from mistaking one kind of thing for another.

The distinction that matters applies well beyond LangGraph. LangGraph is not an orchestrator. It is a tool for connecting systems and governing how they communicate, and it gives you the graph, the checkpoints, the approval gates, and the state persistence. What it does not give you is authority management, decision provenance, delegation lifecycle, or the governance layer this book has been describing. It is infrastructure for building workflows, and the orchestration — designing the objective, configuring the agents, setting the boundaries, evaluating the evidence, deciding whether to continue or stop — still has to be done by a person.

The same holds for every system in this chapter. I include them not as recommendations but as evidence of two things at once: the multi-agent space is much larger than coding-agent factories, and the tools for connecting and coordinating agents are arriving far faster than the tools for governing them.

There is no established orchestrator, and there is no product you can buy today that does what this book describes. There are systems that have started to think about pieces of the problem — Gas Town identified the coordination problem, LangGraph the checkpointing and approval problem, CrewAI the role-based organization problem, OpenHands the sandboxed execution problem — and each solved its piece. None solved the whole. The orchestrator, as this book defines the role, is still a person assembling a system by hand: connecting these tools, writing the governance layer in policy documents and review procedures, and remaining accountable for what the result does. The tools will come. They have not arrived.

A warning for the reader who bought this book to orchestrate their work next week. If that is you, the honest answer is: not with anything on the market today, and not without a real investment of time. The systems in this survey are impressive, and young: many are only two or three years old, and several important entrants are newer. Gas Town and Gas City — which under this book’s definition come closest to an operating orchestration platform — involve a fair amount of effort to install, configure, and keep running, and there is no blog post that gets you up and running quickly. A lot of the work this book describes is new, and it will be defined by whoever does it: you pick a specific approach, assemble the pieces, and write the governance by hand. It could all change quickly — if one of these products ships something genuinely comprehensive, this chapter becomes a historical document and the job gets easier. But an orchestrator reading this today should plan for assembly work, not installation.

A new framework seems to arrive every week, and part of the problem is that 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: the platforms have merged their competing frameworks into production defaults (Microsoft Agent Framework, Google’s Agent Development Kit, AWS’s 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 the edges’ main effect is to make the questions in this chapter more important, not less.⁵⁹

One more category belongs in this survey for the sake of equal time: the closed, full-stack proprietary options. The two most consequential are Anthropic’s and OpenAI’s, and neither is a framework — they are 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.

---

49. Gas Town, https://github.com/gastownhall/gastown. Steve Yegge. Released Jan 1, 2026; task state, hooks, agent identity, history, and orchestration state persist in Beads and Git-backed storage. “Expensive as hell” is Yegge’s own characterization. The roughly $100 sixty-minute session is a single early-user report — an anecdote without agent count, duty cycle, or model mix, so no per-agent or per-day rate can be derived from it.↩︎

50. MetaGPT, https://github.com/FoundationAgents/MetaGPT; ChatDev, https://github.com/OpenBMB/ChatDev; AutoGen, https://github.com/microsoft/autogen; CAMEL, https://github.com/camel-ai/camel. All upstream project repositories, verified August 29, 2026. These frameworks demonstrated multi-agent role collaboration before Gas Town’s January 2026 release; the claim is one of precedent, not equivalence in operational form.↩︎

51. Gas City, https://github.com/gastownhall/gascity. Orchestration-builder SDK from Gas Town infrastructure.↩︎

52. OpenAI, Symphony open-source orchestration specification, April 27, 2026, https://openai.com/index/open-source-codex-orchestration-symphony/ (Apache 2.0; a minimal reference implementation in Elixir; verified August 29, 2026).↩︎

53. Claude Code Agent Teams, https://code.claude.com/docs/en/agent-teams. Experimental.↩︎

54. OpenHands, https://github.com/OpenHands/OpenHands. Open-source AI development platform with Agent Canvas and a programmable agent server; sandboxed execution, scheduled and event-triggered automations, MCP support.↩︎

55. SWE-agent, https://github.com/SWE-agent/SWE-agent. Coding agent for real repository issues.↩︎

56. Visual Studio Code, “Agent sessions and where agents run,” 2026, https://code.visualstudio.com/learn/foundations/agent-sessions-and-where-agents-run — unified local, background, cloud, and subagent interface (verified August 29, 2026).↩︎

57. CrewAI documentation, https://docs.crewai.com/ (verified August 29, 2026). Open-source Python multi-agent framework; Flows provide the @persist decorator for automatic state persistence across restarts, plus human-feedback patterns. Documented capability, not an independent assessment of production governance.↩︎

58. LangGraph documentation, https://docs.langchain.com/oss/python/langgraph/overview (verified August 29, 2026). Graph-based stateful workflow runtime; first released January 2024, version 1.0 October 2025. LangChain positions LangGraph as a “low-level orchestration framework and runtime” for long-running, stateful agents, with durable execution, persistence, and human-in-the-loop as documented core capabilities. Documented capability, not an independent assessment of market leadership.↩︎

59. Framework landscape as of August 2026. Microsoft Agent Framework 1.0 (AutoGen + Semantic Kernel merger), https://github.com/microsoft/agent-framework, GA April 3, 2026; Google Agent Development Kit 2.0, https://adk.dev/2.0, GA May-June 2026; Strands Agents SDK, https://github.com/strands-agents (production use inside Amazon Q Developer, AWS Glue, and VPC Reachability Analyzer); OpenAI AgentKit wind-down announcement, June 3, 2026 (Agent Builder and Evals sunset November 30, 2026), https://openai.com/index/introducing-agentkit; presenc.ai agent framework rankings, May 2026 (25+ open-source frameworks, ~1.3M combined GitHub stars), https://presenc.ai/research/ai-agent-framework-github-rankings-2026; PydanticAI, https://github.com/pydantic/pydantic-ai; Mastra, https://github.com/mastra-ai/mastra; Agno, https://github.com/agno-agi/agno; smolagents, https://github.com/huggingface/smolagents; LlamaIndex, https://github.com/run-llama/llama_index.↩︎

60. Reuters, “Anthropic clinches $380 billion valuation after $30 billion funding round,” February 12, 2026, https://www.reuters.com/technology/anthropic-valued-380-billion-latest-funding-round-2026-02-12 — reported Claude Code run-rate revenue above $2.5 billion, more than doubling since the start of 2026; a company-reported figure relayed by Reuters, not an audited number, and used here only as evidence of vendor concentration. Claude Agent SDK, https://www.anthropic.com/news/agent-sdk; Claude Cowork, January 2026; self-hosted Claude Code environments, public beta August 6, 2026 (https://support.claude.com/en/articles/12138966-release-notes). OpenAI: Responses API, March 11, 2025, https://openai.com/index/new-tools-for-building-agents; ChatGPT Agent, July 17, 2025, https://openai.com/index/introducing-chatgpt-agent; Codex agent line and CLI; AgentKit wind-down, June 3, 2026, https://openai.com/index/introducing-agentkit.↩︎