Cards and Google Antigravity — a comparison

Cards' honest claim is guiding and checking — a durable, human-readable work object for the developer re-entering a job after stepping away. Google Antigravity's honest claim is guiding and starting — a Manager Surface for spawning and supervising many agents at once. The two can be used together; which one you need turns on whether your bottleneck is losing context between sessions or keeping track of everything you have running in parallel.

A companion piece lays out person-and-AI 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, and three other things shape the result: how many attempts become accepted work, how much holds up later, and how much cleanup the workflow creates. This page compares Cards and Google Antigravity pipe by pipe without ranking them. In the marketplace ontology, Antigravity is a multi-agent control plane with an attention interface, centered on the Execution Mode and Attention/Supervision layers; Cards is a control artifact and memory/continuity system, centered on the Control Artifact and Memory/Continuity layers. Those classifications predict 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 a description, one or more plans, comments and attachments, sessions and transcripts, commits, changed files, and attribution. Actions launch the configured agent from that job context; the harness and model provider still run the agent. The operator is a professional developer who reads diffs and makes technical decisions, and the unit of work is one coding-agent job — a bug fix, feature, cleanup, or investigation — that may span many sessions and interruptions.

Google Antigravity is a desktop agentic development platform with two surfaces. The Editor Surface is "a state-of-the-art, AI-powered IDE equipped with tab completions and inline commands." The Manager Surface is "a dedicated interface where you can spawn, orchestrate, and observe multiple agents working asynchronously across different workspaces." Its agent reads and writes files, runs terminal commands, and drives a Chrome browser instance, producing artifacts — task lists, code diffs, screenshots, browser recordings — and saving context to a knowledge base, with Claude Sonnet 4.5 and GPT-OSS as model options. The operator is an individual developer, and the unit of work is a task handed to an agent. Cards is organized around keeping one job intelligible from plan to commit; Antigravity is organized around spawning and supervising many tasks at once.

Starting is the act of launching an attempt at all — how many serious pieces of work get underway in a given period.

Antigravity widens starting by removing the friction of running one session at a time. The Manager Surface lets a developer spawn agents across multiple workspaces, let them work asynchronously, then return to see what each produced. The ontology layer is Execution Mode: parallel local agents raise how many attempts can be in motion at once, and this is the explicit design intent of the Manager Surface.

Cards moves a different lever. It does not raise the speed or count of starts. Its default flow opens with an intake interview that draws a vague intent into a written description and plan before the agent touches code. The ontology layer is Control Artifacts: the description and plan become a durable specification that exists before the run. The effect is on the seriousness of each attempt, not the rate of attempts.

The two products sit on opposite sides of the same risk. Antigravity makes it easy to start ten things; whether you have attention to guide and check ten is a separate question it does not answer, and the free preview's model rate limits, not session friction, may become the real ceiling. Cards makes it harder to start something underspecified — helpful for a team whose attempts go nowhere for lack of definition, overhead for a team whose intake is already strong. A developer who cannot get enough attempts running gets more from Antigravity; a developer whose started attempts were never real tasks gets more from Cards.

Guiding is the human work of pointing an agent at the right thing, watching what it produces, and steering it back when it drifts. Both products place their strongest claim here, relieving different bottlenecks.

Antigravity's mechanism is the Manager Surface plus artifacts. Instead of replaying a session, the developer reads what the agent produced — a task list, a diff, screenshots, a walkthrough, a browser recording — and can "leave feedback directly on the Artifact" so the agent incorporates the correction, while the knowledge base carries context forward across tasks. The ontology layer is Attention/Supervision: session aggregation and glanceable progress to stay oriented across many parallel agents and decide which needs attention next. A secondary effect: the Manager Surface works outside a full editing session, converting dead pauses into steerable time, though only on the machine where Antigravity runs.

Cards' mechanism is the card itself, a durable work object of intent that persists across sessions and the harness. When a developer returns after a meeting, weekend, or handoff, the description, plan sequence, comments, attachments, and running change map are already on the card; the picture is read, not reconstructed from a transcript. The ontology layer is Memory/Continuity: durable local state backed by a git repository on disk, readable by the developer and reviewers, surviving compaction, crashes, and tool switches.

The distinction reduces to each product's assumption about the developer's relationship with time. Antigravity assumes switching between tasks in real time, glancing at the Manager Surface to decide which running agent needs a comment now. Cards assumes switching away from a task and returning later, recovering context that would otherwise be lost. Antigravity's help is broader across tasks but shallower per task; Cards' is deeper per task but requires opening the card. Neither removes the underlying judgment load of directing an agent.

Checking is verifying that an agent's output is correct before it counts as accepted work. The two products diverge most here.

Antigravity's checking story rests on artifacts the agent produces about its own work. The product frames this as closing a "Trust Gap": when an agent claims it fixed something, it produces an artifact — a diff, a screenshot, a recorded browser run — as evidence rather than asking the developer to read raw logs. This is genuine communication infrastructure, but it is self-verification: the same model that wrote the code wrote the plan, took the screenshots, and recorded the test. Self-verification only widens the checking pipe when calibrated against independent checks — when human review time falls without escaped defects rising — and Antigravity does not publish calibration evidence of that kind. The browser recording is the most independent artifact because it shows the application running, but a running application is not a correct, secure, or well-structured one. The ontology layer is Verification and Adjudication, where agent and verifier share a model and therefore share blind spots.

Cards makes human review cheaper by handing the reviewer the original intent — the description and plans written before and during the work, not retrofitted — plus the change map showing which parts of the project the work touched. The reviewer answers "does this meet the spec, and what else does it affect?" from the card rather than from chat archaeology. Cards provides no independent verifier either. Its workflow markers — "plan approved," "merge approved" — are advisory, which creates a rubber-stamping risk that has to be named plainly: a reviewer can click "approved" without doing any real checking, and the marker will say checking happened when it did not. Cards is explicit that real independent checks (tests, careful human review, evaluation systems) must sit behind the markers, or the card makes work look checked while leaving it unchecked, which is worse than no marker.

Both products lack an independent verifier on the Verification and Adjudication layer and both rely on a human. Cards lowers review cost by preserving intent and is transparent that its markers prove nothing. Antigravity lowers review cost by producing summaries, and the specific hazard is that those summaries can feel more like verification than they are, because the agent produced them to document its own work.

Fitting in is merging a finished piece into the larger project without breaking what is already there. Both products have modest claims here.

Cards lowers cost per piece in two narrow ways: the running change map surfaces collisions with other in-flight work earlier than merge time, and the default setup gives each card its own isolated working copy so two jobs in flight do not stomp on each other. Cards does not run merges, manage releases, or coordinate dependencies; that capacity is whatever it was before. It touches Delivery/Integration only through Isolation, not merge orchestration.

Antigravity has little to claim here directly. It organizes work into workspaces, the Editor Surface includes a changes-review panel, and it connects external tools through protocol integration; Google states agent-to-agent protocol support was strengthened in a May 2026 release — none of which addresses merging, conflict resolution, or release coordination. Because the product actively encourages many parallel agents, it can create a fitting-in problem that did not previously exist: multiple agents producing changes in the same workspace will eventually collide, and Antigravity has no mechanism to detect or resolve agent-against-agent conflicts. Cards' isolated working copy per card is a partial buffer that Antigravity's shared-workspace model does not provide. Neither product helps a team whose integration bottleneck is release coordination, slow builds, or customer migration.

Approving here means a real, recurring authority gate — a separate party who must formally sign off on each piece of work because policy, regulation, or organizational rule requires it. This is distinct from the one-time decision to permit an agent at all.

Cards declines this pipe by design. Its markers are advisory and enforce nothing, with one narrow exception treated as a real rule for the final merge marker. There is no approval queue, no role-based access control, no audit trail for an outside reviewer, no hosted dashboard; the card lives on the developer's machine, with nowhere for a compliance officer to log in. Cards is a work surface for building with agents, not a control system for who may do the work.

Antigravity has agent-level controls but not organizational approval gates. Google states its April 2026 release introduced a Unified Permission System governing what an agent may do on the machine, alongside secure-mode and sandboxing guardrails, and describes its 2026 enterprise work as moving toward workspace tenant support and audit-log export. These constrain agent behavior but are not recurring per-task sign-off by an outside authority; as shipped to the individual developer in public preview, there is no enforced per-task approval queue. Both products reach the same outcome here: a team whose binding constraint is formal per-task approval is helped by neither today, though Antigravity's enterprise direction is the one moving toward that territory.

Cards lifts this fraction through two mechanisms. The intake interview keeps vague ideas out of the started pool — they are sharpened or dropped before they become code. And because the description and plan travel with the work, reviewers reject for substantive reasons rather than because context was lost between sessions, so the common "no idea why this was built this way, send it back" rejection disappears.

Antigravity's effect is more mixed. The knowledge base reduces repeated mistakes over time, and feedback left on an early artifact catches some failures before they consume a full task cycle. But parallel tasks pull the other way: starting ten tasks while having attention to steer five means the other five are likely to miss the mark. Cards' intake filter raises the quality of what gets started; Antigravity's Manager Surface raises the quantity. A developer whose acceptance problem is underspecified attempts gets more from Cards; a developer who cannot run enough attempts to find the good ones gets more from Antigravity, provided the attention to finish them exists.

Both products support durability through different mechanisms, and neither actively tracks whether accepted work is still valid.

Cards keeps the why attached to the work, so a later reader is less likely to undo a change whose rationale is no longer obvious. The running change map, projected against the current project state, answers "is this piece of work still in place?" with a glance instead of git forensics, and the aggregate is project-aware: the map combines all cards against the live codebase. A residual risk is that a once-correct plan can outlive its assumptions; Cards has signals to re-confirm a stale plan but cannot force a team to heed them.

Antigravity's durability rests on the knowledge base and the artifact record. The knowledge base persists conventions across tasks, so future work is less likely to contradict an established decision, and the artifact trail lets someone later understand why decisions were made. The store is passive and per-task: it retains what was learned but does not check whether earlier work is still true, and there is no aggregate picture of project coherence. For a solo developer, durability is often not the binding constraint; in a team setting maintained by someone outside the original decisions, the artifact record helps but the absence of staleness detection bounds the benefit.

Both products reduce some cleanup and create some, and the sources of the increase differ.

Cards reduces cleanup through default failure-mode agents that look for problems in plans and implementations before they cause downstream work, and through a recoverable on-disk record that makes rescuing stuck work faster. It increases cleanup through the rubber-stamping pattern: advisory markers create false confidence, half-checked work merges, someone fixes it later. In real use this increase is usually the dominant effect unless real independent checks sit behind the markers.

Antigravity reduces cleanup through early feedback on artifacts, the permission system preventing unauthorized actions, and the knowledge base reducing repeated mistakes. It increases cleanup through the self-verification problem — artifacts making output look verified, so checks are skipped — and parallel-agent collision, where agents in the same codebase undo or conflict with each other's work. The risks reflect different scale assumptions: Cards assumes a modest number of well-defined attempts, and its risk is false confidence in its own signals, manageable through process discipline; Antigravity assumes many parallel attempts, and its risk is structural and grows with agent count.

Cards' honest claim is the guiding and checking pipes. Its durable, human-readable work object serves the developer re-entering a job after stepping away and the reviewer evaluating a result without reconstructing context — the constraint is context depth, and Antigravity is honestly better at running and supervising many tasks at once than Cards is or tries to be. Antigravity's honest claim is the guiding and starting pipes. Its Manager Surface serves the developer who needs to keep many agents running and stay oriented across them from one screen — the constraint is attention span across parallel work. They can be used together: Antigravity to spawn and supervise the running, Cards to hold the durable record of a job that has to survive the session and a reviewer. The question is not which is better but which pipe is narrowest in your workflow right now — losing context every time you return to a task, or being unable to keep track of every agent you have running.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Antigravity or migrate anything out of it. Cards runs on your existing local Git repository with no daemon, no account, and no code uploaded to a new service; card data lives locally at `~/.cards/cards-repos/<card-id>/`, alongside your repository rather than inside it, so there is nothing to import from Antigravity and nothing Antigravity produced that has to be rebuilt to use Cards. Uninstalling Cards removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program — the honest version is that trying Cards costs an install and undoing it costs an uninstall, and Antigravity keeps doing whatever it already does in the meantime.