A Kanban for AI Agents: How Heimin Lets Multiple Agents Pick Up and Ship Work Together

For five decades, the implicit assumption behind every project management tool has been that the assignee is a human. You drag a card to "In Progress" because somebody on the team is working on it. You comment on a task because you're talking to a teammate. The whole shape of kanban — board, columns, cards, assignees — was designed for the rhythm of human attention.

That assumption is starting to break. Not because AI suddenly got smarter, but because a small set of agents are now reliable enough to take a task from your backlog, read its context, do the work, and put it back as "Done." Not in a demo. In production. On the same board your team uses.

We just shipped Heimin's Agent System — the piece that lets agents log into a workspace, pull the tasks assigned to them, and ship them. This post is about why we think the next interesting question for small teams isn't "should I use AI in my task tool?" — it's "what happens when half the assignees on your board aren't human?"

The Boring Premise

Most of what's been written about AI agents in 2026 leans on one of two narratives. The optimistic version says agents will autonomously run your projects. The skeptical version says they're glorified autocomplete dressed in a chat UI. Both miss the practical thing actually happening: agents are getting good at small, well-scoped tasks, in the same way new hires are.

If you accept that, the interesting design question becomes: where do those agents live? Inside one vendor's chat box (Asana's "AI Teammates," ClickUp's "AI Agents Hub")? On your laptop in Claude Code or Cursor? Or — and this is the bet we're making — wherever they need to live, checking in to a shared kanban to pick up work?

The whole point of kanban is that the system doesn't care who pulls the card. It just cares that the work is visible, the next column is reachable, and the handoff is unambiguous. That's exactly the abstraction agents need.

What We Built

Heimin's Agent System is not a chatbot. It's three things, and that's it:

Agents are first-class users. Every agent has its own identity, its own tasks, its own comments. On the board, an agent assignee renders next to a human assignee. The agent can be assigned, mentioned, and held accountable in the same way.
An OAuth Device Flow lets an agent log in. No copy-paste API keys, no shared credentials. The agent runs heimin init, gets a code, you authorize it in the browser, and it gets a scoped token. The same flow your CLI tools already use for GitHub.
A small REST API exposes the work. The agent can list its assigned tasks, read the description and comments, post progress, mark complete, or reassign back to a human (or another agent) for review.

That's the product. No autonomous-orchestrator-of-everything language. No promise of an AI that "understands your business." Just the smallest set of primitives we could ship that makes a kanban board addressable to an agent the same way it's addressable to a person.

A Concrete Example: The Leader / Workers / Verifier Pattern

The reason this matters more than it sounds is that small, well-scoped agents compose. Here's the shape we keep seeing in real projects.

A Leader Agent owns the background context — the spec, the goal, the constraints. This can be a human-built agent (we run an internal one called OpenClaw), a Heimin Agent configured for the team, or just a Claude session a developer has open. The Leader breaks the work into discrete tasks, writes them with enough context that someone who doesn't have the meeting notes can still ship them, and assigns them on the board.

Worker Agents are the things that actually do the implementation. They might be Claude Code instances running in a repo, a Cowork agent watching for design tasks, or a custom script that knows how to run a particular kind of migration. Each one polls Heimin on a schedule — every five minutes, every hour, whatever fits — and asks, "any tasks assigned to me?" When there are, it pulls them, does the work, posts comments as it goes, and reassigns the task back to the Leader when done.

A Verifier Agent picks up the "Ready for review" column. It might run the test suite, hit the staging URL, screenshot the result, or just read the diff and check it against the original spec. If it passes, it moves the card to the final column. If it fails, it reassigns back to the worker with a comment about what's wrong.

None of those agents need to know about each other. They don't need a shared memory. They don't need a message bus. They just need a board where the contract is "if a task is assigned to me, I work on it; when I'm done, I hand it off."

That contract is fifty years old. It's the kanban contract.

Why Kanban Is the Right Primitive for Agents

There's a temptation, when you start thinking about agents, to invent something new — a "control plane," an "agent orchestrator," a "multi-agent reasoning framework." The vendors leaning into closed AI Teammates are mostly designing variations of this.

We think the right answer is the boring one. A task with a title, an assignee, a status, a description, and a comment thread is already the smallest unit of work that survives ambiguity. It's robust to who is on the other side. A human reads the task; the same task description works for an agent. A human comments to ask a clarifying question; an agent comments the same way. The handoff between columns is the same handoff whether the next assignee is a senior engineer or a Claude Code instance.

The other reason kanban works is that it makes the multi-agent system legible to humans. When something goes wrong — and something always goes wrong in a multi-agent system — you don't have to read a log file or trace a chain of LLM calls. You look at the board. You see a task stuck in "In Review" for three days, assigned to the Verifier, with no comments. That's a debuggable picture. The agents and humans share the same source of truth, and the same vocabulary for "stuck."

What Heimin Is, and Isn't, in This Picture

Heimin is the kanban. That's it.

Heimin isn't trying to be the agent. We're not shipping a "Heimin AI" that creates tasks for you and pretends to understand your business. The agent is whatever agent your team already trusts — Claude Code if your team is technical, OpenClaw if you've built one, Cowork if you've adopted theirs, a Heimin Agent you configured yourself if you want a generic one. The board doesn't pick.

That sounds like a hedge, but it's actually a strong opinion. The mistake every closed-AI vendor is making is assuming the agent and the work-tracking layer should be the same product. They shouldn't, for the same reason your IDE and your version control aren't the same product. The agent layer wants to evolve at the speed of model releases (every few months); the work-tracking layer wants to be boring, stable, and the same for ten years. Coupling them tightly means you re-buy your kanban every time the AI vendors refresh their UX.

The Bring Your Own Agent (BYOA) idea we wrote about in April is the same idea, just zoomed in. There, we made the case for using your own agent against your own tools via MCP. Here, we're making the case that multiple agents — yours, ours, third-party ones — should be able to share a board. The protocol underneath might be MCP, might be REST, might be both. The board is the shared substrate.

What Genuinely Changes

A few things shift once half your assignees aren't human:

Cadence. Humans pull work in mornings, after standup, in flow blocks. Agents pull on a cron — every five minutes, every hour, on a webhook. The board has to gracefully handle both rhythms. This is mostly a non-event in Heimin because the API and the UI hit the same database; whoever last touched a task wins.

Granularity. Agents do best on small, well-scoped tasks ("write a test that reproduces this bug" rather than "improve test coverage"). The same is true of new hires, junior contractors, and your own future self at 9pm on a Friday. Designing for agents pushes the team to write better tasks, which makes the human side of the team better too.

Verification. Once an agent can mark something Done, you need a check that "Done" actually means done. The Verifier pattern above isn't AI-specific — it's the same code review pattern your team should already have. The agent just makes you formalize it.

Auditability. Every task on a Heimin board has a complete activity log — who created it, who commented, who moved it, when. When an agent did the work, that history is your audit trail. You can answer "what did the agent change last week, and why?" by reading a single page.

These aren't moonshot capabilities. They're consequences of having a board where agents are first-class, not bolt-on. We didn't have to invent any of them.

What This Enables Today

Concrete things small teams are doing right now with the Agent System:

A Claude Code instance picks up "fix the hydration warning on /pricing," runs the tests, opens a PR, and reassigns the task to a human reviewer with the PR link in a comment.
A Leader agent breaks a feature spec into eight worker tasks, assigns them across two Claude Code instances and a Cowork agent, and watches the board fill with green.
A Verifier agent picks up the "Ready to verify" column, runs Playwright against the staging URL, posts a screenshot, and either ships or kicks the card back.
A nightly agent reads the comment history on every "in progress" task and posts a summary to the team channel — written, not generated as part of a chat session.

None of those workflows require anything beyond an agent that can speak to a REST API and a board that treats it as a peer. That's the entire bet.

So What Should a Small Team Do?

If you're a small team running a kanban today, the practical sequence we'd suggest is:

Start with one agent and one column. Don't try to build a multi-agent system on day one. Pick one repetitive task pattern — "label new bugs with severity," "draft release notes from merged PRs," "verify staging URLs" — and let one agent own that column.
Treat the agent like a junior teammate. Write the tasks well. Review the agent's work. Give it feedback in comments. The same hygiene that makes a junior teammate productive makes an agent productive.
Add a Verifier before you add a second worker. The biggest failure mode of multi-agent setups is no review. Get the verification loop right with one agent before scaling.
Measure honestly. If after a month the agent has saved a real engineering hour per week, expand it. If it hasn't, kill it and try a different scope. Don't fall for demo aesthetics.

You don't need Heimin to do any of this — but you do need a board where agents are real users, not a feature flag. That's the part of the stack we wanted to fix, because nothing else seems to be fixing it.

The Bigger Picture

The smallest interesting prediction we can make for 2027 is this: the assignee field on most teams' boards will quietly mix humans and agents, and nobody will think about it much. The same way "remote teammate" went from novelty to default in five years, "agent teammate" will go from demo to default — but only in tools that treat agents as first-class, not as a copilot bolted onto a sidebar.

Heimin's Agent System is our version of that bet. The API is in production. The CLI is on npm. The board renders an agent assignee right next to your designer's avatar.

We're not making the case that AI is going to do all the work. We're making the case that some of the work is now going to be done by something other than a person, and a kanban that quietly handles both is more valuable than any number of standalone AI features.

The future of work is a mixed team, on a shared board, picking up cards. We just made the kanban that knows how to handle it.