Introduction
In January 2026, Steve Yegge introduced Gas Town, an experimental multi-agent development system built around a simple but radical idea: instead of using AI as a coding assistant, use AI as a coordinated workforce. Gas Town runs 20–30 agents in parallel. Each agent has a role. The developer acts as an Overseer, not a typist — coordinating work rather than writing individual functions. The original implementation is built on Claude Code and a substantial custom orchestration layer written in Go. But the architectural pattern itself — hierarchical multi-agent coordination with persistent state — is not tied to any specific runtime. This article explores what a Gas Town-style system would look like if implemented using Microsoft Foundry and GitHub Copilot's pro-code tooling.
What Gas Town Actually Is
Gas Town is not "Copilot, but bigger." It is closer to a distributed build system for AI agents. Its defining characteristics:
- 20–30 agents operating simultaneously
- Clear role separation between coordination and execution
- Git-backed persistent state ("Beads")
- Long-horizon autonomy across multi-step tasks
- Terminal-based visibility into agent activity
Instead of prompting repeatedly, the developer assigns a goal. The system decomposes the goal into sub-tasks, distributes them across workers, supervises output, and merges results. The novelty is orchestration.
Microsoft's Relevant Building Blocks
To reproduce this architecture in Microsoft's ecosystem, three primary components matter:
1. Microsoft Foundry
Microsoft Foundry (formerly Azure AI Studio) provides:
- Agent Service for structured agent execution
- Access to multiple model providers
- Memory services
- Evaluation pipelines
- Telemetry and monitoring integration
From a systems perspective, Foundry replaces the need to build a custom multi-agent runtime from scratch.
2. GitHub Copilot SDK & CLI
GitHub Copilot's SDK and CLI allow programmatic interaction with code generation models. This is important because Gas Town's worker agents are essentially programmable coding units. Using the SDK or gh copilot, it becomes possible to:
- Spawn scoped code-generation sessions
- Attach them to isolated branches
- Automate pull request creation
- Integrate with CI pipelines
That aligns naturally with Gas Town's "short-lived worker" model.
3. Supporting Azure Services
A production implementation would also rely on:
- Azure Container Apps for isolated execution
- GitHub for version control
- Azure Cosmos DB for structured memory
- Azure Monitor for observability
These services provide the operational scaffolding around the agent system.
Gas Town → Microsoft Architecture Mapping
| Gas Town Concept | What It Does | Microsoft Stack Equivalent |
|---|---|---|
| Mayor | Plans work, coordinates agents | Foundry orchestrator agent |
| Short-Lived Workers (Polecats) | Execute focused coding tasks | GitHub Copilot SDK sessions |
| Persistent Workers | Maintain long-running context | Foundry agents with memory |
| Merge & Review (Refinery) | Integrate and enforce quality | PRs + CI + Copilot review |
| Witness / Supervision | Validate correctness | Foundry evaluation pipelines |
| Persistent Memory ("Beads") | Store durable state | Git + Cosmos DB + Foundry memory |
| Watchdogs | Monitor health and behavior | Azure Monitor + telemetry |
This mapping turns Gas Town from a theoretical model into a practical blueprint.
How the System Would Function
Orchestration
In Gas Town, orchestration is handled by ~189k lines of Go. In a Microsoft implementation, orchestration would be handled by:
- A primary Foundry agent acting as coordinator
- Structured task decomposition
- Event-driven execution across worker agents
The difference is not conceptual — it is infrastructural.
Worker Execution
Each short-lived worker would:
- Receive a scoped task
- Check out a Git branch
- Generate or modify code
- Run tests (via CI)
- Submit a pull request
- Terminate
Persistent workers could maintain architectural context, shared knowledge, or domain understanding across sessions.
State Management
Gas Town's "Beads" system uses Git to maintain persistent work state. A Microsoft-based version would likely combine:
- Git for version history
- Cosmos DB for structured agent memory
- Foundry memory services for contextual recall
- Search indexing for retrieval-augmented generation
The pattern remains Git-centric, but memory becomes more flexible.
Supervision and Evaluation
Gas Town includes supervisory roles (Witness, Refinery). In Microsoft's ecosystem, supervision becomes:
- Automated test agents
- Evaluation pipelines in Foundry
- Pull request gating
- Telemetry-driven validation
This reduces reliance on manual review while keeping traceability.
Differences Worth Noting
There are meaningful differences between the original Gas Town and a Microsoft implementation.
- Gas Town is local and experimental; Foundry is managed and service-based.
- Gas Town uses a terminal-first interface; Azure-native tooling would require dashboards or custom UIs.
- Gas Town's orchestration is bespoke; Foundry provides structured agent primitives.
The tradeoff is flexibility versus operational maturity.
What This Suggests About Multi-Agent Development
Gas Town demonstrates that multi-agent coordination is technically viable. Microsoft's stack suggests that the same pattern can be implemented using managed services rather than custom infrastructure. The broader shift is this: Developers increasingly design systems that coordinate AI agents instead of directly producing code. Gas Town shows what that looks like in experimental form. A Microsoft-based implementation shows how it could be structured using enterprise infrastructure. The architectural pattern remains consistent:
- Decompose intent
- Parallelize execution
- Maintain durable state
- Supervise output
- Merge deterministically
The tools change. The model of development evolves.