Work in progress | kanman documentation

kanman does not hand a story to a single long-running job. It looks at the team’s board, decides what to do next and hands each piece of work to a helper: a Claude Code session with one clear brief, such as “implement INT-88”, “review the merge request for INT-88” or “find out why the nightly pipeline fails”. Several helpers work side by side, and kanman keeps track of all of them.

Where helpers work

In a sandbox. Each helper gets its own copy of the repository in its own sandbox. It cannot change anything outside it, and nothing it leaves behind reaches the next piece of work.
Without your credentials. A helper never sees your code host token or model keys. Reading the repository and calling the model go through kanman, which holds the credentials.
On its own branch. kanman publishes a helper’s commits on a branch of its own and opens the merge request. Before anything is pushed, the change is scanned for credentials.

On kanman Cloud this runs on isolated machines in Frankfurt; with a self-hosted runner it runs in your own infrastructure.

What kanman is doing right now

Running tasks. Above the message box in the conversation, Working on 3 things counts the work in progress; All tasks beside it opens everything, finished work and earlier runs included. Select it to see each one with its story and what it is doing right now.
The story’s live line. Each story kanman works on has one line in the conversation that changes in place as the work moves on.
The activity log. Every plan, launch, result, review, question, answer and merge is recorded with its time, its reason and links to the merge request, the pipeline or the review. The team page shows it, and kanman answers “why” questions from it.

Passwords, tokens and other secrets are removed before anything is stored.

The run page

Work kanman did with its earlier way of working still has its run page, at app.kanman.ai/<workspace>/teams/<team>/agents/<run-key>, with its steps, work log and cost. New work is shown in the activity log and on the story instead.

Branch names

kanman pushes each piece of work to a branch of its own, named after the story and starting with kanman/, for example kanman/int-88-update-the-billing-client. kanman only ever pushes branches that start with kanman/; your other branches, and your protected branches above all, are never written by kanman.

When something fails

kanman reads failures itself before it involves anyone. A network error or an overloaded model is tried again. A failing pipeline is read and fixed, or, if it also fails on your main branch, named in the activity log (see Failing pipelines). The same failure twice means kanman looks for the cause instead of trying again. Only what kanman cannot settle itself becomes a question for a person.

When a helper’s attempt fails, the story and the helper’s session say so in one line, such as “Failed: unit tests time out → I’m retrying with the slow fixture mocked out”. kanman then tries a different approach, re-plans or splits the story, or hands it to a person with a clear ask. The line links to the attempt, so you can see what happened.

Cost

Every model call is counted against the team’s daily budget. When the budget is used up, kanman stops for the day and says so in the conversation. See Budgets and cost.

Stopping work

To stop kanman at once, pause the team: no new work starts, and kanman says so in the conversation. To stop work on one story, assign it to a person or move it out of Ready and say why in its notes. See Teams.