Cards and Gas City — a comparison

Cards' honest claim is on guiding and checking one job: making each return and each review cheaper and better informed. Gas City's honest claim is on starting: generating many attempts in parallel through declarative orchestration. Cards matches a team whose slowest step is guiding or checking individual attempts and that loses context between sessions; Gas City matches a team whose slowest step is starting enough attempts and that has the technical capability to configure a declarative multi-agent system. They do not conflict and can be used together — Gas City to raise volume, Cards to keep one shaped job legible.

A companion piece lays out a way of thinking about person-and-agent work as a pipeline with five steps: starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate. Two other documents apply that pipeline to specific products, one for Cards and one for Gas City. This page is the comparison. It walks each step and states, in plain terms, what Cards does, what Gas City does, where they overlap, where they diverge, and which constraint each one fits. It does not rank them. In the marketplace ontology, Cards is primarily a control-artifact and memory-and-continuity system organized around a single job; Gas City is primarily a multi-agent control plane spanning the execution-mode, harness-mediation, and verification-and-adjudication layers.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized around a description, plans, comments, attachments, sessions, transcripts, commits, changed files, and attribution. Actions launch the configured coding agent from that job context; the harness and model provider still run the agent. The operator is a developer working inside an editor on one job at a time. The unit of work is a card: a durable, human-readable work object on disk, backed by a local git repository, named after the job rather than the chat session.

Gas City is an open-source toolkit for agent orchestration: a supervisor plane that runs declared teams of collaborating agents in arbitrary topologies. The operator writes a `city.toml`, registers project directories as rigs, composes agent teams from building blocks called packs, encodes recurring workflows as version-controlled formulas, and lets a controller-and-supervisor loop reconcile desired state to running state. The operator is a developer comfortable with configuration files, CLI commands, and many concurrent terminal sessions — Steve Yegge frames the human role as shepherds, tending flocks of agents. The unit of work is a bead: a tracked work item in a Dolt-backed versioned database, with an ID, status, dependencies, and a full commit history. Cards is organized around keeping one job intelligible from plan to commit. Gas City is organized around running many agents at high concurrency.

Cards improves the quality of each start; Gas City improves the quantity of starts — the two products move opposite levers on getting a serious attempt underway at all.

Cards changes what counts as a serious attempt rather than how many can launch. The default intake interview walks the developer through what they are trying to do, why, and what success looks like before any agent runs, so the description and at least one plan are on the card before launch. Fewer vague ideas reach the agent; the ones that do are scoped well enough to survive the rest of the pipeline. The ontology layer is Control Artifact: Cards turns intent into a durable plan artifact before execution. What Cards does not do is raise the rate or count of attempts. If the constraint is "we cannot run enough agent sessions at once," Cards has no mechanism for that.

Gas City raises volume directly. The operator declares the desired topology once, and the controller loop continuously starts agents and routes work to them, restarting any process that dies. High concurrency is the default assumption — hundreds of concurrent workers is an explicit design target, and a single-agent deployment is actively discouraged. The ontology layer is Execution Mode: Gas City spans interactive local, background, container, and Kubernetes execution through tmux, subprocess, exec, ACP, and Kubernetes runtime providers. What Gas City does not do is make each attempt better formed before it launches. Pointed at vague work, it starts more of it.

The contrast is structural and not in conflict. Cards improves the quality of each start; Gas City improves the quantity of starts. A team could run many agents under Gas City and use Cards to keep one shaped job legible, but they answer different constraints. A team blocked by "we cannot run enough agents" feels Gas City immediately. A team blocked by "too many started attempts go nowhere" feels Cards instead.

Cards reduces the cost of re-entering one specific job; Gas City reduces the cost of configuring many jobs so each needs less steering — both lower the running human cost of pointing an agent at the right thing and keeping it pointed there across interruptions, through different substrates.

Cards lowers the per-attempt cost by making context reconstructable. When the developer returns after a meeting, a weekend, or a handoff, the card already holds the description, the plan sequence, comments, attachments, prior transcripts, and the map of what changed. The developer reads the context instead of rebuilding it from chat transcripts; the agent in the next session reads it instead of being re-explained. The ontology layer is Memory and Continuity: Cards provides durable local state that persists independently of any agent session. The effect is strongest on re-entry and weakest on short tasks finished in one sitting. A secondary, smaller effect: because cards are ordinary files, the developer can glance at one in a second window without opening the heavy editor — same machine only, no phone or shared dashboard.

Gas City lowers the per-attempt cost by codifying intent up front. Formulas encode reusable, forkable workflow templates; packs bundle whole agent-team configurations; rigs scope behavior per project. An agent that Gas City starts already knows its role and constraints, so it does not need a fresh explanation each session, and the bead's commit history records what was tried and what is still pending. The ontology layer is Harness and Runtime Mediation: the configuration system and supervisor loop define how the agent loop behaves before it runs.

Both reduce the per-attempt burden through different substrates. Cards reduces the cost of re-entering one specific job; its benefit grows with the number of returns to the same work. Gas City reduces the cost of configuring many jobs so they need less steering; its benefit grows with the number of agents running in parallel. Neither expands the operator's total attention. Cards still requires the developer to come back. Gas City can run more agents than one developer can actively supervise, and answers that gap with agent-on-agent review — a different tradeoff, not a free expansion of attention. Cards directs one job through configurable actions and skills; it does not run a high-concurrency swarm, and it should not be read as competing with Gas City on parallel execution.

Cards places the check with a human reviewer; Gas City builds it into the deployment topology as agent-on-agent review — the two products place verification of whether produced work is actually correct in different places.

Cards makes human checking cheaper by giving the reviewer context. The description and plans were written before and during the work, so the reviewer can judge the result against the original intent without reconstructing it. The attribution tree projects the job's cumulative changes against the current codebase, so side effects are visible at a glance. The reviewer still reads the diff, runs the tests, and forms the judgment; Cards makes that judgment faster and better informed. The ontology layer is the human-verification subtype of Verification and Adjudication: the reviewer is a person, and Cards improves that person's information.

Gas City makes checking architectural by building it into the deployment topology. The minimum viable setup is two to three agents reviewing each other's output; by catching each other's mistakes, the agent group reaches a more reliable consensus than a single agent. Reliability is presented explicitly as a dial — more rounds of review, more backstops, more judges — that teams turn up for confidence or down for speed. The ontology layer is the reviewer-agent-verification subtype: the check is performed by other agents, and the human inspects the Dolt audit trail afterward.

Both approaches risk rubber-stamping, but the failure modes differ. Cards' risk is human: its workflow markers (plan approved, ready to merge) are advisory and unenforced, so a reviewer can click them without reading the substance, and the marker then says reviewing happened when it did not. This is the most dangerous trap in Cards, and it is named here plainly: a marker is not a check. Real, independent verification — a careful human, an independent test, an outside system — has to sit behind the markers, or the card makes work look checked while leaving it unchecked. Gas City's risk is correlated: reviewer agents that share a model with the producing agents share blind spots and can confidently agree on a wrong answer. A team with trusted but slow human review gets more from Cards; a team with no review capacity gets some checking from Gas City but should not mistake agent agreement for independent verification. The two can layer: Gas City's adversarial review filters early, and Cards makes human review of the survivors cheaper.

Cards' visibility is code-level and cumulative; Gas City's is runtime-level and topological — both have modest, differently shaped claims on connecting a finished piece into the larger project without breaking it.

Cards provides project-scoped visibility through the attribution tree, a cumulative file-by-file projection of the card's contributions against the current codebase, so collisions with other in-flight work surface before merge time. The default setup gives each card its own isolated working copy, so two cards in flight do not stomp on each other at the file level. The ontology layer is Isolation and Boundary at the code level, plus Memory and Continuity for the cumulative projection.

Gas City provides orchestration-scoped visibility through the Dolt-backed bead graph, which tracks dependencies between beads and the state of each work item, and runtime isolation across its providers (tmux panes, subprocesses, Kubernetes namespaces) so parallel executions do not interfere at the process level. The ontology layer is Isolation and Boundary at the runtime level.

Neither product manages code merges, dependency coordination, or release pipelines; those live in the repository and delivery system. The emphasis differs: Cards' attribution tree is cumulative and intent-anchored for one job; Gas City's bead graph is transactional and topological across many. The high-concurrency integration risk belongs to Gas City — raising parallel attempts raises collision cost, and the bead database records collisions after the fact rather than preventing them. Cards is not designed to detect collisions across many parallel cards the way a merge tool would; Cards directs one job, not a swarm, so the comparison here is not about which scales parallel integration better.

Neither product has a claim here — approving is a separate authority's recurring formal sign-off, required by policy, regulation, or organizational rule on each piece of work. Cards' markers are advisory and live on the developer's machine; there is no approval queue, no role-based access control, no compliance dashboard, no place for a separate approver to log in. The one narrow exception is that the final merge marker is treated as a real rule by the system, but that is a local guard, not an authority gate. Gas City records every action as a versioned commit, which could feed compliance review, but it provides no approval queue, role-based access control, or hosted gate either. Both treat approval as outside their scope — Cards because it is a work surface, Gas City because it is an orchestration toolkit. A team whose binding constraint is a recurring approval requirement will not find the answer in either.

Cards raises the accepted fraction by filtering vague ideas at the intake interview and by removing context-loss rejections — reviewers reject for substantive reasons rather than for not knowing why the work was built. This is conditional: if rejections are driven by code quality, requirements changes, or business decisions, none of which is context loss, Cards does not move them. Gas City raises the fraction by encoding proven patterns in formulas and catching failures mid-execution through adversarial review. Both effects are real but pull against parallelism: Cards tolerates a few simultaneous cards and warns against extrapolating to high concurrency; Gas City is built for high concurrency and accepts that work which looks correct in isolation can conflict when combined, so the net depends on whether formula quality and review outweigh collision cost.

Cards improves durability by keeping the rationale attached to the job, so later readers do not delete code for the wrong reason, and by letting the attribution tree answer "is this contribution still in place a month later?" with a glance rather than forensic history-digging. A stale-but-once-correct plan remains a risk the card flags but cannot enforce against. Gas City improves durability by recording every agent action as a commit with a diff and timestamp in Dolt, preserving the full decision trail. Both preserve history — Cards' history is human-readable and intent-structured; Gas City's is machine-verifiable and execution-structured. Neither guarantees the change itself holds up: durability of the record is not durability of the code.

Cards reduces cleanup through default failure-mode-analysis agents that catch problems before they compound and through cheaper rescue when the history is intact. Its dominant counter-movement is the rubber-stamping pattern from the checking step: advisory markers create false confidence, half-checked work merges and fails later, and the cleanup created can exceed the cleanup avoided unless real independent checks sit behind the markers. Cards' cleanup risk is human. Gas City reduces cleanup through convergence loops — bounded iterative refinement that drives agents toward a declared goal rather than wandering — and through mid-execution adversarial review. Its dominant counter-movement is systemic: conflicts between parallel agents, investigation of noisy review findings, and the coordination overhead of many running agents. Gas City's cleanup risk is systemic, and it grows with concurrency. A team running both inherits both risk profiles.

Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and runs entirely against your existing local Git repository — no daemon, no database beyond what's already local, nothing uploaded to a hosted service. Trying it costs the time it takes to install the extension and point it at a coding-agent CLI you may already run, such as Claude Code or Codex; Cards does not import or migrate anything from Gas City, so there's nothing to convert and no `city.toml`, rig, or bead is affected either way. Reversing the trial is just as cheap: a card is a plain folder in a local git repository under `~/.cards/cards-repos/`, so removing the extension and deleting that directory returns the project to exactly where it was. Because Gas City runs as a separate orchestration layer across terminals and infrastructure, a developer already running a Gas City deployment can add Cards for the individual jobs where re-entry and review are the bottleneck, without changing the declared topology or touching a single rig — this isn't a switch, it's an additional layer.

Cards' honest claim is on guiding and checking one job: making each return and each review cheaper and better informed, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. Gas City's honest claim is on starting: generating many attempts in parallel through declarative orchestration, with secondary effects on guiding, checking, durability, and cleanup that exist mainly to make high generation rates workable. Cards matches a team whose slowest step is guiding or checking individual attempts and that loses context between sessions. Gas City matches a team whose slowest step is starting enough attempts and that has the technical capability to configure a declarative multi-agent system. They do not conflict and can be used together — Gas City to raise volume, Cards to keep one shaped job legible — but most teams have one pipe markedly narrower than the rest, and the honest move is to find that pipe before choosing either.