Cards and Google Jules — a comparison

Jules's honest claim is starting — hosted, managed execution that runs many tasks while the developer does other things, for a team whose binding constraint is raw coding throughput. Cards' honest claim is guiding and checking — keeping one coding-agent job intelligible from plan to commit, for a team whose binding constraint is the cost of re-entering and verifying agent output. They sit on different ontology layers and can be run together.

A companion piece lays out a way of thinking about 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 output, and three further 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 walks Cards and Google Jules through that pipeline step by step. It does not rank them. It states what each does at each step, where they overlap, where they diverge, and which team constraint each is built for.

In the marketplace ontology the two sit on different primary layers. Jules is a Managed Agent Infrastructure product: remote, long-running execution on the Execution Mode layer, paired with PR-centric work on the Delivery and Integration layer. Cards is a Control Artifact and Memory/Continuity product: a durable per-job record that persists independently of any agent session. Those layer differences drive every contrast 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, plans, comments, attachments, sessions, transcripts, commits, changed files, and attribution; actions launch the configured agent from that job context. The operator is a professional developer who reads diffs and makes technical decisions; the unit of work is one coding-agent job — a bug fix, feature, cleanup, or investigation — held as a local git repository on disk. Cards does not run the agent: the coding tool the developer already uses and the model behind it call the model, edit files, and run commands. But Cards is not a passive notebook either — in its default configuration it ships actions and skills that direct how a plan is drafted, stress-tested, implemented, and merged. The boundary is execution, not direction: Cards directs and organizes the work; the harness and model provider run it.

Jules is a cloud-hosted, autonomous AI coding agent built by Google, connected to GitHub. The operator is an individual developer who can write a clear prompt, review a plan, and judge a diff; the unit of work is one Jules task — one prompt producing one plan, one set of changes, one pull request. A task clones the repository into a temporary virtual machine in Google's cloud, plans the work, writes code, runs tests, and opens a pull request. Tasks start through a web interface, a command-line tool, a REST API, or by labeling a GitHub issue. Once a task is running the developer can walk away.

The difference in one line: Cards is organized around keeping the job intelligible from plan to commit. Jules is organized around running the work for you while you are elsewhere.

Starting is getting an attempt under way at all — how many you can put in motion per unit of time.

Jules's most defensible claim lives here. It adds hosted execution capacity that does not depend on the developer's typing speed or focus: the free tier allows fifteen tasks per day with three running at once, the Pro tier 100 with fifteen concurrent, the Ultra tier 300 with sixty concurrent. Beyond manual prompts, Suggested Tasks scans the codebase and surfaces candidate work with a confidence score, Scheduled Tasks runs a prompt on a recurring interval, and the GitHub issue label turns any labeled issue into a task. The ontology layer is Execution Mode: remote managed execution for many simultaneous tasks, raising the generation rate directly.

Cards moves a different lever. It does not raise the speed or volume of launches; it raises the seriousness of each one. The default intake interview turns a vague intent into a written description and a plan before the agent touches code, and that specification becomes a durable control artifact that travels with the job. The ontology layer is Control Artifacts: a persistent specification rather than added execution capacity. Where Jules makes it cheaper to start more, Cards makes it harder to start something that was never defined.

The constraint each fits is opposite. A team whose limit is raw coding throughput — work well-scoped, reviewers available, the only question how fast code can be produced — is the team Jules is for, and Cards has no answer for that bottleneck. A team whose limit is that too many started attempts go nowhere because nobody defined them is the team Cards is for; Jules does not address that, and its Suggested and Scheduled task generators can make it worse by adding unvetted attempts to the pile.

Guiding is pointing the agent at the right thing, answering its questions, correcting its direction, and re-entering the work after stepping away.

Jules reduces the active part of guiding through its async model. Every task passes a plan-review step: Jules generates a step-by-step natural-language plan, and the developer approves it or gives feedback before code is written. If the developer navigates away, the plan auto-approves on a timer. Guiding minutes concentrate at the front (prompt, plan review) and the back (diff review, merge decision) rather than spreading across the session. Jules's documentation states that tasks "span several steps hold together more naturally" and that a critic agent "now steps in more reliably and re-engages after replanning," reducing how often the developer must catch a drifting task mid-flight. The per-task saving is concrete: the developer does not sit with the agent while it works. The ontology layer is Execution Mode.

Cards reduces guiding cost through durable context rather than absence. When a developer returns after a meeting, a weekend, or a week, the card already holds the description, plan sequence, comments and attachments, session and transcript record, and the map of what changed; the developer reads the card instead of reconstructing the story from a chat transcript. The ontology layer is Memory/Continuity: durable local state that persists independently of any agent session, readable as ordinary files.

What gets preserved differs. Jules preserves the ability to walk away, but the intent behind each decision lives in the session and the plan, available yet not durably bound to the output a reviewer naturally opens; Cards preserves the intent itself, attached to the work as files that survive the session. Neither reduces the underlying judgment load. Cards' per-attempt re-entry saving is largest for complex work revisited days later; Jules's is largest for routine work the developer wants to fire and forget, though its auto-approve timer cuts the other way — a plan that auto-approves while the developer is away is a plan no one steered.

Checking is verifying that output is correct before it counts as accepted work. This is where the two products share their most serious risk.

Both make the mechanical act of review cheaper, in different ways. Jules presents a diff viewer, inline explanations of changes, executed tests, and a one-click path to publish a branch or pull request; Google states a February 2026 CI Fixer release detects failed GitHub Actions checks on its own pull requests and loops on fixing and resubmitting until they pass. Cards gives the reviewer the description and plan written before and during the work, so "does this meet what was asked for?" can be answered from the card, plus the change map showing which parts of the project were touched.

Neither product adds an independent verifier. Jules uses the same session, model, and context to produce code and to summarize and test it; tests Jules wrote to check code Jules wrote share the same blind spots, and CI is real but not independent. Cards' advisory markers — "plan approved," "merge approved" — can substitute the appearance of review for the substance. Both carry the same rubber-stamping risk: the review path is made frictionless, and frictionlessness in verification is indistinguishable from skipping verification until something breaks. Jules's task summary frames the remaining job as "publish," and its API includes a parameter that opens the PR with no human approval at all; Cards' markers are drafted in a flow the agent participates in. A click is not a check. The difference is what context the reviewer holds: Cards sits in the Control Artifact layer — the original intent is durable and attached — while Jules sits in the Delivery and Integration layer, a diff and test results with the intent left in the session. The Verification and Adjudication layer, independent assessment of correctness, is absent from both.

Fitting in is merging finished changes into the larger project without breaking what is already there.

Jules handles the mechanical integration path: it creates a branch, runs tests on its VM, and opens a pull request carrying the full diff. For an isolated change on an independent part of the codebase, the per-task integration cost is genuinely lower than writing the code by hand, because the branch and diff already exist. But Jules does not coordinate between concurrent tasks. Each runs in its own VM on its own branch; a developer running fifteen or sixty tasks against one repository owns the ordering, merging, and conflict resolution on GitHub manually. The pricing tiers are defined by concurrency, signaling a product built for a high-concurrency regime where integration costs can rise nonlinearly. The ontology layer is Delivery and Integration: PR-centric integration from a remote VM.

Cards' claim here is deliberately modest. The change map makes visible which parts of the project a job has touched, so collisions with other in-flight work surface earlier, and the default setup gives each card its own isolated working copy. But Cards does not run merges, manage releases, coordinate dependencies, or take any position on how a team integrates. The ontology layers are Isolation and Boundary (worktree-level isolation) and Control Artifacts (the change map); Cards does not formalize a delivery pipeline.

The structural difference is locality. Jules integrates from a remote VM into a GitHub PR; Cards integrates from a local working copy into a shared project. Neither solves high-concurrency parallel work on a shared codebase — semantic merge collisions, ordering dependencies, integration coordination — but Jules creates more exposure to it because its concurrency model encourages running many tasks at once, while Cards' default posture does not push production to that scale.

Approving is a recurring authority gate: a separate party who must formally sign off on each piece of work because of policy, regulation, or organizational rule. Neither product has anything to claim here. Cards' markers are advisory — they signal readiness but do not enforce policy, and there is no approval queue, role-based access control, or hosted dashboard for an external reviewer. Jules requires a Google account and GitHub authentication, but these are one-time setup steps, not per-task gates; there is no approval queue, compliance dashboard, or organizational role system, and the PR lands on GitHub where whatever process the team already runs applies. If a team's binding constraint is a recurring authority gate, both products leave it untouched, and a different category of product is the answer.

Cards lifts this fraction upstream: the intake interview keeps vague ideas out of the started pool, and the persistent description and plan mean reviewers reject for substantive reasons rather than because context vanished between sessions. Jules lifts it through early plan correction — a developer who reads the plan and sees Jules aiming at the wrong files can redirect before code exists, preventing a class of full-PR rejections. Two features cut against it: the auto-approve timer means a plan reviewed by no one, and Suggested Tasks starts work on the product's judgment of what matters, scored by the product itself. The honest difference is that Cards improves accepted yield by defining the work better, while Jules improves it by catching wrong plans early, with wide variance depending on whether plans are actually read.

Cards preserves the why. The description, plan, comments, and change map projected against the current codebase persist as readable files, so a developer returning months later can see why the work exists and whether it still holds. Jules produces code and a PR but no durable record of intent — the reasoning lives in a session transcript not bound to the commit history, and the ephemeral VM where the code was tested disappears when the task ends. Both depend most on whether the review that accepted the work was real; careful review produces durable output regardless of tool. Cards adds a structural safeguard against later misreading that Jules does not; Jules's structural exposure is the lost runtime state of an ephemeral environment.

Both reduce some cleanup and create some. Jules's automatic retry handles transient failures without a human, its environment snapshots reproduce a working setup reliably across tasks, and its CI Fixer absorbs a class of follow-up fixes. Cards' default ships agents that look for failure modes in plans and implementations before they cause downstream rework, and the intact on-disk record makes rescuing a stuck job faster. The cleanup each creates is the same in kind — frictionless review paths that let the appearance of checking stand in for checking — but Jules's higher task volume multiplies it: one rubber-stamped PR is a problem, sixty in a day is a regime change. Cards' cleanup risk is per-attempt rather than systemic, because its default posture does not encourage parallel production at that scale.

Jules's honest claim is on starting: hosted, managed execution that puts more change attempts in motion per day than a developer could write by hand, for teams whose binding constraint is raw coding throughput on well-scoped, familiar tasks with review capacity to spare. Cards does not compete on that and is not a better way to run agents asynchronously — that is Jules's job, and Jules does it. Cards' honest claim is on guiding and checking: keeping one coding-agent job intelligible from plan to commit so re-entry and review against intent cost less, for teams whose binding constraint is the cost of understanding and verifying what agents produced. They sit on different ontology layers and address different narrow pipes, so they are not direct competitors. A developer running Jules for execution capacity and Cards for work continuity would have both pipes widened — provided real, independent checks sit behind the markers and the green signals. Without that, the volume Jules adds turns the rubber-stamping risk both products carry into the dominant effect.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Jules 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 Jules and nothing Jules 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 Jules keeps doing whatever it already does in the meantime.