Multi-agent orchestration (Gas Town / custom)

Multi-agent orchestration is a system architecture where multiple AI agents with different specializations collaborate to complete complex engineering tasks. Rather than one agent doing everything, responsibilities are distributed: a planner agent decomposes a high-level task into subtasks; worker agents execute those subtasks in parallel; reviewer agents validate the work; an orchestrator manages the pipeline and handles failures. The system produces a complete, tested, review-ready result from a high-level task description.

"Gas Town" refers to an open-source multi-agent framework that implements this architecture. Named after a concept from the post-scarcity AI development world, it provides the scaffolding for agent-to-agent communication, task routing, result aggregation, and failure handling. Custom implementations at companies like Anthropic, Stripe, and Devin follow similar patterns with proprietary extensions.

At L5 (Autonomous), multi-agent orchestration is not a research project - it's how engineering work gets done. The team defines what needs to be built (product requirements, acceptance criteria, architectural constraints); the agent system figures out how to build it (task decomposition, implementation, testing, iteration). Humans review the results and set direction; agents handle the execution at a scale no human team could match.

The critical difference from L4 (parallel agents per developer) is coordination. At L4, a human orchestrates multiple agents manually. At L5, an agent orchestrates other agents autonomously - the planner decides how to decompose the task and which worker to assign each subtask to, without human direction of those choices.

Multi-agent orchestration unlocks the ceiling on what AI-assisted development can achieve:

• Handles complexity beyond single-agent scope - tasks that are too complex for one agent (implement this entire service with auth, persistence, tests, and documentation) are handled by a coordinated team of agents
• True parallelism at scale - dozens of worker agents executing in parallel, coordinated by a planner, can complete in hours what a human team would take weeks to deliver
• Specialization compounds - a reviewing agent trained specifically on your security patterns catches issues that a general-purpose worker agent would miss; specialization produces better results than generalism
• Self-healing pipelines - when a worker agent fails, the orchestrator can reassign the task, provide additional context, or break it into smaller subtasks; human intervention is only needed for genuinely novel failures
• Separates planning from execution - the planner agent can reason about task dependencies, resource allocation, and risk in ways that are difficult when planning and execution are interleaved

In May 2026 multi-agent orchestration shipped as a product default rather than a custom build. Claude Code "dynamic workflows" (announced late May) let a script Claude writes spawn dozens-to-hundreds of subagents under a single run, and Anthropic's Code w/ Claude conference (May 6) introduced fleets, Outcomes, and Dreaming. The practical implication: the L5 orchestration pattern is now buyable, not only something you have to build yourself - though the foundational discipline below still decides whether it pays off.

The prerequisite for L5 multi-agent orchestration is an extremely mature L2-L4 foundation. The planner agent needs accurate context (CLAUDE.md, architecture docs) to decompose tasks correctly. The worker agents need reliable sandboxes and clear task specifications. The reviewer agents need defined quality standards. Without this foundation, orchestration amplifies problems rather than solving them.

1. Study existing orchestration frameworks - Read the Gas Town source code, review Anthropic's multi-agent documentation, and study how companies like Stripe describe their internal agent systems. Understand the patterns before building.
2. Define your agent roles - At minimum: planner (decomposes tasks), worker (executes subtasks), reviewer (validates output). Each role needs a clear scope, input/output interface, and failure behavior. Write these as specifications before building.
3. Build the communication layer - Agents communicate via structured messages (typically JSON). Define your message schema: task specification, subtask assignment, result reporting, failure escalation. This schema is the contract between agents.
4. Implement the simplest viable planner - A planner that can decompose "implement endpoint X" into ["write handler function", "write tests", "update routing", "update documentation"] is a meaningful starting point. The planner doesn't need to be perfect; it needs to be good enough that worker agents can execute its subtasks.
5. Start with homogeneous workers - Your first workers should all be instances of the same agent (Claude Code) with the same CLAUDE.md context. Specialization (worker agents with different prompts for different task types) comes after the basic pipeline is working.
6. Build the failure handling pipeline - Define: what does a worker failure look like? When does the orchestrator retry vs. escalate to a human? How are partial results handled? Robust failure handling is what separates a production-ready orchestration system from a demo.

Building the full system before validating the components. A multi-agent system is only as good as its weakest agent. If your worker agents produce unreliable results, orchestration amplifies that unreliability. Validate each agent role in isolation before wiring them together. A worker agent that succeeds 70% of the time in isolation will succeed less when coordinated with others due to compounding failure probabilities.

Underestimating orchestration complexity. The planner agent must understand task dependencies, resource constraints, and failure modes. This is significantly more complex than a worker agent that follows a specific task spec. Plan for 2-3x the engineering effort you'd estimate for a single-agent system.

Poor observability into agent behavior. With 10+ agents running in a pipeline, understanding what went wrong requires comprehensive logging. Every agent action, every inter-agent message, every task state transition must be logged with timestamps and correlation IDs. Without this, debugging orchestration failures is nearly impossible.

Context dilution across agent boundaries. When the planner sends a subtask to a worker, how much context travels with it? Too little, and the worker makes wrong assumptions. Too much, and the context window fills with irrelevant information. Context packaging - deciding exactly what context each agent needs for each subtask - is one of the hardest problems in multi-agent system design.