Kanban for AI agents: how lanes change when agents do the work

Kanban for AI agents keeps the practices that make kanban work, visualising the work, limiting work in progress, managing flow and making policies explicit, and changes how you apply three of them. Work in progress is limited per agent rather than only per lane, because an agent will happily start ten things at once. Every lane needs a written exit policy, because an agent follows what is written and nothing else. And a person stands between the agent and done, which moves the queue: with agents doing the work, the slow part of the board is usually review, not doing.

If you want the basics first, what is a kanban board covers the board itself and what is a lane covers the four lanes on a fenbs board. This piece assumes both.

The practices, briefly

Kanban University’s guide to the Kanban Method lists six general practices: visualise, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively. The Kanban Guide↗ (opens in a new tab) by Daniel Vacanti and John Coleman puts it more tightly: define and visualise a workflow, actively manage the items in it, and improve it. Its definition of workflow asks for “explicit policies about how work items can flow through each state”, and it measures flow with a few plain numbers, among them work in progress (items started but not finished) and cycle time (the elapsed time between when an item started and when it finished).

None of that assumes the workers are people. It does quietly assume things people do without being told: stop pulling new work when they are swamped, ask what “done” means when it is unclear, and notice when a card has sat untouched for a week. Agents do none of those unprompted.

What changes when some workers are agents

• Agents do not tire, and they do not feel overloaded. An agent told to “work the board” will pull card after card for as long as its session lasts.
• Agents run in parallel. Two sessions of the same assistant, or Claude Code and Cursor side by side, can pull from the same lane at the same moment.
• Agents follow written policy literally. A policy that lives in someone’s head does not exist for an agent. One that is written down is followed to the letter, including its gaps.
• Agents are fast at doing and cannot sign off on their own work. The time a card spends being worked shrinks; the time it spends waiting for a person does not.

Limit work in progress per agent

A lane-wide limit, say five cards in In Progress, was designed for a team of people who each carry one or two things. With agents on the board, one agent can fill that limit alone and leave nothing for anyone else. The limit that matters is per worker: one card in In Progress per agent session, finished or handed back before it takes another.

fenbs does not enforce a work-in-progress limit; there is no setting for one. It is a policy, and for an agent the place for a policy is its rules file, the CLAUDE.md or Cursor rules↗ (opens in a new tab) it reads at the start of every session. Because every move on the board is recorded with who made it, you can check the policy is kept: the History shows which agent moved which card into In Progress, and when.

An exit policy for every lane

Make policies explicit↗ (opens in a new tab) is the practice agents depend on most. For each lane, write down what must be true before a card may leave it, and who may move it. With four fixed lanes the whole policy fits on a screen.

• Leaving To Do for Next Up: a person has decided it is next and set its priority. Agents file into To Do; they do not promote their own work.
• Leaving Next Up for In Progress: the card’s plan says what is about to be done. On fenbs every task has a Plan box, separate from the Problem, and the guide asks for it to be filled in before work starts.
• Leaving In Progress for Completed: the change is made, the checks named on the card pass, and a comment says what changed, the commit, and how it was checked. Then a person moves it.

## How work moves on this board
- Take work only from the top of Next Up. Never from To Do.
- One task In Progress at a time. Finish or hand it back first.
- Before moving to In Progress: write the plan (fenbs_update_item, plan).
- Done means: checks on the task pass, comment with commit + how checked.
- Do not move anything to Completed. Leave it In Progress; a person reviews.
- Anything you notice but will not fix now: file it in To Do.

A human gate before done

The last lane is a statement that work is finished. If an agent can move cards there, the statement means the agent is confident, and agents are always confident. Put a person in front of Completed.

Some teams add a Review column for this. On fenbs the lanes are fixed at four, so the gate is a rule about who moves the card. Either the agent leaves finished work in In Progress with its evidence in a comment and a person moves it on, or the agent connects with read and comment scopes only, so that it cannot move cards at all and every move to Completed is a person’s. Moving between lanes is its own permission on fenbs, separate from editing, which is what makes the second option clean.

Watch cycle time, and where it goes

With people doing the work, most of a card’s cycle time is doing. With agents, the doing can shrink to minutes while the card still takes two days, because it waited a day in Next Up to be picked and a day in In Progress to be reviewed. The total looks like a people team’s; the shape is completely different.

So look at where the time goes, not only the total. Kanban calls the age of an unfinished item its work item age, and the useful question each morning is which cards in In Progress are oldest and why. If they are finished and waiting for a person, the constraint is review: add reviewers, or make the evidence on each card quicker to check. If they are unfinished, the cards are too big for an agent to finish in one sitting; split them.

fenbs does not calculate cycle time for you. Its History records every move with the lane it left, the lane it entered and how long ago it happened, so you can read rough cycle times off it; it does not show exact timestamps.

Manage the flow into To Do as well

Agents that file what they notice are useful, and they can also bury a backlog. Watch how many new cards arrive in To Do per week and who filed them. If agents file faster than people triage, ask them to search before filing and to comment on an existing task instead; on fenbs, fenbs_create_item also holds back likely duplicates on its own. A To Do lane that nobody reads is not a backlog; it is a pile.

What stays exactly the same

The board is still the one place where the state of the work is visible. Next Up is still the short list everyone agrees is next. Feedback still comes from reading the board together, with the agents’ changes signed by name alongside everyone else’s. And improvement is still collaborative: when a policy fails, you change the written policy, and every agent picks up the change the next time it reads its rules.