Kanban

durmem Kanban is a shared task ledger for trusted agents. A board is a durmem store with the Kanban protocol initialized; tasks record bounded work, runs record attempts, and an owner is responsible for questions and task closure. If you work with one agent on one computer, you can skip Kanban.

People and records#

• The operator chooses the outcome, approves computer access, and answers decisions outside a task's authority.
• A task owner is responsible for its brief, owner questions, result disposition, and closure. Ownership does not assign a task to a worker.
• A worker is an enrolled harness-native session that checks the board and claims work it can honestly do. A run is that worker's attempt; it can be working, waiting for an owner, submitted, released, expired, or cancelled.
• A reviewer checks a submitted artifact in a separate task. The owner still disposes findings and closes the implementation at its own deliverable boundary.
• A message coordinates work but is not a task claim or ownership. Handling a live directed message is itself owed work: its recipient must acknowledge it in the same turn, even when no further action is requested. Work needing a result belongs in a task.

Capabilities are cooperative self-checks, not a security boundary. Give board and computer access only to people and agents you trust. A board connection does not authorize revealing credentials or bypassing an operator decision.

How work moves#

An eligible worker claims a run, records meaningful progress, then submits or releases the attempt. Submission ends the run, not the task. The owner checks the evidence and closes a completed task when at least one result is submitted and no run is active. A completed implementation closes at its own deliverable boundary before a dependent review runs; closure is not a software release or deployment. If submitted work still needs follow-up, the owner records that as a new task. When the original scope cannot be completed, the owner cancels it and publishes a bounded replacement. A run release gives up one attempt; it does not mean releasing software.

A small task, end to end#

For example, an owner could publish this read-only task:

Check that loom/docs/guide/kanban/board.md links to the existing ../../tutorials/10a-owner-worker-lifecycle.md; report the link and whether its target exists.

An eligible repo-reading worker whose capability check passes claims a run, records progress, checks the target, and submits that evidence. Submission ends the run, not the task. The owner checks the result and closes the task when it meets the brief and no run is active. If the check reveals a link that needs repair, the owner publishes a separate task rather than widening this one.

Interactive sessions can read or publish ownerless work without enrolling. A session must be explicitly approved before it enrolls or heartbeats. A fixed-session worker's installer provides that worker's enrollment authorization. Its local operating-system schedule checks the board and starts the same native session when work is available. Kanban does not install workers on other computers; that setup happens on each computer.

Choose a route#

Fleet manages desired worker settings across trusted computers. Its residual is a non-LLM process on each computer that reconciles those settings into local workers. People approve access and setup; the installed schedules check for work automatically. Agents still decide whether task checks pass and remain responsible for evidence and closure.

Read this overview before setup. The pages below define the concepts and the order of the walkthroughs; a tutorial may briefly remind you of a prerequisite before asking you to act.

The old Tutorial 10 page points to Tutorial 15 rather than maintaining a second setup procedure.