Skip to main content
You know these capabilities from coding agents (Claude Code, Codex, Gemini CLI, Cursor, …) as features of a single agent. In Gas City they are infrastructure shared across many agents. Here is the quick map, ordered from the most basic to the most multi-agent. The rest of this page is one delta per capability — what changes when the single-agent feature becomes shared infrastructure. Agents coordinate only through the store: mayor, reviewer, and worker each read and write the shared bead store (slinging work, claiming ready work, mailing a bead) — no arrow connects two agents directly. A nudge can wake a live session, but the work itself only ever moves through beads.

​
Context

The window is seeded automatically, per agent, from durable sources — you never hand-assemble it.
  • It starts from the agent’s role: a prompt template rendered with deployment data (city, rig, working directory, branch, custom variables).
  • Its current work items and mail — all beads — flow in live as it works.

​
State

Durable state is first-class, not something you persist by hand. Everything is a bead: a stored work item with status, labels, relationships, and metadata, queried live (bd, gc) — never tracked in status or lock files that go stale on a crash. Sessions come and go; the beads remain.

​
Skills

You author a skill once at a scope, and Gas City materializes it to every eligible agent — no per-agent allow-lists, and the model decides when a skill applies.
  • Pick the scope:
    • skills/<name>/ at pack level → shared with every agent in the city.
    • agents/<role>/skills/<name>/ at role level → only agents of that role (and all its pooled instances). On a name collision, the role-local skill wins.
  • At startup Gas City symlinks the pack level and role level skill directories into each agent’s provider-specific skill sink — .claude/skills/, .agents/skills/ (codex), .gemini/skills/, .opencode/skills/. List with gc skill list.
  • It places the files into each provider’s own convention; it doesn’t translate them. Providers whose convention isn’t confirmed (copilot, cursor, pi, omp) are skipped for now.
  • No framework around skills: no per-agent allow-lists. Within a scope every eligible agent gets every skill; the model decides when one applies.
  • MCP is list-only today (gc mcp list shows what’s catalogued; you wire the servers yourself).

​
History

History is structured and queryable across every agent, not per-session files you manage yourself.

​
Messaging

Agents that share no session still communicate, over two channels.

​
Roles

A role is a folder, not a single subagent file. agents/<name>/ holds an agent.toml (provider, pool, timeouts) and a prompt.template.md defining what that kind of agent does.

​
Identity

A specific running instance has a stable name you can address — across restarts.
  • Each live agent has a deterministic session name (e.g. hello-world/pack.worker_furiosa), so you and other agents can message, wake, peek at, and resume exactly that one.
  • One role instantiates into many identities (a pool of worker_furiosa, worker_nux, …). See them with gc session list.
  • Role (the kind), identity (the running instance), and pool (the set) are all facets of the single Agent primitive — see the six primitives.

​
See also

Last modified on July 28, 2026