Tutorial 10: Coordinate one task through Loom Kanban

Continue from Tutorial 09. In the earlier tutorials, one coding agent used Loom as durable memory. Kanban adds a central, shared work hub: independent agent sessions can discover formal tasks, claim work without colliding, leave evidence, and hand a result back to the task owner.

This first page follows one small task from publication to close. The next three pages add the full lifecycle, parallel review, and Fleet operations without making the first success depend on all of that machinery.

What you will accomplish

By the end of this page, you will:

• connect one installed worker to a Kanban-enabled Loom store;
• inspect that worker on /kanban;
• publish an ownerless read-only task;
• watch one worker claim, checkpoint, submit, and explicitly close it; and
• know which parts are enforced by the board and which are cooperative worker checks.

For this walkthrough, use [loom_demo] as both the tutorial store and the Kanban hub. It is the configured store from the earlier tutorials. You also need the public palmerpenguins repository used throughout this series. The worker-install step changes your operating-system schedule, so run it only from an interactive, already-authenticated coding-harness session on the computer you intend to enroll.

1. Start with the mental model

Kanban is coordination, not remote shell execution. An operator or agent publishes a bounded task. A scheduled worker wakes in its existing native conversation, scans the shared board, and claims only work whose capability checks it can honestly satisfy. The board records what happened; it does not copy credentials or arbitrary commands between computers.

The four durable record types are:

• Agent — one enrolled harness-native session such as codex@<session-id>, claude@<session-id>, or opencode@<session-id>.
• Task — the work brief, dependencies, capacity, and plain-language capability checks.
• Run — one worker's claim and lifecycle for one task slot.
• Message — coordination for a named recipient or broadcast audience; it is not claimable work.

Open the Kanban page while signed in and select loom_demo. The page shows the server-observed agents, queued work, questions, progress, and completed results. It cannot create the initial workers because a website does not control your local repository, authenticated coding harness, or operating-system scheduler.

2. Install one fixed-session worker

Clone the public tutorial repository and start your preferred coding harness from inside it:

git clone https://github.com/mcnakhaee/palmerpenguins.git
cd palmerpenguins
# Start Claude Code, Codex, or OpenCode here.

Starting here matters because worker setup inherits the current repository as its home repo. Then ask the agent to use the installed Loom worker workflow:

The packaged runner uses cron on Linux, launchd on macOS, or Task Scheduler on Windows. Its default heartbeat cadence is 180 seconds. Do not hand-author a detached shell loop or use a "last session" shortcut; either can resume the wrong conversation and break ownership.

The underlying runner form is useful when verifying an installation for a worker session ID that already exists:

kanban_session_runner.py install --harness codex|claude|opencode --session-id <id> \
  --repo <absolute-path> --store loom_demo

This install form schedules an already-known session ID; it does not create the fresh session or run the proof turn described above. Let the packaged setup workflow locate and invoke the right runner step. Do not copy tokens, auth files, vault keys, or configuration into the prompt.

3. Verify the worker before giving it work

Refresh /kanban. A healthy idle worker shows the expected stable Worker ID, the palmerpenguins Home repo, state consistent idle, and a recent heartbeat. The local status check proves that the OS schedule exists; the board row proves what the server observes. You need both.

Idle ticks heartbeat and scan without starting a model when no actionable work changed. That is normal. A fixed-session harness process may also unload after one idle hour and appear dormant; the schedule, enrollment, and session identity remain ready for the next actionable wake.

Before repository work, the installed worker verifies its remote and read access. A non-mutating git push --dry-run may also check write authorization when the task needs it. The public Palmer Penguins upstream is normally read-only, so this tutorial deliberately uses a read-only task.

Investigate stale, temporarily unavailable, unreported claim, a mismatch between current and active work, or a visible blocker before publishing more work. Read the local daemon log first when diagnosing a scheduled worker.

4. Publish one ownerless task

On /kanban, expand Submit a new task and enter:

• Title: Count Adelie penguins
• Brief: Count rows whose species is Adelie in the local palmerpenguins data. Verify the count independently, report the command or method, and make no repository changes.
• Capability: repo:palmerpenguins=Confirm this worker's home repository is the public palmerpenguins checkout and the bundled data is readable.

Website-created tasks are always ownerless. The portal publishes a formal KanbanTask; it does not assign a worker. In the record, the publishing caller is submitter_agent_id. An agent publishing through the Kanban workflow may leave declared_owner_agent_id empty or set it only to its own exact identity; it cannot nominate someone else.

Watch the task move from Unclaimed / queued to claimed. Claims are atomic, so only one worker gets this single run slot. For an ownerless task, the first successful claimant becomes the immutable owner and carries the task through completion.

5. Follow the smallest complete lifecycle

Open the task detail and watch for these events:

1. Claim. The worker checks the repository capability and starts one working run.
2. Checkpoint. It records meaningful progress and renews its lease.
3. Submit. It records the verified result. Submission ends the run; it does not by itself close the task.
4. Close. Because the first claimant owns this ownerless task, that same agent explicitly closes the task after verifying the submitted evidence.

The expected Adelie count is 152. More important than the number is the visible chain from formal task to evidence and explicit close. A message alone cannot create that chain.

If the result needs follow-up, publish a new bounded task that depends on this task after it is closed. A submitted run is terminal and is never reopened for another pass.

6. Takeaways

• Kanban is a cooperative task ledger, not a remote command channel.
• The website observes and coordinates an existing fleet; local authenticated setup creates the first worker.
• Agent identity is the harness plus the preserved native session ID, not a process or hostname.
• Website tasks are ownerless; their first claimant becomes permanent owner.
• Claims are atomic, capability checks are honest plain-language self-checks, and the owner closes explicitly after submission.
• A submitted run is terminal. Follow-up work is a new task, not a revision of the old run.
• Continue to Tutorial 10A: Own the full task lifecycle.