Concepts
The ideas behind kanman: teams, stories, runs, the outcome gate, decisions, policies, budgets, conventions and maintenance mode.
Read these pages to understand what kanman does on its own, where it stops and asks, and how it proves its work.
Teams
A team is one AI team: one tracker project, one or more repositories, one policy, and a board that mirrors your tracker.
Stories and acceptance criteria
A story is a small, verifiable piece of work with acceptance criteria and a Demonstrate block that shows the outcome.
Runs
A run is kanman working on one story: planning, implementing, verifying and handing over, with every attempt, cost and decision on one page.
Autonomous mode and the team heartbeat
What kanman decides on its own in autonomous mode: it reviews its own plans and goes when it is confident, which boundaries always come to you, how it brings only what needs you, bundled, how it looks after the whole team, and how every team shows what kanman is doing right now or exactly why it is waiting.
Outcomes
Outcomes are how kanman thinks about your team's work: goals in plain language above the stories, created where the work starts, with progress, health and a lifecycle. Where you see what needs you, what happens now, what was done since you were away and what comes next, and the Teams page with one row per team.
Debriefs, Later and calmer updates
After a story or an outcome is delivered, kanman writes a short debrief: what was planned and what was done, where the plan changed and why, what it left for later, what went well and what was hard. Items left for later become stories, so nothing silently disappears. And team chats stay calm: story cards speak up when something is delivered or needs you, not at every step.
Flow and the manager board
See each outcome as one card on the board and open its own board, see work in progress against its limits and how long each story has been in flight, and read your team's flow: how fast stories finish, the pace, a forecast and how long work waits for people. kanman prepares a morning brief, a weekly delivery review with replenishment and a retrospective prompt.
How kanman orders a goal's stories
When an outcome has several stories, kanman plans it as a whole: the order, what each story relies on, which files each one changes. It keeps two runs out of the same files, re-plans when something changes and says so in one sentence, and checks the combined result once the last story landed.
Routines
Routines are work kanman repeats for your team on a schedule, like a weekly digest of delivered stories. One page shows what runs when, what each run did and cost, and whether its results held. You create, change and pause routines there, and you tell kanman when a result was wrong.
The outcome gate and evidence
kanman never takes the executor's word for it. The outcome gate proves each story against its acceptance spec, and the evidence pack shows the proof.
Decisions
Everything that needs a human lands in one place: the decision inbox. Each decision comes with kanman's recommendation and a few clear options.
Policies, presets and authority levels
Each team has one policy: what kanman may touch, how much it may spend, when a human must approve, and which choices it may make alone.
Budgets and cost
Hard spending limits per run, per day and per month, a cost meter on every run, and two ways to pay for model usage.
Conventions (team memory)
kanman learns your team's rules from review feedback and the approaches that worked in verified runs, and shows you exactly what it learned, how often it worked and why.
Code review
kanman reviews your team's pull and merge requests like a colleague and answers the review comments on its own: fixes what is clear, answers questions and asks when a person should decide.
Mentions and assignments
Mention kanman or assign it work in GitHub, GitLab and Jira like any colleague. kanman answers where you wrote, links the conversation, and starts work through your team's usual path.
After the merge
kanman stays with its work after the merge: release notes, watching the deploy, checking production through the story's acceptance check and your signals, and telling everyone when it is live or what failed.
Working hours and reachability
When kanman works for a team, how soon it answers, what waits for the working hours, the handoff note when a run waits on people, and the optional daily update.
Failing pipelines
kanman watches the pipelines of your default branches, including the nightly scheduled runs, tells a broken test from a flaky one or a service that is down, files one fix story per failure across all affected repositories and pursues infrastructure problems until the pipelines are green.
Maintenance mode
With the Hardening preset, kanman looks after the codebase between stories: dependency updates, vulnerabilities, broken links and drift, as a steady, capped trickle of small stories.
Incidents and on-call
kanman can be on call for the services your team runs: it opens an incident when something degrades, investigates, acts within your rules and closes the loop with a summary and follow-up stories.