The Orchestrator

Software has coordinated work for decades. Workflow engines scheduled defined activities, and BPMN gave organizations a standard way to model business processes.¹ Those systems are antecedents, not equivalents. They coordinate processes that people largely specify in advance. The systems emerging now can interpret a goal, decompose it, assign work, select tools, revise the plan, and carry context across runs. I have not found a pre-LLM platform that combined those capabilities at this breadth in a generally available orchestration layer.

The coordination problems are being worked out in software development first, and the examples are already numerous. Gas Town, built by Steve Yegge and released in January 2026, runs twenty or thirty coding agents in parallel — a mix of Claude Code, GitHub Copilot, Codex, and others.² A coordinating agent called the Mayor takes your request, breaks it into tasks, and assigns them to worker agents. Witness agents monitor those workers, detect stuck work, and support recovery; a merge process called the Refinery resolves conflicts when parallel changes touch the same files. That description skips real machinery — state that survives restarts, isolated workspaces, recovery — but the shape is what matters here. It did not invent workflow coordination, and it does not by itself demonstrate the complete business-to-production loop this book describes. What it proves is narrower and still useful: these coordination patterns can be assembled into working software. Gas City is the toolkit extracted from the same infrastructure: an SDK for building that kind of agent workforce for other jobs.

Gas Town is not alone. CrewAI organizes agents into role-based crews with defined tasks. LangGraph models agent work as a graph with checkpoints and human-approval gates. The large platforms have shipped their own open-source frameworks: Microsoft describes its Agent Framework as unifying lessons from AutoGen and Semantic Kernel into a successor for agentic applications, with Semantic Kernel remaining supported during the transition; Google released the Agent Development Kit (ADK); Amazon released the Strands Agents SDK, which teams inside AWS already run in production. MetaGPT, one of the most-starred agent projects on GitHub, simulates a whole software company — product manager, architect, engineers — with orchestrated procedures. The settings differ, but the problems are shared: who owns a task, where state persists, how a stuck worker gets detected, how work is merged, how a person knows what is happening. Those problems show up in any system where several agents work in parallel on the same outcome — which means in every industry, not only software.³

As the field expands you will see orchestration systems appear for operations, customer service, compliance, logistics, healthcare, finance, and public services, each carrying its own specialized vocabulary and its own domain-specific components. An operations system will talk about incidents, alerts, runbooks, and SLAs. A compliance system will talk about regulations, evidence, review cycles, and audit trails. A logistics system will talk about routes, inventory, capacity, and delivery windows.

This book is written from software, because that is where the coordination problems were solved first, but nothing in the structure is software-specific. The names above the line are local; the names below the line are the same everywhere. Each industry will also write its own rules on top — finance will regulate trading autonomy, healthcare will regulate clinical autonomy — and that is the second half of the story: as of this writing I have not located a public example of the complete pattern running inside a regulated industry. No one has done it and advertised it, anyway. It will become more common, and agent-specific regulation and standards are likely to expand and become more explicit as it does — AI is already covered by sectoral law and by AI-specific regulation in some jurisdictions.⁴

Regulated and high-stakes industries are already discovering what happens when automated judgments trigger real-world action. Rite Aid used facial-recognition software to flag suspected shoplifters in hundreds of stores. The FTC alleged that the system produced thousands of false-positive matches and that employees sometimes searched, expelled, or called police on people the system misidentified. The resulting order prohibited Rite Aid from using facial recognition for five years. This was not an autonomous agent, and the settlement is not an adjudicated finding on every allegation — but it shows why consequential automation attracts scrutiny quickly, and why the regulated industries are where the complete loop will have to prove itself first.⁵

Underneath the vocabulary, the concepts from Chapter 3 hold. Gas Town and its relatives have working versions of some of these — task assignment, state that survives a restart, merge discipline — and thin versions of the rest, particularly authority, evidence of who decided what, and audit. Software development is the one field where a bad autonomous decision is usually caught in code review before it reaches a customer, and that safety net is part of why the coordination problem got solved there first.

5.1.1 A note for readers coming from development

A lot of you are coming to this book as people who write software, and you sit at different points on a spectrum. Many of you use Cursor, or Claude Code, or GitHub Copilot, or Codex: you sit in an editor, describe what you want, an agent writes the code, and you evaluate it. That is what the work looks like right now for most developers, and it is a genuine change from what came before.

Some of you have gone further. You installed OpenClaw, or Hermes, or Nanobot, gave an independent agent access to your repositories, and asked it to craft changes you then review as part of a workflow. That is a step toward orchestration: the agent works on its own, and you inspect what it produced. But notice what you are still doing. The work you are doing sits on the boundary between assistance and orchestration. You are creating systems that can work autonomously, but you keep having to step back into the IDE to review or correct code, because the systems are not mature.

Wherever you sit on that spectrum, the permission question arrives on its own. Anyone who has given an agent like OpenClaw or Hermes a service-account key for a cloud provider has already started asking the questions this book is about: how do I put boundaries around what an agent is allowed to do, and how do I keep it from making a catastrophic mistake, by limiting what I grant it in the first place? Development could always treat permissions as somebody else’s problem, because review, test, deploy, and operate were owned further down the chain. The moment the system that writes the code can also deploy it, monitor it, and respond to incidents, the question becomes what the system is allowed to do in production — and it belongs to the person who built it.

What developers need to realize is that this has stopped being purely an engineering question. There is an emerging liability question now, and courts have started answering it. In Moffatt v. Air Canada (2024), the British Columbia Civil Resolution Tribunal held the airline liable for negligent misrepresentation after its website chatbot gave a passenger incorrect bereavement-fare advice, and rejected the argument that the chatbot was a separate legal entity responsible for its own actions. If the system speaks for the company, the company owns what it said. One tribunal’s decision is not a broad precedent governing every agent system, but the inference for organizations is real enough.⁶ In Mobley v. Workday, a federal court allowed the case to proceed on the theory that an AI vendor’s applicant-screening tools can function as an employer’s agent when hiring decisions are delegated to software, and in May 2025 conditionally certified a nationwide age-discrimination collective; the litigation continues, and as of this writing there has been no merits finding of discrimination. The theory alone matters: liability may reach the system that automated the screen rather than stopping at the company that approved the vendor.⁷ These are not hypothetical risks. Both cases involve automated systems speaking or deciding on behalf of an organization, and somebody getting hurt — financially, or in their access to work.

The direct point for developers: your job is no longer just automating the creation of code. You are now automating decisions that have real legal consequences. Checking code into git, compiling, deploying to production — that is the simple version of the job, and it is over.