Gas City wraps each CLI coding agent in a provider and gives configured agents the same workflow and Beads work contract, so a factory can route different steps to different tools. Claude Code, Codex, and Gemini CLI keep their native behavior. Gas City supplies the factory around them.
The platform had seventeen built-in CLI coding-agent integrations on August 7, 2026. Custom commands extend the same provider boundary beyond the built-in catalog.
The catalog spans Claude Code, Codex, Gemini CLI, Cursor, Copilot, OpenCode, Kiro, Grok, Kimi, Amp, and other agent CLIs. That breadth creates a practical routing surface: the provider starts and resumes the tool, while the configured agent and workflow still define the job.
One work graph, several agent harnesses
In Gas City terminology, a provider is the harness around a CLI coding agent. It defines how Gas City starts the command, delivers a prompt, observes readiness, resumes a session, and passes options such as model or approval mode.
An agent is the customer configuration that uses that harness. Its definition can add a role prompt, project scope, model choice, permissions, skills, and workflow defaults. The imported pack defines the role and formula workflow; the Gas City binary supplies the provider boundary that runs it.
Beads sits below the vendor-specific sessions. A bead records the work, status, ownership, notes, and graph relationships. Each CLI reads or updates that shared contract through the factory workflow instead of inventing its own task universe.
This separation prevents a tool choice from becoming a work-state migration. You can change the harness on a configured agent while the bead IDs, dependencies, and acceptance criteria stay put.
What Gas City makes consistent
The useful common layer is operational.
Every configured agent receives explicit work. Workflow dependencies decide when a step is ready. Project scope tells the session where it may work. Agent definitions and packs provide prompts and supporting assets. The orchestrator can start, stop, and observe the resulting session while Beads preserves the job outside it.
Gas City also materializes pack and role skills into provider-specific locations where support is confirmed. It places the files according to each CLI’s convention; it does not translate one agent’s skill format into another behaviorally equivalent skill.
The coming-from-coding-agents guide maps context, state, skills, history, messaging, roles, and identity into Gas City. The agent configuration guide owns the current harness, model, upstream, transport, and runtime settings.
What remains tool-specific
A common workflow does not make the coding agents identical.
Claude Code, Codex, and Gemini CLI have different permission controls, resume mechanisms, model menus, instruction files, hook lifecycles, and native tools. Their models may also produce different results on the same task. Gas City passes the configured options through the relevant harness; it does not promise behavioral parity.
That is why role routing should begin as a hypothesis. If you suspect one setup is better for a particular refactor or review, test it against the same repo, acceptance criteria, and budget. Record the result before turning the preference into a permanent factory rule.
The agent orchestration evaluation rubric provides a method for that test. This page makes no ranking among the agent CLIs.
Route roles, not brand names
Consider a small compatibility test with two agent definitions:
implementationreceives a bounded code change with a failing acceptance test.reviewreceives the diff, test output, and explicit review criteria.
Configure the first role with one harness and the second with another. Run the workflow. Then switch the harnesses and repeat under the same conditions.
The agent names describe the job. A line in configuration selects Claude Code, Codex, Gemini CLI, or another harness for that job. This keeps the workflow readable and makes the experiment reversible.
For a larger example, planning can produce two independent implementation beads, each routed to a different configured agent. A test step waits for both. Review receives the combined result and ends at a human gate. Coordinate multiple AI coding agents walks through that graph.
Do not route by folklore. “Use tool X for architecture” is a claim that needs evidence from your codebase, prompts, and constraints.
Beads already meets each agent on its own terms
Beads can be used without Gas City. Its maintained integration recipes meet Claude Code, Codex, Gemini CLI, and other tools through the instruction, hook, rules, or skill surface each host supports.
Those integrations establish the durable work contract inside each coding-agent session. Gas City adds routing, repeatable workflows, automations, project scope, and local observation around those sessions. The agent-recognition guide separates clean-project recognition from behavior supplied by each host’s official Beads setup.
Choose the agent at the right layer
There are five independent choices in current Gas City configuration: the CLI harness, model, model-serving upstream, transport, and runtime. Changing one does not require changing all five.
For example, a Codex harness can select a model option and a serving endpoint while the city still runs its sessions locally. A Claude Code agent can use a different permission posture for review than an implementation agent. These are configuration decisions with different security and performance consequences.
The reference architecture shows where the harness and runtime fit around Beads and the repository. An AI software factory in practice shows the same provider boundary inside the public factory the team runs across its repository fleet.
Try two agents before seventeen
Configure two agent definitions in one small workflow. Give them deliberately different steps and clear acceptance criteria. Run the graph, inspect each bead, and compare the result with the harnesses swapped.
Keep the routing rule only if the evidence supports it. Mixed-agent compatibility is valuable because it keeps options open. The factory still has to earn every opinion it encodes.
Related articles
- Coordinate multiple AI coding agents: Put mixed harnesses into one dependency-aware repository workflow.
- Software factory reference architecture: Locate harness, model, transport, runtime, work state, and project scope.
- Test coding-agent recognition of Beads: Compare a clean-project observation with the instructions and current context supplied by official host integrations.
- An AI software factory in practice: See mixed-agent routing inside the public factory the team uses on its repository fleet.