Cards and Conductor — a comparison

Cards' honest claim is the guiding and checking pipes for one job: it serves the developer re-entering a task and the reviewer evaluating it against what it was for. Conductor's honest claim is the starting and fitting-in pipes across many jobs, with a strong secondary contribution to guiding through its supervision board: it serves the developer launching, tracking, and merging many isolated agent streams. They can be used together without conflict — Conductor to launch, isolate, and watch the parallel work, Cards to shape and keep the record of an individual job.

A companion piece lays out person-and-AI work as a five-step pipeline: starting, guiding, checking, fitting in, and sometimes approving through a real authority gate. The slowest step caps useful output; three more factors shape the result — how many attempts become accepted work, how much holds up later, how much cleanup the workflow creates. This page compares the two pipe by pipe without ranking. In the marketplace ontology, Conductor is a multi-agent control plane with an attention interface (Execution Mode, Isolation/Boundary, Attention/Supervision, Delivery/Integration); Cards is a control artifact and memory/continuity system (Control Artifact, Memory/Continuity). Those layer differences drive every pipe difference below.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized around its description, plans, comments, attachments, sessions, transcripts, commits, changed files, and attribution; actions launch the configured agent from that context. The operator is a professional developer in VS Code who already runs a coding harness and reads diffs, plans, and commits. The unit of work is one card: one job's intent and actual work, held on disk as a local git repository that outlives any session. Cards directs and organizes that one job through configurable actions and skills; it does not run the agent or coordinate a fleet.

Conductor is a Mac desktop application for running a team of coding agents in parallel. Each piece of work becomes a workspace: an isolated git worktree with its own branch, agent session, file tree, and notes. A sidebar shows every workspace's GitHub status at a glance, with metadata on hover, so one developer sees which agents are running, which need attention, and which are ready to review. The operator is a software engineer on a Mac comfortable with Claude Code or Codex, git branches, and the PR lifecycle. The unit of work is one workspace, typically yielding one branch and one PR. The app wraps the lifecycle from workspace creation through diff review, PR creation, and archiving.

In one line: Cards is organized around keeping one job intelligible from plan to commit; Conductor around running and watching many jobs at once.

Conductor's most direct effect lands here. Without it, running several agents means juggling terminal windows, branches, sessions, and a mental map of which goes with which — overhead that often pins a developer to one agent at a time. Conductor collapses that to a click: name a workspace and an agent starts in its own isolated worktree, configured from the repository's instructions, with optional setup through "Files to copy" repo settings. The layer is Execution Mode and Isolation: interactive local execution for many simultaneous agents, each in its own boundary, raising launch rate.

Cards changes starting differently in kind. It does not raise launch speed or count; its default intake interview sharpens a vague idea into a defined description and plan before code, so what reaches the agent is a serious attempt. The layer is Control Artifact: the description and plan become a durable specification that travels with the work. Where Conductor makes it cheap to start more, Cards makes it harder to start something never defined. A team whose binding constraint is launching parallel sessions fast without collisions should look at Conductor; a team whose constraint is too many unscoped starts going nowhere is the Cards case, and Conductor's ease of starting can make that worse by filling the sidebar with under-defined workspaces.

Both lower re-entry cost, through different mechanisms and durability. Conductor preserves live workspace state: switching between workspaces keeps each agent's chat history, running processes, branch, and notes intact, and recent versions add agent Steering — configurable follow-up behavior. The sidebar renders status across every workspace at once, so a developer orients across the whole parallel workload in seconds without opening each one. The layer is Attention/Supervision: session aggregation and a glanceable status board — Conductor's strongest distinct contribution here, one Cards does not match. Cards keeps the persistent record for one job; it has no live mission-control board, and for watching and coordinating many running agents at once Conductor is the tool, not Cards. This is a research boundary, not only a feature split. **Watching a live stream for more than half an hour measurably degrades anyone's accuracy** — a known limit of sustained monitoring, not of any one tool. The two answer different problems: reading a rendered record on your own schedule versus watching the work happen in real time.

Cards preserves the intent of one job rather than the live state of many. The card holds the description written before the agent started, the plan it followed, the comments left along the way, the transcripts it produced, and a map of what changed; returning after a week means reading the card, not reconstructing context from a transcript. The layer is Memory/Continuity: durable local state that persists whether or not any session is active, independent of harness and UI. Conductor's guiding context is bound to the running workspace and narrows to leftover notes once archived; Cards' is bound to the record, which survives compaction, crashes, and handoffs. Both share a limit: neither reduces the fundamental judgment load of directing an agent, and a status board that makes a backlog visible is not the capacity to clear it.

Both make the mechanical act of review cheaper, and both have more complicated stories here than at their headline pipes. Conductor provides a diff viewer with side-by-side comparison, inline comments, and the ability to send feedback back to the agent, plus a Checks view surfacing git status, CI results, PR review threads, and outstanding todos in one place. Cards provides the description and plan written before and during the work, so the reviewer compares what was asked against what was produced, plus the attribution map of which parts of the project were touched. The ontology split is clean: Conductor on Delivery/Integration (CI status, PR threads), Cards on Control Artifact (durable specification). The substance is what the reviewer holds: Cards gives the original intent from the card itself, so whether the change meets the spec is answerable without leaving the work surface, while Conductor gives the diff and CI status but leaves the intent in workspace chat history or the operator's head.

Neither adds an independent verifier. The reviewer is the same person who directed the agent, or a teammate sharing the same tools and assumptions; agent and reviewer often share a model family and its blind spots. Neither ships an evaluation harness, adversarial testing, spec-to-output comparison, or a second agent auditing the first. The Verification and Adjudication layer is absent from both.

Both carry the same rubber-stamping risk. Cards' advisory markers — "plan approved," "ready to merge" — can manufacture the appearance of review where no checking happened; a click on a marker whose contents the agent itself drafted is not verification. Conductor's smooth path from diff to PR can let the ritual of review stand in for its substance. In both, hours counted as real checking are not real checking unless an independent test or careful human sits behind the surface.

This is Conductor's second strongest claim and Cards' most modest one. Conductor's mechanism is workspace isolation: each workspace is a separate git worktree on its own branch, so two agents in different workspaces cannot edit the same file at the same time. In a bare terminal setup, two sessions on one repository share a single working tree and one agent can silently overwrite the other's changes; Conductor eliminates that class of development-time collision at the filesystem level. It also wraps the branch-to-PR lifecycle — open a PR, monitor CI, address comments, merge — and supports cross-repo workspaces so one agent can touch several repositories. The layer is Isolation and Boundary, supported by Delivery/Integration.

Cards has a narrower claim. Its attribution map reveals which parts of the project a job touched, making collisions visible earlier, and its default setup gives each card its own isolated working copy. But Cards does not run merges, manage releases, or coordinate dependencies; its fitting-in help is awareness, not structural prevention. The gap is strategic: worktree isolation is the foundation of Conductor's parallelism model, while collision visibility is a side benefit of Cards' continuity model. A team whose binding constraint is agents stepping on each other's files will find Conductor solves that directly; Cards helps them see collisions coming but does not prevent them. Both share one limit: neither eliminates semantic collisions at merge time — when separate branches converge to main, standard merging applies, and two agents that refactored the same module incompatibly produce a conflict regardless.

Both products have nothing to claim here, for the same structural reason. Approving is a recurring authority gate where a separate party must formally sign off on each piece of work. Cards' markers are advisory: they signal readiness but enforce nothing — no approval queue, no role-based access control, no audit trail for an outside reviewer, no hosted dashboard where a compliance officer logs in. Conductor's merge blockers are also advisory — they alert the operator that checks failed or comments remain open, but do not enforce policy, and the app runs on the developer's own Mac with no shared surface for external reviewers. The layer is Authority, Identity, and Trust, and neither participates in it. A team whose narrowest pipe is a formal sign-off should evaluate a different category of tool entirely.

Cards lifts this fraction two ways. The intake interview keeps vague ideas from becoming started attempts; they are sharpened or dropped before they consume review effort. And the attached description and plan mean reviewers reject for substantive reasons rather than context-loss — the rejection driven by no one remembering why something was built quietly disappears.

Conductor's effect runs in two directions that partly cancel. Plan Mode can filter wrong-direction work before code is written, nudging the fraction up; but the same ease of starting invites speculative workspaces that do not become accepted work by design. On net the effect is unclear and probably small, depending on operator style. One of the clearest structural differences: Cards' core mechanism, a durable object of intent, directly improves the conditions for acceptance, while Conductor's, cheap parallel startup, works against it by increasing speculative attempts. Both claims are internally consistent; they apply to different workflow styles.

Cards has two mechanisms. Keeping the reason for the work on the card means a future reader is less likely to revert a change whose rationale is no longer obvious; and the running map of cumulative changes, projected against the current project state, answers whether the work is still in place with a glance instead of git archaeology. Conductor has one modest mechanism: an archived workspace preserves notes, chat history, and the task description, so a developer revisiting later can restore it and understand what was done — more than a commit message carries. But nothing in Conductor validates that a merged change still works weeks later, and its design introduces a durability failure mode: two workspaces developed independently and merged separately can together create a subtle breakage, while the diff viewer shows one workspace at a time. The contrast tracks the ontology layers: Cards' Memory/Continuity layer is built for state that outlives the agent; Conductor's preserves session state for the operator's reference but is organized around the workspace lifecycle, not long-term project awareness.

Both reduce some cleanup and create some; the sources differ. Cards reduces cleanup through default agents that catch failure modes in plans and implementations before they cause downstream work, and a recoverable on-disk record that speeds rescue when work goes wrong; it creates cleanup through rubber-stamping, where advisory markers manufacture false confidence and half-checked work merges and fails later — usually the dominant effect unless the team wires independent checks behind the markers. Conductor reduces cleanup through worktree isolation and clean teardown (a workspace can be archived or deleted without orphaned files); it creates cleanup through branch proliferation — every workspace is a branch, every unmerged branch is cleanup — and through the semantic merge conflicts independent development invites, which it has no tooling to detect or prevent. Cards' cleanup risk comes from false confidence in its own signals and can be managed with process discipline; Conductor's comes from the volume of objects parallelism creates and is more structural.

Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and runs against your existing local Git repository — it doesn't touch Conductor's Mac app or its workspaces at all. Trying it costs the time to install the extension and point it at a coding-agent CLI you may already run, such as Claude Code or Codex; Cards imports nothing from Conductor's workspace history, so nothing there needs converting. 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 the two run at different layers — a Mac app for launching and watching many parallel workspaces versus an editor extension for one job's record — a developer already running Conductor can open the same repository's card in VS Code for the jobs that need re-entry and review, without changing how Conductor launches the rest.

Cards' honest claim is the guiding and checking pipes for one job, with secondary effects on accepted yield and durability; it serves the developer re-entering a task and the reviewer evaluating it against what it was for. A narrow guiding-and-checking pipe points to Cards first. Conductor's honest claim is the starting and fitting-in pipes across many jobs, with a strong distinct contribution to guiding through its supervision board; it serves the developer launching, tracking, and merging many isolated agent streams without manual terminal juggling. A narrow starting-and-isolation pipe points to Conductor first. They can be used together without conflict — Conductor to launch, isolate, and watch the parallel work, Cards to shape and keep the record of an individual job — because they occupy different ontology layers and answer different questions: which agents are running right now, versus what this work was for and what it still amounts to.