developmentL5 AutonomousCoding Agent Usage

Multi-agent orchestration (Gas Town / custom)

How to build systems where specialized agents collaborate - a planner decomposes tasks, workers execute them, and reviewers validate results - to handle complex engineering tasks end-to-end.

·Multi-agent orchestration system (planner-worker hierarchy) is in production
·Agent fleet sustains 100+ concurrent agents on the codebase
·Agent fleet produces 1,000+ commits per week without manual dispatch

·Planner agents decompose epics into tasks and assign to worker agents autonomously
·Agent fleet self-recovers from failures without human escalation for 90%+ of error cases

Evidence

·Orchestration system dashboard showing planner-worker task flow
·Git history showing 1,000+ weekly commits attributed to agent fleet
·Agent fleet monitoring showing concurrent agent count and error recovery rate

What It Is

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.

Why It Matters

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

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.

Tip

Build orchestration incrementally. Start with a two-agent system (planner + one worker) on a single task type before adding reviewers, additional workers, and complex routing. The complexity of multi-agent systems grows faster than the number of agents; earn that complexity with proven simpler configurations first.

Getting Started

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

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has been delivering impressive results with L4 parallel agents, but he's seeing a pattern: the tasks that take the most effort are the ones that require coordination across multiple areas of the codebase. These are exactly the tasks that would benefit from orchestration, but Bob doesn't know if the team is ready for the L5 investment.

What Bob should do: L5 orchestration is a significant infrastructure investment - likely a dedicated 2-4 week engineering project before it produces business value. Bob should only initiate this if the L4 foundation is solid: mature CLAUDE.md files, reliable agent sandboxes, established review protocols, and demonstrated parallel agent workflows. The signal for L5 readiness is when developers say "the bottleneck is no longer implementation - it's the coordination overhead of managing multiple agents." When that statement is consistently true, orchestration automation is the right investment. Bob should frame it as infrastructure engineering: assign Victor to design and build the orchestration layer, with a 6-week timeline and specific success criteria.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is watching the L5 trend in the industry and wants to understand the ROI before committing to the engineering investment. Multi-agent orchestration sounds transformative but also sounds expensive to build.

What Sarah should do: Sarah's analysis should compare two costs: (1) the engineering investment to build the orchestration system (one-time, 4-8 weeks of engineering time), and (2) the ongoing human coordination cost it replaces (the time senior developers spend orchestrating parallel agents manually at L4). If senior developers are spending 2+ hours per day on agent coordination, an orchestration system that reduces this to 30 minutes of review has a payback period measured in weeks. Sarah should also look at task types: which tasks require the most agent coordination? Those are the candidates for the first orchestration pipeline. A focused first pipeline targeting a high-frequency task type will demonstrate ROI faster than a general-purpose orchestration system.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been informally acting as the "planner agent" himself - decomposing complex tasks into subtasks, assigning them to different Claude Code instances, and synthesizing the results. He knows this manual orchestration is the bottleneck and wants to automate it.

What Victor should do: Victor should document his manual orchestration process first, before automating it. For the last 10 complex tasks he coordinated: how did he decompose them? What criteria determined subtask assignments? How did he handle failures? What information did he pass to each agent? This documentation is the specification for the planner agent he'll eventually build. Victor should then propose a concrete L5 project: build a planner agent that can decompose a specific category of tasks (e.g., "implement REST endpoint from spec") into the same subtask structure he uses manually. Automate one task type end-to-end before generalizing. The first successful end-to-end orchestration is the proof of concept that justifies broader investment.

What Victor should do - role-specific action plan