Cards and Factory — a comparison

Factory's honest claim is the starting pipe, with a genuine front-and-back contribution to guiding: managed execution capacity plus a persistent environment so a developer can convert intent into a tested, documented PR without staying in the loop. Cards' honest claim is the guiding and checking pipes: it lowers the attention each job costs by absorbing re-entry and makes review cheaper by preserving intent, plans, change maps, and history in a human-readable card. A team whose narrow constraint is execution capacity should look at Factory; one whose constraint is re-entry cost or context-loss rejections should look at Cards. They run on the same codebase without overlap.

The companion piece ([introduction.md](../../formula/introduction.md)) lays out person-and-AI work as a five-step pipeline: starting, guiding, checking, fitting in, and sometimes approving through a real authority gate. This page walks both through those steps plus accepted yield, durability, and cleanup, without ranking. In the marketplace ontology, Factory is managed agent infrastructure with a background delegation engine and multi-agent control plane role; Cards is a control artifact and memory/continuity system on an existing harness.

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 configured agents from that context. The operator is a professional developer who reads diffs and shapes plans in the editor; the unit of work is one job — feature, fix, cleanup, or investigation — held as a durable local object that persists across sessions. Cards does not execute the agent: the harness the developer already runs (Claude Code, Codex, or similar) and its model edit files and run commands. What Cards directs, through default actions and skills, is how the work proceeds: how a plan is drafted and stress-tested before code, how the change is checked, how it merges. The boundary is execution versus direction.

Factory runs autonomous agents it calls Droids that carry out software tasks end to end. A developer describes a task — in the Droid CLI, Slack, an IDE, the desktop app, or by assigning a Linear or Jira issue — and the system reads the codebase, plans, writes code, runs tests, reviews its own diff, documents the change, and opens a PR. A coordinator agent decomposes larger work and dispatches it to specialized droids for code, review, docs, and testing, and Missions coordinate long-horizon, multi-step workflows the company describes as weeks' worth of work. Every Droid gets a persistent Droid Computer — cloud-hosted or the developer's machine — whose filesystem, configuration, credentials, local services, and process memory stay intact between sessions. The operator is also a professional developer; the unit of work is one task delegated to a Droid that produces a PR. The crystallizing difference: Cards keeps the job intelligible from plan to commit; Factory runs the work autonomously and keeps its environment alive. That reaches the developer's relationship to the result. **Work you shaped through a plan you wrote feels yours; work an autonomous run hands you does not** — and what you never shaped, saw, or invested in is the work you find hardest to trust.

Factory raises how many serious pieces of work can get going in a week directly; Cards raises it only modestly, trading throughput for quality instead. A single natural-language description in a terminal, a Slack command, or an assigned Jira issue launches the full generate-test-review-document-merge cycle without the developer writing code in between. Missions let one delegation stand in for a multi-step project, and persistent Droid Computers mean a Droid keeps working while the developer is away and resumes from a filesystem-and-memory snapshot rather than rebuilding its environment. Several Droids run in parallel across surfaces. The layer is Execution Mode: managed long-running, handoff-capable execution that turns one description into a launched delegation.

Cards approaches starting through seriousness, not throughput. The default intake interview asks what the developer is trying to do, why, what success looks like, and what constraints matter, so the card carries a written description and plan before the agent runs. Fewer vague ideas become attempts; because the card holds context, a few well-formed attempts can be in flight at once, so the count of serious attempts rises modestly. The layer is Control Artifact: Cards formalizes intent into a plan artifact before any code exists.

Both share a backfire class from opposite ends. Factory's risk is over-generation — delegating more tasks than review and integration can absorb, converting work into a PR backlog. Cards' is over-ceremony — intake costing more than it saves on small or obvious work. Neither speeds model inference, and neither decides what is worth building; that judgment stays with the developer.

Factory lowers the per-task guiding cost by concentrating steering into fewer interactions. The developer specifies once, AGENTS.md codifies conventions the Droid follows without being told, Skills and custom subagents bundle reusable behavior, and the Droid self-corrects through its internal test-review loop without consuming the developer's attention. Persistent Droid Computers let context — and learned memories and skills — survive across sessions on the machine itself, so work continues while the developer is elsewhere. The guiding that remains is real but front-and-back: initial specification and final review. The layer is Harness and Runtime Mediation: the managed harness absorbs mid-task steering. For exploratory work where the back-and-forth is how the right approach is discovered, that concentration can backfire — a wrong specification produces output that must be thrown out and re-specified whole.

Cards lowers the same cost by absorbing re-entry. When the developer returns after a meeting, a day, or a week, the description, plan sequence, comments, and change map are already on the card; they read it instead of reconstructing it from chat transcripts, and the next agent session loads the same context from disk. The layer is Memory and Continuity: the durable local work object persists independently of any agent session. A smaller secondary lift: because the card lives as files, the developer can glance at work state in a terminal or second window without opening the heavy editor — modest and same-machine only; no phone app or shared dashboard.

The mechanisms suit different work. Factory's is strongest when the developer already knows the answer and needs the steering compressed and the environment kept alive. Cards' is strongest for work that spans sessions, where the developer discovers new constraints and re-entry is the bottleneck. Both share an outer limit: neither significantly expands the developer's attention hours, and neither has an async queue where a teammate picks up guidance of an in-flight task. Cards can also invert if a card becomes a flood of notifications — costing more attention than it saves — a configuration risk Factory's quieter delegation model does not share in the same form.

Factory builds checking into the Droid's default pipeline. The Droid tests the code it writes and runs a review pass on its own diff; `@droid review` on a PR inspects the changes, prioritizes high-impact issues, and leaves inline comments with configurable review depth; Droid Control automates terminals, browsers, and desktop apps for end-to-end QA. Most of this happens without the developer asking and, in many configurations, without seeing intermediate results. The layer is Verification and Adjudication — but predominantly the automated-verification subtype run by the same agent family that produced the code.

Cards makes checking cheaper for a human rather than automating it. The reviewer opens the card and reads the description and plans written before and during the work, not retrofitted afterward, and looks at the attribution tree projecting cumulative changes against the current project to see at a glance what the work touched. The judgment about whether it met intent is formed without reconstructing context from logs. The layer is Verification and Adjudication, human-verification subtype: Cards supports a person doing the checking; it does not automate trusted verification.

The structural difference is whether verification is built into the execution pipeline or into the review process. Both share the same critical vulnerability: neither provides independent verification by default. In Factory the generating and reviewing Droids are the same agent on the same model with the same context and blind spots; in Cards the agents that wrote the code are the same type that draft the advisory markers. Neither routes output to a different model, an external test system, or a separate human reviewer unless the team wires that in. The shared failure mode is rubber-stamping: Factory's Droid reports "review complete" and a time-pressed developer merges without reading the diff; in Cards a reviewer clicks an advisory marker without checking substance. The tooling manufactures the appearance of verification, which is worse than none because the false confidence displaces the checking that would otherwise have happened. This is the most dangerous trap in Cards, and it has to be named plainly. Both are safest when the team treats the tool's signals as input to a real human review, not a substitute.

Factory's pipeline ends at a PR, packaged with code, tests, and documentation and traced back to the originating task or ticket. Git worktrees isolate in-progress changes and Droid Computers provide consistent environments that reduce environment-specific bugs. Factory does not resolve merge conflicts, coordinate across developers working adjacent code, manage the review queue, or handle releases. The layer is Delivery and Integration, PR-centric subtype: Factory creates the PR and stops.

Cards contributes two mechanisms Factory lacks. The attribution tree projects a card's cumulative changes against the current project state, so collisions with other in-flight cards are visible at a glance rather than at merge time, and the default isolated working copy keeps two concurrent cards from stomping on each other's files. The distinctive capability is cumulative change projection: it can answer whether a piece of work is still in place against the codebase now, a question that otherwise needs manual git archaeology. The layer is Delivery and Integration, repo-native subtype: contributions projected against the live codebase rather than packaged and handed off.

Both share the concurrency warning. Factory makes it easy to fan out many Droids through the CLI, Droid Exec in CI, Slack, and ticket triggers; more parallel tasks mean more PRs to coordinate, and Factory has no mechanism for the resulting integration load. Cards' own notes warn that running many cards in parallel raises integration cost faster than throughput. Neither widens the fitting-in pipe or resolves the overhead it creates at scale.

Neither product addresses approving — a separate authority signing off on each piece of work before release, every time, because of policy, regulation, customer trust, or data-access rules. Cards carries advisory markers — plan approved, merge ready — that can look like approval but enforce nothing; the card lives on the developer's machine with no place for a compliance officer to log in (the final merge marker is the one narrow system-enforced exception, still not an external authority gate). Factory's enterprise direction includes governance maturation, SSO, and admin controls, but those are one-time adoption configuration, not a recurring per-work gate, and the in-session approve-each-change prompt is the developer guiding the work, not an outside authority releasing it. For a team whose binding constraint is a recurring authority gate, neither product is built for that problem.

Factory raises this fraction through internal mechanisms: the Droid explores the codebase before implementing, Specification Mode proposes a reviewable plan before code, and the internal test-review-document loop filters mistakes before human review, so the PR that arrives is better-formed than a raw code dump. The counter-movement: the Droid absorbs its failed internal attempts and presents only the final result, which can make yield look better while actual correctness is no higher; without measurement comparing Droid output to hand-written code on the same tasks, the gain remains a question. Cards raises yield differently: the intake interview keeps vague ideas out of the started pool, and the attached description and plan shift rejections from context-loss ("I have no idea why this was built this way") to substantive ("this approach is wrong"). Factory's mechanism is internal and automated; Cards' is record-based and social. Both effects are conditional — neither moves rejections driven by code quality, changed requirements, or business decisions.

Cards has a mechanism Factory lacks: the attribution tree answers whether work is still in place against the current project state without forensic git work, and keeping the why on the card makes future readers less likely to delete code for the wrong reason. Factory contributes durability through ticket-to-PR-to-code traceability and documentation generated alongside the change, but cannot answer the cumulative-persistence question without manual investigation, and a Droid's design reasoning often lives only in the session transcript rather than attached to the code. Both share a stale-plan risk: a plan once correct can outlive its assumptions, and neither stops an agent from following it unless the team heeds the re-confirm signals. For both, durability ultimately depends on whether the review that accepted the work was real and independent, not on what either product provides.

Both have the same honest summary: net direction depends on whether independent review stays real. Factory's cleanup-reducing mechanisms are automated review, consistent Droid Computer environments, generated tests and documentation, and security scanning. Cards' are dedicated failure-mode agents that catch problems in plans and implementations before they cause downstream work, faster recovery because the record is on disk, and preserved history. Both share the same dominant cleanup-increasing mechanism: rubber-stamping merges half-checked work that fails later and needs expensive rework. In Cards this is usually the larger effect unless real independent checks sit behind the markers; in Factory the same pattern lets shared-blind-spot code merge with the appearance of being checked. Neither reduces cleanup from the agent going in circles inside a session. Teams that let verification standards slip in response to output volume see cleanup rise, not fall, with either tool.

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 Factory, so there's nothing to convert and no Droid, Mission, or Droid Computer 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 Factory runs its Droids on its own managed infrastructure, a developer already delegating tasks to Factory can add Cards for the jobs where re-entry and review are the bottleneck without giving up any Droid, Mission, or Droid Computer already in flight — this isn't a switch, it's an additional layer.

Factory's honest claim is the starting pipe, with a genuine front-and-back contribution to guiding: managed execution capacity plus a persistent environment so a developer can convert intent into a tested, documented PR without staying in the loop. A team whose narrow constraint is execution capacity — more features, fixes, and migrations to ship than developer-hours to produce them — should look at Factory. Cards' honest claim is the guiding and checking pipes: it lowers the attention each job costs by absorbing re-entry and makes review cheaper by preserving intent, plans, change maps, and history in a human-readable card. A team whose narrow constraint is re-entry cost or context-loss rejections should look at Cards. They run on the same codebase without overlap, answering different questions: how to produce and run more work autonomously, versus how to keep one job intelligible from plan to commit. Measure which pipe is actually narrow first, because widening the wrong one does not increase durable output.