Cards and Augment Intent — a comparison

Cards is most honest on guiding and checking: a persistent, human-readable job object that serves the person re-entering a task and the reviewer judging it against its original intent. Intent is also most honest on guiding, but through active coordination rather than a job-level surface — a living spec and specialist agents cut the steering burden between check-ins, and Intent carries a real fitting-in advantage within one Space that Cards only makes visible. They share the guiding pipe but occupy different layers within it, so they compose rather than compete: Intent orchestrates the work, Cards keeps the job's intent, plan, and attribution intact across sessions.

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. The slowest step sets the ceiling on useful output. Three other things shape the result: how many attempts become accepted work, how much accepted work holds up later, and how much cleanup the workflow creates. This page compares Cards and Augment Intent step by step, without ranking them. In the marketplace ontology, Intent is principally a Control Artifact system (a spec that survives the run) layered on an Execution Mode system (a coordinator that splits one attempt into specialist agents running in parallel waves). Cards is principally a Control Artifact and Memory and Continuity system (a job-level work object that stays readable across sessions). Both touch the Control Artifact layer, but through artifact types built for different roles: Intent's spec drives the agents; Cards' card serves the person re-entering the work and the reviewer judging it.

Cards is a VS Code extension for building with coding agents from plan to commit. For each distinct coding-agent job it keeps one durable work object organized around a description, one or more plans, comments, attachments, the sessions and transcripts the agent produced, the commits that landed, and an attribution map of what the job changed against the current codebase. Actions on the card launch the configured coding tool from that accumulated context. The operator is a professional developer who reads diffs, commits, and plans and already runs their own harness; the unit of work is one card — one bug fix, feature, cleanup, or investigation, named after the job rather than the chat session. Cards does not run the agent — the developer's harness and model provider do that — but the default configuration does direct the work through configurable actions and skills: how a plan is drafted, stress-tested before code is written, checked, and merged. The boundary is execution, not direction.

Augment Intent is a macOS desktop workspace for coordinating multiple coding agents around a spec that stays alive. You describe what you want; a Coordinator uses Augment's Context Engine to analyze the codebase and propose a plan as a spec; you review and approve that plan before any code is written; then Implementor agents run in parallel waves against the spec, with built-in specialist personas — Investigate, Implement, Verify, Critique, Debug, and Code Review — each handling a focused role. A Verifier checks results against the spec to flag inconsistencies, bugs, or missing pieces. Each prompt creates a Space with its own dedicated git branch and worktree, and the spec updates itself as agents complete work. Intent can drive Augment's own agent or external harnesses including Claude Code, Codex, and OpenCode. The operator is a developer comfortable with git and running multiple agents; the unit of work is one Space — a spec-defined, isolated attempt the coordinator breaks into tasks. The cleanest way to hold the difference: Cards keeps the job intelligible from plan to commit; Intent orchestrates the work so multiple agents stay aligned to one spec.

Both products reach for the same rhetorical move: the bottleneck of agent-assisted software has moved off raw production. Intent locates the new bottleneck *upstream* — getting a correct, decomposed spec out of the human before agents run — and solves it with Context-Engine spec drafting and a coordinator. Cards locates it *downstream* — the human understanding what the agent did and whether it still holds — and solves it with a durable job-level work object read after the run. Same sentence, opposite ends of the agent's run. The collision is at the worldview-sentence layer only; the mechanisms do not overlap.

Both make starting more deliberate rather than faster, but automate different parts of the deliberation — Cards through a guided intake interview, Intent through spec drafting and Space setup. Starting means getting an attempt off the ground at all; neither product competes on raw launch speed.

Cards' effect on starting is about seriousness, not throughput. The default intake interview draws a vague idea into a description: what you are trying to do, why, what success looks like, what constraints matter. Fewer vague attempts get past the front door, and the ones that launch are better-formed. The ontology layer is Control Artifact: the description and plan become inspectable artifacts before any code exists. Cards has no answer if the constraint is launching dozens of well-scoped tasks per day.

Intent front-loads structure differently. Describing what you want triggers the Coordinator to read the codebase through the Context Engine, draft a spec, and create an isolated Space with its own branch and worktree — then pause for you to approve the plan before code is written. The ontology layers are Control Artifact (the drafted spec) and Isolation and Boundary (the per-Space worktree created at start). The per-start investment is heavier than Cards' intake because infrastructure and a multi-agent task breakdown are produced up front; it pays off only when the work is large enough to benefit from coordinated parallel execution. Both share the same backfire: the structure is wasted on work that was never going to go wrong — a one-line change needs neither a spec-and-coordinator setup nor a full intake interview.

This is the pipe where both products make their primary, honest claim, and they reach a similar effect through different mechanisms: Cards through a durable job a person re-enters, Intent through a living spec a coordinator keeps agents aligned to. Guiding is the human effort of pointing the agent at the right thing and keeping it pointed there across returns.

Cards lowers the per-attempt cost of guiding by keeping the job context available at every return and relaunch. Come back after a meeting, a day, or a week, and the description, the plan sequence, the comments, the attachments, and the change map are already on disk. You read the card instead of reconstructing the story from chat transcripts, and the next agent session reads the same context instead of needing a long re-explanation. The ontology layer is Memory and Continuity: the card is durable local state that persists independently of any agent session, with a smaller secondary lift — because it is plain files, it is readable on a second monitor or in a terminal without the heavy editor.

Intent lowers guiding cost through the living spec plus the coordinator. The spec serves a similar continuity role to Cards' card — what the work is for, what is done, what is pending — but it auto-updates as agents complete work rather than being maintained by hand, and the Coordinator keeps Implementor agents aligned to it between your check-ins. The ontology layers are Control Artifact (the spec as shared source of truth) and Execution Mode (the coordinator maintaining alignment across parallel agents). Where Cards keeps the job in a surface a person shapes and launches from, Intent's spec and coordinator shape what the agents do, so the human supplies less steering between sessions. That is more automated, and it carries a dependency Cards does not share: the value of that autonomous alignment rests on the coordinator interpreting the spec correctly across many agent turns.

Both products share the same backfire. Neither expands where guiding can happen — no phone app, no shared dashboard, no remote access; Intent runs on one Mac, the card lives on one machine. And both saturate the same scarce resource, human attention. Lowering the per-attempt cost of guiding does not raise the number of attempts one person can meaningfully steer once that person is at capacity, and both make it tempting to run more attempts than there is attention to guide.

This is where the two products diverge most: Cards makes human checking cheaper but automates none of it, while Intent automates spec-compliance checking through agents that share the blind spots of the agents they audit. Checking is whether the work is actually verified before it counts.

Cards has no automated checking mechanism, and makes no claim to one. Its contribution is structural: the reviewer reads the description and plan — written before and during the work, not retrofitted — and compares what was asked against what was produced, using the attribution map to see which parts of the project the change touched. The reviewer does not rebuild context from chat logs; the card supplies the specification. The ontology layer is Memory and Continuity: durable context makes human review cheaper. Cards also adds advisory markers — plan approved, merge approved — that signal readiness without enforcing it. The honest failure mode is rubber-stamping: a reviewer clicks through a marker the agent itself drafted the contents for, the card records that checking happened, and no checking happened. That is worse than no card, and Cards' checking quality depends entirely on a real, independent check sitting behind the marker.

Intent ships two automated checking mechanisms the Coordinator runs alongside implementation: a Verify specialist that checks each agent's output against the spec, and a Code Review specialist that reviews combined changes with severity labels. The ontology layer is Verification and Adjudication: Intent has an automated spec-compliance stage Cards does not have. The complication is that the Verifier draws on the same model ecosystem, the same Context Engine, and the same codebase understanding as the Implementors it audits, so it shares their blind spots. It can confirm code matches the spec's stated requirements; it cannot reliably catch a failure the implementing model would itself miss. This is self-verification, not independent verification, and the product vocabulary — Verify, Verifier — suggests more independence than the architecture delivers. A team with strong independent review practices gets real value from Cards' context support without that illusion; a team that wants automated spec-compliance checking and will manage the correlated-blind-spot risk gets a real capability from Intent that Cards does not offer.

Intent has the structurally stronger claim here: its coordinator actively manages cross-agent dependencies inside one Space, where Cards only makes collisions visible. Fitting in is connecting a finished piece to the larger project without breaking what is already there.

Cards' fitting-in claim is modest, and is awareness, not prevention. The attribution map shows which parts of the project a job has touched, so collisions with other in-flight work surface earlier than at merge time, and the default setup gives each card its own isolated working copy. But Cards does not run merges, manage releases, coordinate dependencies, or resolve conflicts. The ontology layer is the awareness end of Isolation and Boundary: it can show that two pieces of work touch the same files but cannot manage the interaction.

Intent's claim is stronger because the Coordinator actively manages cross-cutting dependencies between specialist agents inside one Space: when one agent modifies the auth service and another modifies the gateway that depends on it, the coordinator manages the handoff, and the shared spec makes the coupling visible before merge. The ontology layers are Isolation and Boundary (the per-Space worktree) plus Execution Mode (coordinator-managed parallel agents). Intent then carries the work from prompt to commit to PR to merge inside the app.

Both share the same high-concurrency limit. File-level isolation within a Space or a card does not prevent merge conflicts between separate Spaces or cards that branched from the same main. As parallel branches multiply, git conflicts become more likely regardless of which tool produced them. Intent's coordinator advantage is confined to within-Space handoffs; it does not extend across Spaces, and neither product predicts cross-branch collisions.

Neither product has anything to claim here, for the same reasons. Approving is a recurring formal authority gate — a separate party who must sign off on each piece of work because of policy, regulation, or organizational rule.

Cards' markers are advisory. There is no approval queue, no role-based access control, no hosted dashboard for an external reviewer, no audit trail built for consumption outside the engineering team. The card lives on the developer's machine. Cards is a work surface, not a control system.

Intent has the same gap. The Coordinator and Verifier are delegation and self-checking mechanisms inside one developer's workflow, not approval gates, and their names suggest more gatekeeping than they perform. There is no compliance dashboard, no role-based authority model, and no way for an outside approver to review a Space without running the app. The ontology layer is Authority, Identity, and Trust, and neither product participates in it. A team whose binding constraint is a recurring authority gate needs a different category of product.

This fraction is how many started attempts survive to acceptance rather than being scrapped, failed, or abandoned.

Cards lifts it two ways. The intake interview keeps vague ideas out of the started pool — they get sharpened or dropped before they consume review effort. And the attached description and plan mean reviewers reject for substantive reasons rather than context loss, so the I-cannot-tell-what-this-was-for rejection disappears.

Intent lifts it through more automated mechanisms: every attempt has an approved spec before any agent starts, the Coordinator breaks the work into concrete verifiable tasks, the Verify specialist catches spec mismatches before human review, and the persistent Space makes a partially completed attempt more likely to be finished than abandoned because re-entry cost is low.

Both share the same counterweight: the ease of starting invites speculative attempts that drag the fraction back down — a vague prompt produces a vague spec, vague agent work, then a rejection at review. Cards' intake interview provides some friction against thoughtless starts; Intent's prompt-to-Space flow is smoother and provides less, so its yield gain depends on the operator using the spec to think before launching rather than clicking through it.

This is durability: whether accepted work is still standing a month later or has been reverted, rewritten, or replaced.

Cards has two mechanisms. The smaller: the why is attached to the work on the card, so a future reader is less likely to revert a change whose rationale is no longer obvious. The larger: the attribution tree is a running projection of cumulative changes against the current state of the project, so anyone can see whether a piece of work is still in place without git archaeology.

Intent's mechanism is the spec preserved in branch history. A developer returning to a merged Space months later can read the spec and understand why the work exists, what constraints applied, what alternatives were considered. But nothing keeps the spec in sync with code changes made outside the Space after merge; it is static from the moment the Space closes. The structural difference is that Cards' attribution tree keeps re-projecting against the current codebase and continues to provide value after merge, while Intent's spec is a fixed historical document that does not update unless someone manually edits it.

Both products reduce some cleanup and create some; the sources differ.

Cards reduces cleanup through dedicated failure-mode-analysis agents in the default setup that catch problems in plans and implementations before they cause downstream work, and through a recoverable on-disk record that makes rescuing stuck work faster. It creates cleanup through the rubber-stamping pattern: false confidence in advisory markers lets half-checked work merge, and someone has to fix it later — often the dominant effect unless real independent checks sit behind the markers.

Intent reduces cleanup through the Coordinator's structured task breakdown (less wasted effort from agents going the wrong direction), per-Space worktrees (agents cannot corrupt each other's changes), and the Verify specialist catching spec mismatches before human review. It creates cleanup through the self-verification pattern: a passing Verifier report shortens human review, and failures hidden in correlated model blind spots merge and surface later as bugs or rewrites.

Both cleanup risks are the same shape — false confidence in a check that is not independent — and both reductions are realized only when a human keeps independent judgment. Neither product reduces the cleanup from the model going in circles, retrying the wrong fix, or compounding errors inside a single session; that is whatever the model produces, and both products act on the human side of the load.

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 — no separate desktop app, no infrastructure to stand up. Trying it costs the time to install the extension and point it at a coding-agent CLI you may already run; Cards does not import anything from Intent, so there's nothing to convert and no Space or spec history 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 Intent can itself drive external harnesses including Claude Code, Codex, and OpenCode, a developer already running Intent's coordinator can add Cards for the sessions it launches directly without giving up Intent's Space-based orchestration for the rest — this isn't a switch, it's an additional layer to try where it fits.

Cards is most honest on the guiding and checking pipes: a persistent, human-readable work object that serves the person re-entering a task and the reviewer judging it against its original intent, with an attribution tree that gives it a durability advantage no orchestration tool matches. It fits the team whose constraint is that work is hard to come back to and hard to verify against what it was for. Intent is also most honest on guiding, but through active alignment rather than a job-level surface — the Coordinator and auto-updating spec cut the steering burden between check-ins, and Intent carries a real fitting-in advantage (coordinator-managed within-Space handoffs) Cards only makes visible. It fits the team whose constraint is keeping multiple specialists coordinated around one approved spec. The two share the guiding pipe but occupy different ontology layers within it, so they compose: Intent orchestrates the work, Cards keeps the job's intent, plan, and attribution intact across sessions — the spec and the card serve different readers and do not conflict.