What happened
The Kanzo repository describes a Rust application that combines a browser-based kanban board, an MCP server and a command-line interface. Its central premise is that a person and coding agents can work on the same tasks, either on one computer or through a board shared across computers. The README says the first run creates a ~/kanzo directory and opens the board at http://localhost:4242; it does not require an account or a separate server.
People use the browser interface to create and edit tasks, search across projects, attach images and mark tasks for human attention. Agents connect through MCP, take tasks, move cards and add progress comments. The repository gives setup examples for Claude Code and Codex, and says Kanzo identifies the relevant project from the git remote of the repository in which an agent is working. A running board also exposes MCP at http://localhost:4242/mcp. A CLI supports terminal and script use alongside the browser and MCP interfaces.
The project supports sharing a live board between computers using kanzo share on and kanzo join <address>. The README describes same-network use and a Raspberry Pi as a host; for access over the internet, it recommends putting the Pi and computers on a VPN such as Tailscale, NetBird or WireGuard. It also says the board can be synchronized between machines, though the supplied excerpt does not include the details of that option. The author explicitly warns that there are no logins and that sharing should be limited to a network the user trusts.
Installation instructions cover macOS and Linux, Raspberry Pi, and Windows, as well as cargo install kanzo. The repository offers signed GitHub releases and instructions to verify a download with GitHub attestation. The README and the repository’s About text describe a single 4.5 MB binary that uses 4.5 MB of RAM and starts quickly; these are project claims, not independent measurements. The supplied source does not state a price. It is published under the AGPL-3.0 license.
What the archive adds
kwant’s open-source, self-hosted multi-agent runtime is a related but distinct project: it coordinates bots through handoffs, routines and approvals. Kanzo is a new event, not a new fact about Kwant; it applies the shared-workspace idea to a task board exposed to agents over MCP.
Trend signal
Kanzo supports agent protocols becoming an interoperability layer: the same task surface is available to people through a browser and agents through MCP. This is a single project release, not evidence that the pattern has become dominant, and the source does not compare Kanzo with other protocols or coordination tools.
Why now
The project’s README presents Kanzo as a response to the practical need for humans and coding agents to work from the same tasks. It connects that need to current coding-agent workflows by documenting MCP setup for Claude Code and Codex. The source does not give a launch date or explain a wider market catalyst.
Connections to other events
A prior channel post described Cline Kanban as an orchestration UI for coordinating multiple coding agents. Kanzo is adjacent in its focus on shared task visibility, but the source describes a self-hosted board and MCP interface rather than claiming compatibility with that project or offering the same orchestration features. Separately, the archive’s Kwant note covers a self-hosted runtime with bot handoffs, routines and approvals; Kanzo centers on cards and agent comments.
Why it matters
For teams already using coding agents, the useful design choice is to make work state visible and mutable through an interface both people and agents can use. Kanzo’s MCP server lets an agent claim a task and report progress in the same board a teammate reviews, which may reduce the need to translate status between chat, terminal sessions and a separate task tracker. Its local-first setup also gives small teams a way to try that workflow without adopting a hosted service.
That convenience comes with operational trade-offs. Shared boards have no logins, according to the README, so network boundaries matter; the project’s own guidance is to share only on trusted networks and use a VPN for remote access. Teams should also evaluate whether a lightweight board meets their needs for permissions, auditability and task lifecycle controls before using it for sensitive work. The source establishes the available interfaces, not improved delivery speed or reliable agent completion.
What happens next
- The README will add or clarify explicit access-control guidance for shared boards (6 months, 55%). Watch for: documented authentication or permission controls beyond network-level trust.
Limits and uncertainty
The repository describes the project’s capabilities and intended workflow, but the supplied material does not establish adoption, reliability, security review, or measurable productivity gains. Its claims about binary size, memory use, token use and startup are project-provided figures. No price is stated. The README excerpt also does not fully describe board synchronization, data retention, backup, or the precise behavior of concurrent edits. Claims that setup is effortless should be read alongside the explicit warning that shared boards have no logins.
Skill to build now
Before giving an agent access to a shared task board, write down the smallest useful task contract: what qualifies as ready, what status the agent must set when it starts, what evidence belongs in its comment, and which tasks remain human-only. If you test Kanzo, start on localhost with non-sensitive tasks, then evaluate sharing separately on a trusted network. This isolates workflow value from network exposure.
Reader takeaway
Kanzo turns a kanban board into an MCP-accessible coordination surface: people manage cards in a browser while coding agents can take and update them. It is a practical experiment for teams that want visible agent work, but its no-login sharing model makes network trust a design requirement, not a footnote.