Kanban for AI agents, proven in daily dev work — kanbento v0.3

kanbento v0.3 is on npm. It is the largest release since the project went public, and the story\ behind it is simple: for two months, an AI harness has used kanbento to track and deliver real\ development work — not only on kanbento itself, but on a dozen other repos on the same machine. A real-time service, a web builder, this website: each has its own board, the same CLI, the same workflow. Every card was captured\ on a board, committed across its commitment point, developed in its own worktree by an agent,\ reviewed and accepted against a checklist, and merged — with the human holding the gates and the\ agents doing the work. The features below are not a roadmap; they are the parts of the tool and the\ workflow that turned out to be load-bearing, day to day, across all of them.

What kanban for AI agents looks like in practice

A card owns a git worktree

The hard part of letting agents deliver work is not the model; it is isolation. Two agents on one checkout trample each other; an agent switching branches loses the board’s context; a reviewer needs a diff that is the card’s diff, not whatever the working tree happens to hold.

In v0.3 a card owns a persistent git worktree. Open it once, and the same branch and directory are\ reused across the whole flow — development, review, rework, acceptance — until the card is done and\ the worktree is explicitly torn down. The branch’s diff against its base is the reviewer’s subject,\ computed on demand.

kanbento worktree open login-fix     # a card-scoped branch + directory, reused across the flow
kanbento worktree diff login-fix     # base..branch — what a reviewer actually judges
kanbento worktree remove login-fix   # explicit teardown at done

The detail that makes this work rather than merely exist: verbs run from inside the worktree are routed to the main board. A small pointer file — the same trick git uses for gitdir: — tells the CLI where the board lives, so an agent working on a branch sees and moves the same cards as everyone else. The board never forks with the code. Those 51 merges are 51 cards that went through this path.

Acceptance is a checklist, not a paragraph

Every team has a Definition of Done. Most of them live in prose, and prose is exactly what an agent will interpret generously.

A card now carries named checklists: append-only registers of open/done items. “Acceptance Criteria” is the one the flow cares about — the commitment point’s Definition of Ready requires it to be non-empty, and an unchecked item is a queryable fact rather than a vibe. Reviewers add findings to a “Rework” list; the dev agent works the list down in the same worktree; the coordinator gates the merge on it being clear.

kanbento checklist login-fix "Acceptance Criteria" -F criteria.md
kanbento checklist login-fix --check 1,3
kanbento checklist login-fix --incomplete      # exit 1 while anything is open — a gate you can script

This is the mechanism behind the numbers above: 554 criteria written before work started, 347 checked by the agent that did the work, and a gate that would not let the rest through. It is the practical form of what we argued in making policies explicit — a gate is only real when the thing it checks is data.

Recall over the whole store

A board that accumulates knowledge is only useful if the knowledge can be found by an agent that\ did not write it. kanbento search is ranked recall over everything in the store at once — cards\ (archived included), records, notes, precedents, vendored documentation stubs — in one query, with\ no index to maintain. It is the first thing a fresh session runs before capturing a card that may\ already exist, and it is why our pool has 9 merged duplicates rather than 90.

The board measures its own flow

We published our first flow report in July from an\ early fold over the event log. In v0.3 that fold is a verb: kanbento metrics folds the log into three regions — the upstream funnel, the delivery pipeline, and system balance — plus knowledge accrual, and writes views/METRICS.md beside the board.

Nothing was instrumented to get the numbers in this post. Every transition already carried a timestamp; the commitment point was already an explicit boundary; a rework loop was already a recorded event. Cycle time, lead time, throughput, arrivals against departures: arithmetic over facts the board records anyway, which is why they cannot drift from reality.

Cards belong to a product scope

One repo, several products — a monorepo, a platform with a CLI and a web app, a service with a public API and an internal one. A flat board mixes them, and “what is in flight for this product” becomes a question nobody can answer from the views.

Boards can now declare a product scope vocabulary, derived from the repo’s directory topology\ or an explicit scope→paths map. A captured card is assigned its scope by inference from where the\ agent is standing; it can be reassigned or healed later; it shows as a chip on every view and is a\ filter on the pool and on search. The unscoped queue is its own visible thing, not a silent default.

The knowledge layer gets a lifecycle

Records — capabilities, strategies, procedures, whatever the manifest declares — carry a status. In\ v0.3 the status changes through the CLI: kanbento graduate appends an identity-stamped event, so\ who promoted a capability from germinating to active, and when, is part of the record rather\ than an unattributed frontmatter edit. Body appends are logged the same way. The knowledge layer\ now has the audit trail the flow layer always had — ten graduations so far, each one a decision\ somebody can be asked about.

Try it today

npm install -g kanbento — and start here if it is your first board.

Full list of changes in the release notes.