Work / Live demos
Agile Cards
A board of contract-shaped work cards and a runner that picks them up, verifies them, and merges them, with a human on the merge button where the stakes call for one. Two properties define it: the unit of work is a contract, not a prompt, and the runner survives its own death because the state that matters lives in a card store, not in the process. The studio ships Agile Cards features through Agile Cards; the board that plans the work is the same tool the work is built on.
Agile Cards runs as a local operator tool, so there is no public instance to sign into. The screenshots below are the board and the runner running on a synthetic set of cards. The cards are invented; the board, the runner, and the tests are the real thing.
Work is shaped like a contract
A card is a Markdown file with a YAML header and a fixed set of body sections. The header carries the routing and the budget: a tier from 1 to 6, a model floor, a token estimate and a per-card cost cap, the files the card is allowed to touch, and the cards it depends on. The body carries the work: context, scope, out of scope, and a list of acceptance criteria. Those acceptance criteria are the definition of done, and they are machine-checked. Each one is one of six types (file exists, file absent, file contains, file lacks, a shell command that must exit clean, or a subjective check handed to a model). A card whose acceptance list does not parse into at least one real check fails closed: a card that verifies nothing is never merged.
This is the whole bet. "Write the feature" is too big to hand an agent unsupervised. "Make this file contain this, and make this command exit zero" is small enough to check without trusting the agent that wrote it. The board is a queue of that second kind of work.
Crash-resume is a property of the store, not the process
The runner is a long-running daemon that spawns a worker per card. It holds no durable state of its own. Every fact that has to survive a restart lives in a card store (SQLite by default, a git-versioned database as an option) with an append-only event log beside it. Claiming a card is a single transactional update against that store, not a file move, so two runners racing for the same card produce exactly one winner.
When a runner dies mid-card, the card is left marked active with a claim on it. On the next boot the runner reconciles: it reads the worker's recorded process id and, if that process is gone, reclaims the card immediately; failing that, any active card whose last heartbeat has aged past a timeout is swept back to the backlog, its claim fields cleared, and a reclaim event appended to the log. The work is not lost and it is not silently abandoned. It goes back in the queue to be run again.
The honest boundary: re-entrancy is at the card level, not the conversation level. A card that was half-done when the runner died is re-run from the start, not resumed mid-thought. The store guarantees the card is picked back up; it does not check point the executor's transcript. The behavior below is the runner's own crash-resume test suite, run for this write-up.
The runner, and what it may do
Each claimed card runs in its own git worktree, in a worker subprocess launched with a scrubbed environment: provider keys and cloud credentials are stripped out unless a card is explicitly granted one. Each card can carry a hard cost cap. A run that would spend past its cap is halted and the card moved to blocked, rather than allowed to run up a bill. Every transition (claimed, executed, verified, reclaimed, merged) is one row in the append-only event log, stamped with who or what made it.
The board is a view over that store. Open a card the runner has claimed and its record shows which runner holds it, when the run started, and its last heartbeat. The board does not animate the runner's inner loop; it reports the card's state, which is the part that has to be right.
Two checks before a merge
Verification runs at two levels. First, a cold-read verifier checks the card's acceptance criteria against the actual tree: the deterministic types (files, contents, shell exit codes) run directly, and any subjective criterion is handed to a model judge that escalates to a stronger model when its own confidence is low, and routes the card to human standup review if the escalation runs out of room. Second, the merge itself is gated by tier. Low-tier cards can auto-merge on a clean verify; middle tiers open a pull request for a second agent to review; high-tier and pinned cards open a pull request and wait for a person. The pin is a hard override: some work does not merge without a human, regardless of how clean the checks came back.
What it is, and what it is not
Agile Cards is the production version of the workflow the studio runs on its own projects, which is the most direct recommendation a tool can carry: it has shipped its own features through itself. Several of the cards in these screenshots are the synthetic echo of that, describing the board and the runner being built.
It is not a general agent harness and does not pretend to be. There is no model-response streaming surfaced here, no dynamic tool marketplace, no conversation-transcript compaction. It does one thing: it turns a plan into a queue of small, checkable, budgeted units of work, runs them with humans on the parts that need a human, and stays correct across a crash because the state that matters is in a store, not in a running process. For an agent fleet, that is the part that is hard to get right, and it is the part this is built around.
Want an agent workflow with contracts at the unit boundary and a human on the merge button? Tell us what you're trying to do.