Cards and GitHub Copilot — a comparison

Copilot's honest claim is on starting and guiding: it lets a developer begin more work across editor, CLI, and cloud and reduces how much steering each attempt consumes during execution. Cards' honest claim is on guiding and checking: it lowers the cost of re-entering a piece of work and reviewing it against its original intent. A team whose constraint is initiating enough candidate work or keeping agents on track during a session is in Copilot's category; a team whose constraint is that work loses its thread between sessions and review is expensive because intent was never durable is in Cards' category. They are not substitutes and can be used together — Cards scopes and preserves the job, Copilot's agent runs it.

The companion piece to the formula notes lays out a way of looking at person-and-agent work as a five-step pipeline: starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate. The slowest step sets the ceiling on useful output. This page compares Cards and GitHub Copilot pipe by pipe; it does not rank them. In the ontology of agent control systems, Copilot is classified primarily as an interactive agent workbench and background delegation engine with a unified attention interface, spanning the execution mode, harness and runtime mediation, attention and supervision, and delivery and integration layers. Cards is classified as a control artifact and memory and continuity system, spanning the control artifact, memory and continuity, and isolation and boundary layers.

Cards is a VS Code extension for building with coding agents from plan to commit. For one coding-agent job — a bug fix, a feature, an investigation — it keeps the work organized inside VS Code: a written description of what the work is for, one or more plans, comments and attachments, the sessions and transcripts the agent produced, the commits that landed, and a running map of which parts of the project the work touched. That work object is a card. The operator is a professional developer who reads diffs, plans, and commits; the unit of work is one coding-agent job that begins as intent and ends, if it succeeds, as a merged change. Cards does not execute the agent — the harness the developer already runs and the model behind it call the model, edit files, and run commands. But Cards is not a passive notebook either: its default configuration ships actions and skills that direct how the plan forms, how it is stress-tested, how the change is checked, and how it merges. The boundary is execution, not direction.

GitHub Copilot is an AI capability embedded in the tools a developer already uses — the editor, the terminal, the pull request page on github.com. It suggests code inline as the developer types; in agent mode it plans a multi-step approach, edits files across a project, runs commands, tests, and corrects its own errors; on github.com it reviews open pull requests; on the command line it interprets natural-language workflows and, with the `/fleet` command, splits an objective into independent subtasks dispatched to parallel subagents. Cloud agents run in their own development environment and open a pull request, now startable through an Agent tasks REST API. The operator is the same developer; the unit of work is one attempt that begins as a request or a branch and ends as a merged pull request. Copilot is organized around running the work across many surfaces. Cards is organized around keeping one job intelligible from plan to commit.

Copilot's cost of each additional start is low and attempt volume is high; Cards trades volume for quality at the point of starting — how many attempts a developer can launch and how much friction each launch carries.

Copilot's most visible effect is here. Agent mode turns a natural-language description into a plan, an implementation, and a pull request without the developer keystroking scaffolding. Inline completions accelerate line-by-line writing. The CLI translates terminal intent into executed workflows, and `/fleet` fans one objective out into several subagents working in parallel against a shared filesystem. Cloud agents can be assigned from a GitHub issue or kicked off through the REST API and produce a PR autonomously while the developer works elsewhere. The cost of each additional start is low and the number of attempts in motion is high. The ontology layer is execution mode: Copilot defines interactive local, background local, and remote cloud modes and lets attempts begin cheaply in any of them.

Cards approaches starting through seriousness, not speed. When a developer begins work, the default `interview` action runs a short intake that produces a written description and plan before any code is written. The effect is on the quality of each start: vague ideas get sharpened or dropped at the front door, and because the card holds the context for each one, a modest number of well-formed attempts can stay in flight without the developer losing the thread. The ontology layer is control artifact: the card is the durable plan-and-intent object that exists before execution. Cards does not raise the raw rate at which sessions launch, and it does not replicate Copilot's parallel cloud or `/fleet` concurrency.

These mechanisms answer different constraints. If the bottleneck is that the developer can describe work faster than it can be written, Copilot's frictionless multi-surface starting is the relevant intervention. If the bottleneck is that started attempts are too vague and fail downstream because nothing pinned down what was wanted, the intake interview is the relevant one. They can run in sequence — scope the work on the card, then launch Copilot's agent against it — but whether that helps depends on which of the two problems is binding.

Copilot reduces the steering cost within a session; Cards reduces it across sessions — both cut the human effort of pointing the agent at the right thing and keeping it pointed there.

Copilot reduces the steering cost a single attempt consumes during a session. The Plan agent structures open-ended work before a line of code is written, so the developer approves an approach rather than directing each step. Agent mode self-corrects: when a test fails, it reads the error, traces a cause, and applies a fix without the developer catching the failure by hand. Custom agents defined in `.agent.md` files — including a global `~/.copilot/agents` scope as of May 2026 — and sub-agents encode conventions and specialized roles once instead of per session. The Ask question tool lets an agent pause for a focused clarifying question rather than guessing when intent is ambiguous. A unified sessions view tracks every session — title, agent type, elapsed time, status — so a developer steering several at once can see which needs attention. The ontology layers are harness and runtime mediation, where the planning and self-correction live, and attention and supervision, where the session list keeps the developer oriented across concurrent work.

Cards reduces the steering cost an attempt consumes across sessions. When the developer returns after a meeting, a context switch, or a week away, the card already holds the description, the plan sequence, the comments, the session transcripts, and the map of changes. The developer reads the context instead of reconstructing it from chat logs; the agent opening a new session is launched from the card and needs no long re-explanation; the reviewer who needs to know why a decision was made reads the card rather than asking the person who made it. The ontology layers are control artifact and memory and continuity: the card carries intent across time and is the developer's primary reading surface, not the agent's working memory.

The two effects are additive, not competing. Copilot makes the active session cheaper to steer; Cards makes the next return to the work cheaper. The risk is also additive: both make it easy to accumulate many in-progress attempts, and each still demands steering attention at review and re-entry even when each such moment costs less. Cards earns its keep specifically in the re-entry case; for a small task done in one continuous session, most of what it does for guiding is wasted.

Copilot automates a first pass with a reviewer that shares blind spots with the coder; Cards makes the human's own check cheaper without automating the judgment — both touch deciding whether what the agent produced is actually correct and actually what was asked.

Copilot adds an automated reviewer to pull requests on github.com, leaving inline comments and suggested changes in well under a minute, and in agent mode runs tests after implementing and iterates on failures before showing the result. But the reviewer and the generator draw on the same model families and share blind spots — a test the agent writes to verify its own code tends to miss the same categories of failure its coding logic tends toward. By design, Copilot code review always leaves a Comment review, never an Approve or a Request changes; it does not count toward required approvals and does not block a merge on a protected branch. It does not automatically re-review after new commits and can repeat dismissed comments. These are structural constraints, not gaps waiting to be patched. The ontology layer is verification and adjudication: Copilot automates a first pass with a model that shares distribution with the coder.

Cards makes the checking that humans do cheaper without automating the judgment. Instead of reconstructing what a change was supposed to do, the reviewer reads the description and plan written before the work started; instead of tracing which files moved, the reviewer reads the running change map; instead of scrolling a transcript to recover why a decision was made, the reviewer reads the card. Per-candidate checking cost falls because context-reconstruction time falls. The ontology layer is memory and continuity feeding human verification: the substance of the review is still entirely on the human.

Both products carry the same rubber-stamping risk, named plainly. With Copilot, a developer who sees that the AI reviewed a PR and the comments look reasonable may merge without the substantive human review the work needed — the appearance of verification substituting for verification. With Cards, the advisory markers ("plan approved", "ready to merge") enforce nothing, and a reviewer who clicks through without checking the substance produces a record that says reviewing happened when it did not. Neither product provides independent verification. A team using either must keep a checking discipline not driven by the same models that produced the code — careful human review, independently written tests, or an outside evaluation system — or both will make work look checked without it being checked.

Copilot reduces handoff friction by routing output straight into the PR workflow; Cards reduces collision risk by making overlapping work visible — both touch merging a finished piece into the larger project without breaking what is already there.

Copilot reduces handoff friction by creating pull requests automatically from cloud agent sessions, so output flows into the existing delivery workflow without a manual branch-and-PR step, and the Agent tasks REST API lets that path be triggered programmatically. The Plan agent surfaces dependencies and affected areas before implementation, reducing surprises at merge time, and a single agent session produces a coherent set of edits rather than scattered ones. The ontology layer is delivery and integration — PR-centric integration with early dependency signaling.

Cards reduces collision risk by making overlapping work visible. The running change map shows which parts of the project each card touches, so two in-flight cards heading for the same files are visible before merge, and default per-job worktree isolation keeps them from overwriting each other. The ontology layer is isolation and boundary — code isolation via worktrees, context isolation via separate cards.

Neither product resolves merge conflicts, coordinates cross-team dependencies, manages release handoffs, or addresses build systems, deployment sequencing, or rollback. Both share a concurrency warning: at a modest number of parallel pieces their integration mechanisms help, but `/fleet` subagents share a filesystem without talking to each other, Copilot offers no coordination between parallel sessions, and Cards' change map cannot keep pace beyond a threshold either. Gains from a few simultaneous pieces should not be extrapolated to dozens without measuring again.

Neither product has anything meaningful to claim on approving — a real authority gate where a separate party must formally sign off on each piece of work because of policy, regulation, or organizational rule. Copilot's code review leaves Comment reviews and never approves or blocks a merge; enterprise administrators set policies and manage access, but those control who may use the tool, not whether a given piece of work is approved — adoption gates, not per-work gates. Cards' workflow markers look like approval steps to a casual reader but enforce nothing at the system level, with one narrow exception for the final merge marker. The ontology layer is authority, identity, and trust, and both stay in the operator-approval subtype: the developer decides what ships. Neither enforces organization-governed authority, policy-bound approval, or per-candidate compliance routing. For a team whose binding constraint is a recurring authority gate, neither widens that pipe.

Copilot pushes this fraction both ways. The Plan agent catches wrong approaches early, agent-mode self-verification catches some failures before review, and the Ask question tool reduces ambiguity that would cause rejection. Pulling the other way, plausible-but-wrong code passes review more easily than clearly wrong code, and reviewer fatigue compounds when every PR arrives full of generated code. The net is not vendor-published; it has to be measured per team. Cards raises the fraction differently: the intake interview keeps vague ideas out of the started pool, and the description and plan attached to the work mean reviewers reject for substance rather than for context loss — the "no idea why this was built this way, send it back" rejection common when context vanishes between sessions disappears. That gain is conditional: if rejections are driven by code quality, requirements changes, or business decisions, neither product moves them.

Work that merges and is reverted a month later was not really finished. Copilot's smaller positive effect is that security and test checks catch a class of failure before it ships; its larger concern is subtle integration assumptions — error handling, data formats, race conditions — that the agent's own tests share its blind spots about and miss until after deployment. Cards' contribution is on the human side: keeping the why attached to the work means a later reader is less likely to undo it for the wrong reason, and the change map projected against the current codebase turns "is this still in place a month later?" from forensic work into a glance. Cards' own risk is a once-correct plan that lingers after its assumptions stop being true; the system has signals to re-confirm a plan, but ignoring them is a process problem the tool cannot fix. Neither vendor publishes reversion data; durability is something to verify, not assume.

Copilot reduces short-loop cleanup — its self-correction loop automates rework a developer would otherwise do by hand, and review and security checks catch issues before merge — while likely increasing long-loop cleanup, since subtle wrong output that survives the agent's own tests is harder to trace because the developer did not write it, and autonomous retries of a failing approach compound rather than resolve. Cards has real cleanup-reducing mechanisms: default agents that look for failure modes in plans and implementations before they cause downstream work, and an intact on-disk history that makes rescuing a stuck piece faster. But its dominant cleanup effect in careless use is an increase: the rubber-stamping pattern merges half-checked work that fails later and has to be fixed. Cards reduces cleanup only when the team wires real independent checks behind the markers; without that, the false confidence the markers create costs more cleanup than no markers would. Neither product reduces cleanup that comes from the agent going in circles inside a single session — that is the agent's own behavior.

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, 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 Copilot, so there's nothing to convert and no Copilot session, custom agent config, or cloud task 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 Copilot is embedded across the editor, CLI, and github.com, a developer already using Copilot can add Cards for the jobs where re-entry and review are the bottleneck without giving up any of Copilot's inline completions, agent mode, or cloud agents — this isn't a switch, it's an additional layer.

Copilot's honest claim is on starting and guiding: it lets a developer begin more work across editor, CLI, and cloud and reduces how much steering each attempt consumes during execution. Cards' honest claim is on guiding and checking: it lowers the cost of re-entering a piece of work and reviewing it against its original intent. A team whose constraint is initiating enough candidate work or keeping agents on track during a session is in Copilot's category; a team whose constraint is that work loses its thread between sessions and review is expensive because intent was never durable is in Cards' category. They are not substitutes and can be used together — Cards scopes and preserves the job, Copilot's agent runs it — but a team whose real constraint is independent verification, integration at scale, or a formal approval gate should expect neither to widen that pipe.