Guide

The board can't lie when agents write the code

Boards don't lie out of malice. They lie because their state is hand-maintained. A look at the agent era: more merged PRs, longer reviews, and a board that derives its state from git instead.

Last updated:

Project boards rarely lie out of malice. They lie because their state is hand-maintained: someone was busy doing the actual work and did not move the card. The board state is a reminder of what somebody should have entered, and the faster the work runs, the wider the gap between repo and board grows.

That gap is opening wide right now. Faros AI analysed telemetry from 1,255 teams and more than 10,000 developers: on teams with high AI adoption, merged pull requests rise 98% and review time 91%, while the organisations themselves are not delivering any faster. The throughput does not disappear, it shifts: more code, more PRs, more review and coordination work. Precisely the work a hand-maintained board captures worst (Faros AI, Lab vs. Reality).

The category is responding: Linear assigns agents as team members. Cursor, Codex or Devin take an issue and work in the repo. Atlassian is heading the same way with Rovo. On both paths the work happens in the repository and the result flows back into the tracker. That is the right direction, and it runs past a point Zuuna has occupied from its first commit: the board derives its state from git.

Recording of a real agent session: ZCode (GLM) picks up a Zuuna card over the MCP server, commits to kenzotp/zuuna-cli, the pull request merges, and a git rule on the board moves and closes the card.
Real session: ZCode (GLM) picks up the card, commits to kenzotp/zuuna-cli. When the PR merges, a git rule on our board moves the card.

Why a board derived from git cannot lie

A board that derives its state from the repo has no state anybody has to maintain. It has evidence: a commit sits on the card because it happened in git. A release is done because the git tag exists. The deploy gate is green because the pipeline reported it. You can disagree with any one of these, but none of them needs a card that somebody "quickly" updates, and none of them contradicts the repository.

In the agent era this moves from nice feature to core. When a coding agent reads the card over the Zuuna MCP server, builds in the repo (Claude Code, Cursor, Codex) and the pull request merges, a git rule on the board moves the card. Commits, PRs, releases and deploy gates update the board without a single manual action. Nobody drags cards for agents. The board only repeats what the repository evidences.

What Zuuna does not do

Zuuna does not write code: the agents build, with their own tools. Zuuna does not decide anything: there is no project-management AI that plans or prioritizes; the board mirrors the repo, agents and humans do the rest. And Zuuna does not deploy without your pipeline: deploy gates hang off your process, not our server. The MCP server is deliberately board I/O: eight tools, from reading the board to commenting on a card, nothing else.

The honest state today: the MCP server is published as mcp-server-zuuna on npm (version 0.1.2, MIT-licensed, tested in CI), set up with one npx line. How to wire it up is on Zuuna for AI agents.

The merge is the moment of truth

Project tools have long managed the state: the narrative about work. Git manages the work itself. A board that derives from git can no longer let the two drift apart: it can have gaps where nothing merges, but it cannot say anything that is not true. When agents write the code, that is exactly the property that matters: the agent tells you a lot; the repository has no reason to stay silent, and the board merely translates it.

Ready to make it simpler?

Boards, sprints, docs and time tracking in one place (GDPR-compliant, hosted in the EU).