What kanman does

kanman runs an AI teammate inside your engineering team, under your rules, and proves every change before it asks for review.

kanman runs an AI teammate inside your engineering team, under your rules. It takes a requirement, writes the stories, ships the code through Claude Code or Codex, proves that the change meets the acceptance criteria, and keeps an audit trail. All of it happens in the tracker you already use, on EU infrastructure or on your own.

Coding agents are good at writing code. What most teams miss is everything around the agent: who turns a vague request into small, testable work, what the agent may touch and spend, how anyone knows the result does what was asked, and who approved what. kanman is that operating layer.

The five stages

Every piece of work goes through the same five stages. How a story flows walks through them with a diagram.

Stage What happens Where you come in
1. Intake A requirement (written on the team’s intake page or in a Slack thread) becomes small stories with Given/When/Then acceptance criteria, a test plan and a Demonstrate block. You edit, reject or approve each story. Approved stories are written to your tracker.
2. Dispatch When a story reaches the Ready column, kanman checks the team’s policy: pause, working hours, budget and how many runs may happen at once. During the run it checks allowed repositories, denied paths and change size. If the policy blocks the work, the story waits or kanman asks you in the decision inbox.
3. Execute Claude Code or Codex writes the code in an isolated sandbox, on its own branch, connected back to kanman. If the plan needs approval, or the agent has a question, it lands in the decision inbox.
4. Verify kanman runs the outcome gate: the story’s acceptance spec in a fresh environment and on a clean checkout, your CI, and an independent reviewer that checks every criterion. One automatic rework attempt is allowed. If verification still fails, kanman stops and asks.
5. Handoff kanman posts the evidence pack on the pull request and the tracker issue, marks the pull request as verified and writes an audit entry. A human reviews and merges, unless your policy allows auto-merge for small changes.

What kanman owns, and what it uses

kanman owns the parts that make an AI teammate safe to run in a team: intake, policy, dispatch, verification, evidence, audit and reporting.

It uses what you already have:

  • The coding agent. Claude Code by default, Codex as an alternative. You can bring your own model provider contract.
  • The tracker. GitHub Issues, GitLab issues or Jira. The tracker stays the source of truth; kanman mirrors it.
  • The code host and CI. GitHub or GitLab, including self-managed GitLab, and your existing CI.

You do not move your backlog, your repositories or your review process into kanman.

One teammate, not a crowd of bots

There is exactly one kanman in your workspace. It says “I”, shows up next to your colleagues in assignee lists and on the tracker, and every action it takes is recorded under its name. Internally it plans, implements and reviews, but you never manage a roster of agents.

Under your rules

Each team has a policy. A preset gives you sensible defaults, and every knob can be tuned:

  • which repositories and branches kanman may work on, and which paths it must never touch
  • how large a change may be, in files and lines
  • how much a single run, a day or a month may cost
  • whether a plan needs approval before any code is written, and who merges
  • which decisions kanman takes on its own, which it reports, and which it always escalates

Some protections are not configurable: the acceptance specs are off limits to the code-writing agent, every change is checked on a clean checkout, and anything touching production data or security settings always goes to a human. See Policies, presets and authority levels.

Proof, not promises

kanman never takes the coding agent’s word that a story is done. Before work starts, kanman writes an executable acceptance spec from the story’s Demonstrate block and confirms that it fails. The pull request is only marked as verified when the same spec passes on a fresh checkout, CI is green and the reviewer has checked each criterion. The result is an evidence pack on the pull request and the tracker issue: criteria, gate results, test counts, artifacts such as Playwright traces, cost and duration. See The outcome gate and evidence.

Who kanman is for

kanman is built for engineering teams of roughly 5 to 50 people that already use GitHub or Jira, have tried coding agents individually, and now want a team-level setup with guardrails. The person who sets it up is usually a head of engineering, a CTO or a tech lead. The people who work with it every day are the developers who write requirements, answer decisions and review pull requests.

kanman is not a general project management tool and not a chat assistant for everything. It does engineering work, inside your process.

Where kanman runs

  • kanman cloud: runs execute on isolated machines in Frankfurt, Germany.
  • Self-hosted runner: the same execution environment as a container in your own infrastructure. It connects outward to kanman, so you open no inbound ports.

See Hosting and data residency for details.

Next steps

Last updated: January 1, 0001

Open kanman