Give Coding Agents a Kanban Board: Kanzo Wants Less Terminal Archaeology

Kanzo is a local kanban board and an MCP server, both packaged in the same program. It is aimed at people who are writing code with coding agents: you and the agent look at the same board, the agent drags cards to doing and leaves comments as it works, and you don't have to copy tasks between tools.

MCP can first be understood as an interface layer through which agents call external tools. Kanzo's approach is to let Claude Code, Codex, or other MCP clients connect to the board in the browser. Data lives in a local folder: the board in SQLite and settings in TOML, with no account required. The official specs are a 4 MB binary, 5 MB memory, and 1 thread. Open source under AGPL-3.0. The GitHub repo is here.

A few points in the feature list are quite concrete:

• Shared board: humans and agents use the same set of tasks; while the agent works, it moves cards and leaves comments.
• Local data: SQLite plus TOML, no cloud account dependency.
• Git sync: sync the board through a private repository when switching machines.
• Agent safe zone: the backlog column is off-limits to agents by default; only after you manually move cards to todo do agents take over.
• Export: export the whole board or a single project to Markdown or JSON.

These features address terminal archaeology. Agents run in the terminal, and task status is scattered across logs, commit messages, and chat history. Looking back to find out what step it reached often feels like digging through an archaeological site. Kanban boards are not new; connecting the board and MCP into the same task flow is the point Kanzo wants to sell.

But the replies are closer to real use than the promotional image. One commenter said backlog isolation should be enforced by the MCP server, not left to the agent to decide which cards it touches. This reminder is not flashy, but it determines whether the board is trustworthy. Rules written in prompts can be misunderstood by agents; rules written into the server are ones agents cannot bypass.

Others are worried about Git sync. Syncing the board through git means conflicts will appear just like they do in code, effectively adding another file to fix. That concern is reasonable. Task cards are not code, but the cost of merge conflicts is just as annoying. What Kanzo needs to answer is how conflicts are presented, who resolves them, and whether the agent still recognizes the board after resolution.

A more critical question came from a follow-up: after an agent finishes, does it move the card to done itself, or does the card move to done only after review? This rule determines whether the board is real. If agents drag cards themselves, the board easily becomes the agent's self-report; if cards move only after review, the board is closer to actual work status. The promotion says agents move cards to doing and leave comments, but the permission boundary for done is not spelled out.

A user also mentioned that agents work in YouTrack, and the board is almost unusable for humans, but the work is indeed moving forward. That is a bit ironic and also points to Kanzo's opportunity: agents don't need a pretty Jira, humans need readable status. Others say Todoist is enough, or that they'll keep using feature.md. That's normal too. For lightweight tasks, Markdown files are hard to beat. Dan Kornas said in a reply that a feature.md both you and your agent can read is hard to beat. What Kanzo has to win is the scenario with multiple projects, multiple agents, and status that is starting to get messy.

Someone joked that agents now also have to sit through endless standups and look at Jira; Dan Kornas replied, wait until they start estimating story points for each other.

Kanzo currently looks like a small tool with a clear direction: put the kanban board into the agent's workflow instead of adding another project management website. Whether it can hold up doesn't depend on card animations, but on three things: whether backlog isolation is enforced by the server, whether completion status goes through review, and whether Git conflicts are controllable. Once these three things are clear, the board will be more than just another layer of decoration outside the terminal.