Obsah

Gas Town

Gas Town je open-source multi-agent workspace manager pro Claude Code, GitHub Copilot, Codex, Gemini a další AI coding agenty. Nejde o jeden editorový plugin, ale o koordinační vrstvu nad více agenty, git repozitáři a pracovními rolemi. Hlavní myšlenka je oddělit krátkodobou session agenta od dlouhodobého stavu práce, aby se kontext neztrácel po restartu nebo pádu procesu.

Co projekt řeší

README projektu popisuje několik praktických problémů:

Gas Town to řeší tím, že stav práce ukládá do perzistentní vrstvy postavené nad gitem, worktree a systémem Beads. Session jednotlivých agentů mohou být krátké a pomíjivé, ale identita agenta, přidělená práce a historie zůstávají uložené.

Jak funguje

Town, rig a crew

Celý workspace se v terminologii projektu jmenuje Town. Typicky jde o adresář jako ~/gt, ve kterém jsou uložené konfigurace, registry projektů, metadata agentů a společná infrastruktura.

Jednotlivý projekt se nazývá Rig. Rig obaluje konkrétní git repozitář a spravuje jeho pracovní role, worktree, tasky a merge workflow.

Crew je lidský workspace v rámci rigu — tedy místo, kde pracuje člověk. Oproti tomu worker agenti běží odděleně ve vlastních pracovních adresářích.

Mayor, polecats a hooks

Hlavní koordinátor se jmenuje Mayor. To je agent, kterému se zadá cíl a on z něj rozpadne práci na menší kroky, vytvoří trackované úkoly a přidělí je workerům.

Worker agenti se jmenují Polecats. Každý polecat dostane konkrétní task a pracuje izolovaně od ostatních.

Důležitou roli mají Hooks — perzistentní úložiště práce postavené nad git worktree. Právě tady je uložený pracovní stav, který má přežít restart session.

Beads, convoys a dohled

Jednotlivé tasky jsou v Gas Townu vedené jako Beads s vlastními ID. Nad nimi se vytvářejí Convoys, tedy skupiny práce, které lze rozdělovat mezi agenty a průběžně sledovat.

Nad běžícími agenty stojí další role:

Architektura perzistence

Architektonická dokumentace popisuje dvouúrovňový model evidence práce:

V praxi to znamená, že strategická a koordinační vrstva je oddělená od tasků konkrétního projektu.

Stejný dokument také popisuje, že:

Typický workflow

Základní bootstrap podle README vypadá takto: 

gt install ~/gt --git
cd ~/gt
 
gt rig add myproject https://github.com/you/repo.git
gt crew add yourname --rig myproject
cd myproject/crew/yourname
 
gt mayor attach

Po spuštění Mayor session se práce obvykle řídí přes convoy a přidělování beadů: 

gt convoy create "Feature X" gt-abc12 gt-def34 --notify --human
gt sling gt-abc12 myproject
gt convoy list
gt agents

Zjednodušeně to funguje takto:

  1. člověk zadá Mayorovi cíl
  2. Mayor vytvoří convoy a rozdělí práci na beads
  3. konkrétní bead se přes gt sling přidělí worker agentovi
  4. worker pracuje ve vlastním worktree a průběžně ukládá stav
  5. hotová práce jde přes merge queue, ne přímo do main

Důležité části systému

Kromě samotného dispatchingu agentů projekt obsahuje i další vrstvy:

Kdy Gas Town dává smysl

Projekt dává smysl hlavně tam, kde jeden agent v jednom terminálu nestačí a je potřeba řídit více izolovaných workerů nad jedním nebo více repozitáři. Podle README míří Gas Town na workflow, kde se koordinuje více tasků současně a kde je důležité, aby stav práce přežil restart agentů i delší běh.

Prakticky je zajímavý hlavně pro:

Praktické poznámky

Gas Town není malý doplněk do editoru. README uvádí několik předpokladů, mimo jiné Go 1.25+, Git s podporou worktree, Dolt, Beads, SQLite a ideálně i tmux. Projekt má také vlastní, poměrně bohatou terminologii — Mayor, Rig, Polecat, Hook, Convoy, Witness, Refinery, Deacon — takže první seznámení je spíš o pochopení celého modelu práce než o jednom příkazu navíc.

Projekt je navržený pro složitější orchestration scénáře, ne pro nejjednodušší single-agent použití.

Zdroje