Gastown 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 assumes agents (and the humans running them) will restart constantly, so it makes git the durable memory. Claude Agent Teams assumes the risk is agents silently duplicating or dropping work, so it builds a shared task list with file-locking directly into the product. GSD assumes the risk is context rot — a long-running orchestrator degrading as its own window fills — so it keeps the orchestrator deliberately thin and gives every worker 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.

What it is. Gastown (from Steve Yegge, now 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, 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 doesn't reconstruct state from a live process; it replays its own event log, a feature Gastown calls Seance. That is the core idea: state is not in memory, it's in git, so any process interruption is recoverable the same way a git pull is.

Boundary. Gastown 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 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 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 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 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 — see Anthropic's official Agent Teams reference and each project's GitHub repo for the deepest, most current detail — before building a workflow you depend on. For the single-session fundamentals these orchestrators build on, see Claude Code workflow basics and what agentic AI actually is.