Gas Town vs Claude Agent Teams vs GSD: Multi-Agent Orchestrators

A single Claude Code session is already agentic: it plans, calls tools, and verifies its own work in a loop. It hits a ceiling on a different axis — throughput and independent perspective, not capability. A large migration, a systemic bug hunt, or a feature that spans frontend/backend/tests all benefit from work happening at the same time by agents that don't share one context window.

Subagents already parallelize some of this, but a subagent only reports back to the session that spawned it — it can't message a sibling subagent, disagree with it, or claim a task off a shared queue. Gastown, Claude Agent Teams, and GSD all add that missing layer, but they picked different failure modes to optimize against: Gastown makes git the durable memory, Claude Agent Teams builds a shared task list with file-locking into the product, and GSD keeps the orchestrator deliberately thin while each worker gets a fresh 200K-token window.

Before reaching for any of them, name the actual bottleneck. If tasks are sequential or touch the same files, one session is faster and cheaper than any of these three — coordination overhead is real, and every orchestrator here spends extra tokens keeping agents from colliding.

Sub-agents are specialized workers spawned by a main agent for bounded side work. In Claude Code, a subagent starts with its own isolated context window, custom instructions, and explicit tool access, then returns a result summary to the caller. That makes sub-agents useful when the main conversation would otherwise get flooded with search results, logs, or file contents you do not need to keep in the main context.

The key limit is communication. A sub-agent reports back to the main agent; it does not message sibling sub-agents, claim tasks from a shared queue, or keep a durable identity after the delegated task ends. That is why sub-agents are not the same as Agent Teams or a Gas Town fleet. For checkout-service, a main session might spawn one test-runner sub-agent to inspect failing timeout tests, receive a compact summary, and keep editing in the main conversation.

Multi-agent systems add independent workers around a shared goal. The hard part is not launching several model calls; it is deciding who owns the plan, which worker owns each file or task, how workers share evidence, how conflicts merge, and where recoverable state lives. Without those contracts, five agents are just five opportunities to produce incompatible patches.

The checkout-service bug makes the boundary concrete. A test worker can reproduce the double charge, a backend worker can inspect idempotency handling, and a client worker can audit retry behavior. Those tasks are parallel only if they touch different files and produce evidence the orchestrator can merge. If all three need to edit the same payment handler, a single agent with sub-agents for research is usually safer than a multi-agent system.

The project styles itself as Gas Town in its repository title, while many developers write Gastown as one word because the GitHub org/package names use that form. This article keeps the stable URL as gastown-vs-claude-agent-teams-vs-gsd, but the concept is Gas Town: a multi-agent workspace manager where git is the coordination substrate.

Gas Town's vocabulary is strange at first because it names the coordination objects rather than hiding them. A rig is the project workspace. A mayor coordinates. Polecats are worker agents with persistent identity and ephemeral sessions. Beads are git-backed work items. Convoys bundle beads for execution. Hooks are git worktree-based persistent storage. Seance discovers and queries previous sessions through .events.jsonl logs. The point is not whimsy; the point is that each term names where state and recovery live.

What it is. Gas Town (from Steve Yegge, maintained under the gastownhall org) is a workspace manager for running many coding-agent CLIs — Claude Code, Copilot, Codex, Gemini — against the same set of projects. Its unit of organization is the rig, a project container wrapping a git repository. Inside a rig, polecats are worker agents with a persistent identity but an ephemeral session: the process can die and restart, but the polecat's history survives. A mayor agent holds full workspace context and assigns work.

How it runs. Work is tracked as beads — git-backed issue records, not an external database — and beads bundle into convoys assigned to a polecat. The mechanism that makes this durable is hooks: git worktrees that persist state, task status, and event history as ordinary git objects. Every action a polecat takes is appended to a .events.jsonl log inside its hook. When a polecat's process restarts — crash, laptop sleep, container recycle — it does not reconstruct state from a live process; it discovers and queries predecessor sessions through Seance. That is the core idea: state is not only in memory, it is in git, so process interruption is recoverable by reading durable history.

Boundary. Gas Town owns fleet coordination and durability across agent CLI vendors — it does not run the models itself; it wraps whichever CLI you already use. It is the heaviest of the three to adopt: you install a shell tool, run a mayor, and think in git-native primitives (rigs, beads, convoys) that have no equivalent in a single Claude Code session.

What it is. Agent Teams is an experimental Claude Code feature (enabled with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) where one session becomes the lead and spawns teammates — each a full, independent Claude Code instance with its own context window. Unlike a subagent, a teammate does not only report back to its caller: it can message the lead or any other teammate directly, and a human can message a teammate directly too, bypassing the lead entirely.

How it runs. Coordination happens through two structures the lead creates automatically: a shared task list (~/.claude/tasks/{team}/) where tasks carry a state — pending, in progress, completed — and can declare dependencies, and a mailbox per agent (~/.claude/teams/{team}/inboxes/{agent}.json) for direct messages. Teammates self-claim the next unblocked task, and file locking on the task list prevents two teammates from claiming the same item in a race. When a teammate finishes a task that others depend on, the dependent tasks unblock automatically — no polling, no lead intervention required.

Boundary. Agent Teams owns in-session, same-machine coordination for Claude Code specifically — it doesn't span other CLIs or persist a workspace identity the way Gastown does. It is explicitly experimental: task-list state can lag (a teammate finishes work but forgets to mark the task complete, blocking dependents), and /resume does not restore in-process teammates — the lead can end up messaging teammates that no longer exist.

What it is. GSD (Get Shit Done) is an npm package (get-shit-done-cc) layered on top of Claude Code, OpenCode, Codex, Copilot, Cursor, and others. It is not a persistent fleet manager like Gastown, and it doesn't rely on inter-agent messaging like Agent Teams. Its core bet is that the orchestrator itself is the fragile part of any multi-agent system — a long session that keeps accumulating context degrades in quality — so GSD keeps the orchestrator's own context at roughly 10–20% usage and pushes all heavy work into subagents that each get a fresh 200K window.

How it runs. GSD's workflow is spec-driven: /gsd:new-project and /gsd:plan-phase 1 spawn researchers, synthesizers, and planners that write structured markdown into a .planning/ directory — PROJECT.md, REQUIREMENTS.md, PLAN.md per unit of work. /gsd:execute-phase 1 reads those plan files and runs dependency-ordered waves: plans that declare no dependency on each other run in parallel; a plan that depends on another waits. Each spawned executor gets a tailored context assembly — only the specific PLAN.md and referenced source files it needs — rather than the orchestrator's full history. /gsd:verify-work 1 then spawns debuggers against anything that failed.

Boundary. GSD owns context engineering and phased execution within a single project directory — it has no cross-CLI fleet concept and no live inter-agent mailbox; agents communicate only by reading and writing the same markdown files. That file-based communication is also its resilience mechanism: because state is plain markdown, not a live task list or an in-memory session, a project can be resumed by re-reading .planning/ days later.

Here is the story that actually separates these tools: an agent working on the checkout-service idempotency fix gets killed mid-task — the container is recycled, the laptop sleeps, or the process OOMs. The visible symptom is identical everywhere: a task that was 'in progress' now has no running agent behind it. What each orchestrator does next is where the architecture shows.

Gastown doesn't need to ask what the polecat was doing — its hook already has an .events.jsonl log of every action taken before the crash. A new polecat process (or the same one restarting) runs gt seance, replays the log, and continues from the last committed event. Because the log is git-backed, this works even if the crash happened on a different machine entirely. Claude Agent Teams has no durable identity to resume — the task simply stays marked "in progress" with no owner, which is exactly the documented limitation: task status can lag, and /resume does not restore in-process teammates. Recovery here is manual: a human notices the stuck task, checks whether the work is actually done, and either updates the status or tells the lead to spawn a replacement teammate. GSD sits in between: there's no live session to lose, because the executor's only durable output was ever the markdown files it wrote — PLAN.md and any SUMMARY.md — so re-running /gsd:execute-phase 1 re-reads the wave state, sees the crashed plan is incomplete, and re-spawns a fresh executor for just that plan, not the whole phase.

The generalizable lesson: durability scales with how much of an agent's state lives outside its own process. Gastown externalizes the most (every action, in git); GSD externalizes the plan and result but not intermediate reasoning; Agent Teams externalizes the least by default, trading that for the richest live communication between agents while they're actually running.

Start from what you're actually optimizing, not from which tool has the most attention this month. Use Claude Agent Teams when the work is exploratory and benefits from disagreement — competing bug hypotheses, a multi-angle code review, a design debate — and it fits inside one Claude Code session on one machine. It has the least setup (one environment variable) and the richest live communication, which matters most when agents genuinely need to argue with each other before converging.

Use GSD when the work is a real, multi-phase project with a spec you want to survive the session — a migration, a new service, anything you'd want to resume next week exactly where you left off — and you want the orchestrator itself to stay cheap and non-degrading as the project grows. Its dependency waves are the right model when some units of work are strictly sequential and others aren't.

Use Gastown when you're running a genuine fleet: many agents, possibly across different CLI vendors, across multiple repos, over days or weeks, where a laptop sleeping or a container recycling must never lose track of work. That durability is real, but it comes with the most new vocabulary (rigs, polecats, beads, convoys) and the most operational surface to learn — don't reach for it just because the article title puts it first.

All three are moving targets: version numbers, flags, and defaults referenced here (Claude Code teams as of v2.1.178+, GSD's current command set, Gastown's v1.2.1) will drift. Read each project's own docs before building a workflow you depend on. Official source notes checked July 2026: Claude Agent Teams at code.claude.com/docs/en/agent-teams; Gastown at github.com/gastownhall/gastown; GSD at github.com/gsd-build/get-shit-done and github.com/gsd-build/get-shit-done/blob/main/docs/COMMANDS.md. For the single-session fundamentals these orchestrators build on, see Claude Code workflow basics and what agentic AI actually is.