Kanbots is a local-first Electron app that converts a git repository into a kanban board where each card dispatches an autonomous coding agent into its own git worktree. It supports 11 agent CLIs, runs up to four agents in parallel, and keeps all state on disk in SQLite. The interesting part is not the feature list. It is what happens when kanban’s “one card, one owner” convention meets a workflow where every card has its own machine contributor operating simultaneously.
One Agent Per Card, Many Cards at Once
Kanbots v1.0.1 launched in late May 2026 as an MIT-licensed desktop app for macOS, Linux, and Windows. The core idea is straightforward: a kanban board backed by a real git repo where each card maps to an isolated branch (kanbots/issue-N) inside a git worktree. Moving a card into the “In Progress” column spawns a coding agent on that branch. Moving it to “Done” or “Blocked” kills the run.
The project gathered roughly 316 GitHub stars and 240 Hacker News points in its first week, which signals developer curiosity if not yet production adoption. The install path is a single npx kanbots, which auto-downloads an approximately 80MB binary. Requirements are Node 20+, pnpm 10+, git, and at least one supported agent CLI on PATH.
How It Works: Worktrees, Adapter, and the Dispatch Loop
The isolation model is the part worth paying attention to. Rather than giving a single agent the whole repo, Kanbots checks out a separate git worktree per card. Each worktree gets its own branch, its own working directory, and its own agent process. Two agents can edit the same file simultaneously at the filesystem level without stepping on each other because they operate on different directory trees.
The agent dispatch goes through a single AgentCliAdapter that normalizes the interface for 11 CLIs: Claude Code, Codex, Gemini, Cursor CLI, GitHub Copilot CLI, Amp, OpenCode, Droid, CCR (Claude Code Router), Qwen Code, and any ACP-compatible CLI. The adapter reuses each CLI’s existing authentication rather than introducing its own token management.
A pre-push hook in every worktree blocks agents from pushing to remote. Promotion, whether to a local commit or a draft PR, is always an explicit user action. In GitHub mode, the board syncs with real issues via Octokit, so the kanban state reflects upstream issue state rather than living in a parallel universe.
The user interface provides a live thread that streams every tool_use and tool_result from the agent, plus decision prompts that pause the run with numbered options when the agent hits an ambiguity. Per-run, per-card, and per-project cost rollups with configurable caps can stop a run mid-task when the budget is exhausted.
Autopilot: Multi-Persona Slots and Self-Evolving Backlogs
The Autopilot mode is where the parallel-agent model starts to strain kanban’s design assumptions. Up to four agent slots run round-robin through configurable personas: product, engineer, reviewer, and tester. Each agent can split a parent issue into subtasks, file new cards on the board, and cycle through cards until the work is done or the per-session cost budget is hit.
This means the backlog is no longer a static prioritization queue. It is a mutable data structure that agents rewrite in real time. A single “implement auth” card might spawn five subtask cards, each with its own agent worktree, each potentially editing overlapping files in the codebase. The QA mode compounds this: it runs typecheck, tests, lint, build, and e2e suites, then auto-dispatches fix runs on failures. A failing test suite can inject new cards and new agent runs without human involvement.
A separate kanbots-mcp-server exposes the board over Model Context Protocol, allowing Cursor, Claude Desktop, or any MCP-aware client to drive the kanban externally. This is architecturally interesting because it decouples the board controller from the Electron shell, but it also introduces a second codepath for board mutations that could diverge from the desktop model.
The Merge-Conflict Bottleneck: Why Branch Isolation Isn’t Enough
Git worktrees solve the concurrent-write problem at the filesystem level. They do not solve it at the semantic level. When agent A edits src/auth/types.ts on branch kanbots/issue-3 and agent B edits the same file on kanbots/issue-7, both runs succeed in isolation. The conflict surfaces only when one or both branches are promoted back to main.
This is the second-order constraint that kanban boards were never designed to handle for non-human workers. Traditional kanban assumes a single human owner per card who can coordinate informally with other card owners. The WIP limit exists to constrain human cognitive load, not to manage filesystem contention. When the “owners” are agents that do not communicate with each other, WIP limits prevent too many branches from diverging simultaneously but do nothing to reduce the per-branch merge surface.
The Firethering coverage and aitoolly writeup both treat Kanbots as a product announcement, listing features and install steps. Neither tests the multi-agent merge scenario. The documentation on docs.kanbots.ru references a Cloud/team tier with MCP-based agent leases that appears architecturally distinct from the desktop SQLite model, which raises the question of whether the merge problem is handled differently in the cloud codepath or simply deferred there as well.
Where This Forces the Industry: The Unit-of-Work Question
Kanbots is a single project with roughly 300 stars. Its direct market impact is small. The structural question it raises is not.
Linear, Jira, and Asana all treat a kanban card as a unit of human work. One assignee, one status, one branch (if the tooling even integrates with git). Kanbots reframes the card as a dispatch unit for a machine worker. The question this forces on every project-management vendor is whether the atomic unit of work stays “one card, one agent” or becomes “one card, many agents.” The first model keeps branch semantics simple but limits parallelism. The second model maximizes throughput but requires conflict-aware scheduling that no current tool provides.
The dependency-arrow feature common to Jira and Linear (linking cards as “blocks” or “is blocked by”) was designed for humans who can read the dependency graph and self-coordinate. Agents do not read dependency graphs unless explicitly prompted to, and even then they cannot guarantee that their changes will not conflict with a card they do not know about. The dependency model needs to operate at the file or symbol level, not the card level, to be useful for parallel agent dispatch.
Kanbots’ approach, keep everything local, let the human resolve conflicts at promote time, is honest about where the current state of the art sits. It does not pretend to have solved the coordination problem. Whether that is a pragmatic v1 constraint or a fundamental limitation depends on whether someone builds the file-level dependency graph that parallel agent workflows require.
The free solo tier and the Cloud team tier also present a divergence risk. Solo mode with SQLite and local worktrees is architecturally simple and well-documented. The Cloud tier with MCP-based agent leases and team coordination is described but not detailed in the available sources. If the two codepaths diverge, the merge-conflict problem could end up solved in one and not the other, which would fragment the project’s own design story. That is a familiar pattern in open-source tools that add hosted tiers, and it is worth watching.
For now, Kanbots is the first kanban board that treats cards as agent dispatch units rather than passive status trackers. That distinction matters more than the feature list. The question is whether the industry follows the “one card, one agent” model and keeps humans in the merge loop, or pushes toward “one card, many agents” and has to invent conflict-aware scheduling to make it work. Either way, the bottleneck has moved.
Frequently Asked Questions
Does Kanbots work well on monorepos with shared type definitions and lockfiles?
Worktree isolation prevents concurrent-write crashes, but monorepos with centralized type files, generated code, or package lockfiles create single-point-of-contention artifacts that will conflict on nearly every promote. Projects with high inter-file coupling see diminishing returns from parallel slots beyond two, because most agent runs will touch at least one shared asset regardless of which card they started from.
How does this differ from manually running agent CLIs in separate git worktrees?
The isolation model is standard git; any developer can run git worktree add and launch separate terminal sessions. Kanbots adds board-state binding so card status reflects agent state, cross-CLI cost rollups across all active runs, a structured promote gate backed by the pre-push hook, and the QA auto-dispatch loop that re-spawns agents on test failures. Without those, coordinating multiple agent runs requires manual tracking of which worktree maps to which task and when each run finished.
What is the cost floor for running four parallel agent slots in Autopilot?
Four concurrent slots means four simultaneous API sessions against whichever provider CLIs are configured. For token-priced models like Claude or GPT-4, that is four times the per-minute spend with no throttling beyond the per-session budget cap. The budget stops individual runs from exceeding their allocation but does not prevent all four runs from each hitting their cap in the same cycle, so the worst-case cost per Autopilot session is four times the per-run ceiling.
What happens when Autopilot splits a parent issue into subtasks that all touch the same module?
Each subtask card gets its own worktree and agent run with no awareness of sibling subtasks’ file edits, so a single parent issue can produce N mutually incompatible branches where N equals the number of subtask cards. The pre-push hook keeps these off remote, but the human at promote time faces an N-way merge conflict that grows with the number of subtasks, not just the four-slot parallelism ceiling. The quadratic conflict surface the article describes compounds further when subtask agents themselves file additional subtask cards.