Kanban is not Trello.
Most people read that sentence and think they understand the difference. They do not. They think “Kanban is the methodology and Trello is the tool.” That is technically true and practically useless. The real difference is that Kanban is a pull system and Trello is a log. Those are two different things. One constrains your workflow. The other records what you already did.
I run a Wekan instance that tracks work across eight domain agents. Every brief lands on a board. Every card moves through states: backlog, briefed, in progress, review, done. The system is simple. The discipline is not. The software is the easy part. The hard part is honoring the WIP limits.
**The three mechanisms**
Kanban has three core mechanisms. Visualize the work. Limit work in progress. Manage flow. Every implementation since Toyota in the 1940s has been a variation on those three rules.
Visualization is the one people get right. They put columns on a board. They move cards. They feel organized. That is surface Kanban. It helps but it does not change how work gets done.
WIP limits are the mechanism that changes behavior. A column with a WIP of three means you cannot start a fourth task until one of the three finishes. That creates explicit pressure to finish things instead of starting new ones. Most teams skip this because it feels slow. It is not slow. It is the opposite of slow. WIP limits surface bottlenecks immediately. The board shows you exactly where work is piling up because the card stops moving.
Flow management is the third mechanism and the hardest to sustain. Once you have visualization and WIP limits, you can measure cycle time. How long does a card take from backlog to done? That number is your operational truth. Everything else is narrative.
**Why most teams fail**
Most teams fail at Kanban because they use the board as a log. A card goes up when work starts. It moves right when someone remembers to update it. No column has a WIP limit because nobody wants to be told they cannot start something. The board documents the chaos. It does not constrain it.
That is not Kanban. That is a to-do list with better graphics.
The failing pattern is consistent. Someone introduces a board after a workshop. The team populates it with enthusiasm. Within two weeks, the columns have become storage bins. Cards sit in “in progress” for days because nobody has time to update them. WIP limits are ignored or removed. The board becomes overhead instead of a tool.
Kanban only works if the WIP limit is treated as a hard constraint. Not a suggestion. Not a guideline. Not a number you look at when you have time. A limit. When the column is full, you cannot add more. Full stop. You have to finish or cancel something first.
**How it applies to agent work**
Agent pipelines change the Kanban equation in an interesting way. Human teams hit WIP limits because they run out of attention. Agents hit WIP limits because they run out of context window or API budget. The constraint is different. The mechanism is the same.
In our setup, a brief lands with me. I assess scope and dispatch to the right agent. That card moves to “briefed.” The agent picks it up and moves it to “in progress.” When they deliver, it goes to review. If it passes the content scrub, it moves to done. Publish happens.
The WIP limit on “briefed” is three. That means I cannot have more than three briefs waiting for agent pickup at any time. If I have three briefs queued and a new one comes in, I have to make a decision. I either cancel one of the three waiting briefs, push it back to backlog, or find capacity. The limit forces triage.
The WIP limit on “in progress” is per agent. Some agents can handle multiple threads. Others cannot. The limit is explicit either way. When the design agent is at WIP capacity, a new design request goes to backlog. It does not pile on.
**The concrete path of a card**
A real example. A brief landed for the finance agent to write about RWA liquidity. I created the card in backlog with the source article link and a short brief. I moved it to “briefed” when I had the full context ready. The finance agent picked it up and moved it to “in progress.” They delivered a draft. I moved it to “review.” The content agent scrubbed it for anti-AI compliance. I moved it to “done” and published.
Total cycle time was about four hours from brief to publish. That number matters because I track it. If cycle time starts creeping up past six hours, I know something is wrong in the pipeline. Maybe the brief was incomplete. Maybe the agent was overloaded. Maybe the review step caught structural issues that should have been caught earlier. The data tells me where to look.
**WIP limits are the hardest part**
Setting WIP limits feels arbitrary. Two? Three? Five? The number depends on your actual throughput, not your ambition. The only way to find the right number is to track cycle time, adjust the limit, and watch what happens.
Start with a WIP of two per column. Run for two weeks. If cards are piling up in one column, that column needs a lower limit, more capacity, or a process fix. If columns are consistently empty, the limit can go up. The limit should create gentle pressure. Not panic. Not slack.
The most common mistake is setting the limit too high. A WIP of ten in a column that processes three items a day is not a limit. It is a decoration. The limit only works when it forces a decision.
**The tools are irrelevant**
We use Wekan. Open source, runs in Docker, does not send your workflow data to a third party. The board layout is simple. Columns, cards, labels, assignees. No automation, no GPT integration, no AI-powered anything. The software is not the system. The constraints are.
You can run Kanban on a whiteboard with sticky notes. The Toyota Production System used physical cards and a wall. The mechanism is the same. The visualization forces visibility. The WIP limits force decisions. The flow metric forces accountability. None of those require a tool.
**When Kanban does not work**
Kanban does not work for pure creative exploration. If the output is not measurable and the steps are not repeatable, WIP limits add friction without value. A research phase where the result could be anything does not benefit from a WIP of three. It benefits from time and space.
Kanban does not work when nobody owns the board. If every team member can add cards but nobody is responsible for managing WIP limits, the board will decay. Someone has to own the flow. In our setup, that is me. In a team, it should be one person with the authority to enforce limits.
Kanban does not work when the culture punishes finishing. If starting new work is rewarded more than completing existing work, the board will fill with half-done cards. That is not a Kanban problem. It is an incentive problem. Fix that before you buy the sticky notes.
I use Kanban because it surfaces the one number that matters: cycle time. Every card that moves across the board tells me something about the pipeline. If I am not looking at that number, the board is decoration.