From Prompt Experiments to Operable Agent Systems: Gas Town on Microsoft’s AI Stack

If you’ve spent any time experimenting with agentic systems, you’ve probably hit the same wall again and again: agents are great at doing work, but terrible at remembering it. Context evaporates. Coordination breaks down. Restarting the system feels like reliving 50 First Dates—the same conversations, the same mistakes, every single time.

That’s where the Gas Town pattern becomes interesting.

Popularized by Steve Yegge, Gas Town reframes software development as a city of cooperating agents. Instead of a single, all-knowing model, you have clear roles: a coordinator (the “Mayor”), specialized workers, and—most importantly—persistent memory backed by Git. Work is explicit, versioned, and durable. Agents can come and go without losing the plot.

In this post, we’ll look at how Gas Town maps cleanly onto a modern Microsoft stack using GitHub Copilot and Azure AI Foundry—and how that mapping turns a clever idea into something you can actually operate in a real enterprise.

Gas Town in Practice

At its core, Gas Town is about roles and persistence.

Short-lived agents do focused units of work. Longer-lived agents provide continuity. A coordinator plans, delegates, and reconciles outcomes. And everything that matters—decisions, code, artifacts, state—is written down in a repository.

This directly addresses what Yegge famously described as the “50 First Dates” problem: language models forget, but Git doesn’t.

The key shift is philosophical. Agent output isn’t treated as chat transcripts or ephemeral thoughts. It’s treated as accountable data. Every decision leaves a trail. Every change has provenance. If something breaks, you can see who (or what) did what, and why.

Where GitHub Copilot Fits

GitHub Copilot has evolved well beyond autocomplete. Today, it acts as a collection of execution-focused agents that can:

• Write and refactor code

• Review pull requests

• Operate through the CLI

• Apply patterns learned across tasks through shared context

The Copilot SDK exposes this same runtime, allowing you to embed Copilot agents directly inside your own orchestration layer. You don’t need to invent a new execution engine. Copilot becomes your skilled labor pool.

In Gas Town terms, Copilot agents are ideal short-lived workers: focused, disposable, and highly capable. They do the work, commit the results, and move on.

Azure AI Foundry as the Control Plane

Execution alone isn’t enough once you move past demos. In an enterprise setting, you also need governance, observability, evaluation, and integration with business systems.

That’s where Azure AI Foundry comes in.

Foundry provides the control plane for agentic systems: agent hosting, memory, telemetry, evaluation, and policy enforcement. Through Copilot Studio, you can build parent agents that coordinate work, delegate to child agents, and integrate safely with enterprise data and tools.

This is the point where agentic systems stop being experimental and start becoming operational.

How the Pieces Map Together

When you look at Gas Town, GitHub Copilot, and Azure AI Foundry side by side, the alignment is surprisingly clean:

Gas Town Concept	What It Does	Microsoft Stack Equivalent
Mayor	Plans work, coordinates agents, maintains overall intent	Copilot Studio parent agent or Azure AI Foundry orchestrator
Short-lived workers	Execute focused, disposable tasks	GitHub Copilot SDK sessions
Persistent workers	Maintain long-running domain context	Azure AI Foundry–hosted agents or connected Copilot agents
Merge and review	Enforce quality and correctness	GitHub pull requests with Copilot-assisted code review
Watchdogs and maintenance	Observe health, enforce policy, audit behavior	Azure AI Foundry observability, evaluation, and governance
Persistent memory	Store durable system state and decisions	Git repositories plus Foundry memory and telemetry

This mapping turns Gas Town from a theoretical model into a practical blueprint.

A Reference Architecture

In a typical setup, a developer interacts with a parent agent built in Copilot Studio. That agent plans the work and delegates tasks to short-lived Copilot SDK workers.

Those workers operate directly against GitHub repositories, submitting changes through pull requests. Quality gates are enforced through repository policy and Copilot-assisted review. Azure AI Foundry provides centralized logging, evaluation, memory, and secure access to enterprise systems.

Final outputs are deployed to Azure runtimes such as App Service, Azure Functions, or Kubernetes.

Agents can fail independently. Work remains auditable. The system keeps moving.

How to Start Without Overengineering

You don’t need a city on day one.

Start with:

• One orchestrator agent

• Two worker agents

• A single repository

Use the Copilot SDK for execution and GitHub for quality control. Turn on telemetry and evaluation immediately. Measure latency, cost, and correctness before adding more agents.

Agent systems scale best when growth is intentional, not enthusiastic.

Risks and Real-World Constraints

Agent sprawl is real. Too many agents create coordination overhead. Unbounded memory hurts performance. Weak governance creates risk.

The fix isn’t more prompts—it’s discipline.

Treat orchestration as architecture. Keep memory explicit. Centralize policy. If you wouldn’t allow a human developer to operate without oversight, don’t allow an agent to do it either.

Closing Thoughts

Gas Town gives us a way to think about agentic software as coordinated, stateful work, not clever prompt chains. GitHub Copilot provides the execution layer. Azure AI Foundry supplies the enterprise control plane.

Together, they offer a practical path from experimentation to production.

Start with a small city. Instrument everything. Let evidence—not enthusiasm—guide your expansion.

• Authour - Kevin Evans