What is an AI agent kanban board?

What makes it a kanban board for agents (not just for tickets)

A regular kanban board is a planning surface. A column move means “a human decided this thing is in a new state.” An AI agent kanban board is also a runtime: a column move can spawn a process, the process emits events back to the card, the card’s state reflects what the process is doing right now. The difference is whether anything happens when you let go of the card.

Concretely, in kanbots, the columns are:

• Inbox — cards with no status:* label. Sentry imports and freshly synced GitHub issues land here.
• Backlog — status:backlog. Triaged, not yet picked up.
• To do — status:todo. Ready for the next available slot.
• In progress — status:in-progress. An agent run is alive on this card.
• Review — status:review. The run produced something; promote-to-PR or discard.
• Done — status:done. Closed, archived, or merged.

Mapping columns to the agent lifecycle

Drags on the board correspond to specific lifecycle transitions that the dispatcher understands:

• Backlog → In progress. Creates a per-run worktree at .kanbots/worktrees/issue-N-runId/, spawns claude -p or codex exec against it, and starts streaming events into the card.
• In progress → Review. Set automatically when the agent emits a result event with ok:true. The agent has stopped; the worktree is on disk waiting for promote.
• Review → Done. User action. Either Promote commit, Open draft PR, or simply close the issue. The worktree is removed (or stays, on PR).
• Any column → Awaiting decision (state, not column). A yellow chip appears on the card. The card stays in In progress but the run drawer shows the decision prompt with numbered options.

On GitHub mode every drag mirrors as a label edit. The card has status:in-progress on the GitHub issue while the run is alive, plus an agent:* label (agent:running, agent:blocked, agent:review, agent:failed) that tells non-kanbots viewers what the agent is doing.

The card is a thread, not a row

A card on a normal kanban tool is a thin row of metadata: title, labels, assignee, due date. A kanbots card is a complete record of every agent run ever dispatched on that issue. Open the card and you see:

• The agent thread, top to bottom: every tool_use (Read, Edit, Bash, Glob, Grep, …), every tool_result, every text message from the assistant, every decision and its resolved value.
• Run stats: chosen model, elapsed time, input/output tokens, total_cost_usd from the result event.
• The worktree path and branch name (e.g. kanbots/issue-142-01HZ…), with Reveal in file manager and Start dev server buttons.
• A Reply box accepting free text or slash commands (/spec, /review, /split) that fire follow-up runs in the same worktree.

The persistence is in agent_events (one row per stream event) and agent_runs. Reload the desktop window and the thread replays from SQLite. Close the laptop and come back tomorrow; the card and its thread are intact.

A worked example

Sasha drags issue #87 (“Stripe webhook retries on 5xx”) from Backlog to In progress. A run starts. The thread fills with:

1. tool_use: Bash — git log --oneline -20. Result: 20 commits back, no retry logic.
2. tool_use: Glob — **/webhooks/stripe*.ts. Result: one file.
3. tool_use: Read — the file. tool_result: 120 lines.
4. decision: “Should retries respect Retry-Afteror back off exponentially?” The card moves to agent:blocked. Sasha is in standup; Maya the lead clicks option 2 (exponential). The card flips back to agent:running.
5. tool_use: Edit— adds retry logic and a jittered sleep.
6. tool_use: Bash — pnpm test. Result: 1 failure. tool_use: Edit— fix the test. tool_use: Bash— pass.
7. result: ok:true, cost $0.34, 14k input / 2.1k output tokens.

The card auto-moves to Review. Sasha clicks Open draft PR. The PR links back to issue #87 with the commits the agent made on its kanbots/issue-87-… branch. Maya has been watching the thread the whole time; she leaves a one-line approval and merges.

Why columns > chat history

A chatbot puts agent work in a hidden history. Kanban makes the state visible across a whole team without anyone clicking around. Three properties fall out of that:

1. WIP limits actually mean something. Set the In progress column to a max of 4 cards. The board shows you when you’ve hit it. Compare to a chatbot where you have no idea how many parallel agent sessions a team is running.
2. Cost rolls up naturally. Per card, per column, per project. The CFO question gets a real answer.
3. Handoffs are free.A card in Review can be claimed by any reviewer without anyone re-explaining what the agent did — the thread is right there.

Failure modes and fixes

“The board has 60 cards in Backlog and we can’t prioritize.”

Drag order in Backlog is the queue order. The dispatcher picks the top card when a slot frees. Sort Backlog top-down by what you want done next; don’t treat it as a graveyard. If you can’t bring yourself to delete cards, move them to a Done with a wontfix label and clean up later.

“Cards in Review pile up.”

Review is the human bottleneck. If runs are completing faster than humans review, lower the autopilot parallelism (max 4 slots; try 2) or set a tighter runCostBudgetUsd so the agent produces smaller diffs that are quicker to review.

“The label sync is out of step with GitHub.”

If you edit a status:* label directly on GitHub (instead of dragging the kanbots card), the webhook fires and the card moves. If the webhook is delayed (GitHub queues can be slow), the card looks stale for a few seconds. The reconciler runs every 5 minutes and re-pulls open issues to catch up.

When this is the wrong fit

A board this shape pays off when work is card-sized: roughly 2–200 lines of diff, completes in 5–60 minutes of agent time, has a clear acceptance criterion. For exploratory sessions (“help me think through this architecture”), a kanban is the wrong shape — use the chat directly. The board is for work that has a beginning, a deliverable, and somewhere to go after it’s done.

Related reading

For the queue mechanics under the columns, see how to build an AI agent task queue. For who can dispatch and who reviews, see Claude Code orchestration for teams. For the GitHub-specific click path, see assign GitHub issues to AI agents.