Loom keeps your agents on track.

Tutorial 15: Set up a Kanban board and run a task on another computer

Continue from Tutorial 14. Tutorial 10 used the tutorial store as a board. Here you set up a real, dedicated board, connect a second computer to it as a worker, and have that computer claim and finish a task you publish.

What you will accomplish

You need two computers signed in to the same account (Tutorial 14), each with git and a signed-in harness (the Loom CLI installs uv at ~/.loom/bin/uv; from v0.672 its installer puts that folder on your PATH for new terminals, earlier ones did not). Computer A publishes; computer B works. The worker install changes B's operating-system schedule, so do it only on a computer you intend to enrol.

> Hosted: Sign-up already created a kanban board. Step 1 only confirms it.

> Private install: Use --base https://<your-host> with loom login if you have not signed in > yet; the board already exists, so step 1 only confirms it. Do not use create_store to make it: > sign-in already created the board, and a second one only uses up a store slot (see > Set up a board).

1. Confirm the board exists

YouShow me loom list_stores and loom describe_store --store kanban; confirm there is a kanban store with LogDomain.
AgentThe agent runs loom list_stores to find the kanban store, then loom describe_store --store kanban, whose domain field is LogDomain.
ResultA kanban section exists (its description is "Kanban store for multi-agent coordination."). On both hosted and private installs, sign-in already created it; do not create another.

2. Initialise the board and name it

YouInitialise the Kanban protocol on the kanban store, and make sure my ~/.loom/stores.toml has [workspace] with loom-kanban = "kanban". Do not make it the default store.
AgentIt loads kanban without setting it as default, runs loom_kanban_init (idempotent), and adds the workspace entry if missing.
ResultThe board is initialised (kanban_schema_ensured: ok, four types declared) and [workspace] loom-kanban = "kanban" is set. kanban_protocol_installed is true when this call installed the protocol and false when it was already installed. Sign-up may already have initialised your board, in which case every run reports false; either way, running it again changes nothing.

See Set up a board for the commands behind this.

3. Enrol a worker on computer B

On computer B, clone the tutorial repository and start your harness inside it, so the worker's home repository is palmerpenguins:

git clone https://github.com/mcnakhaee/palmerpenguins.git
cd palmerpenguins
# Start Claude Code, Codex, or OpenCode here.
YouCreate one fixed-session Kanban worker for the kanban board in this repository, using the operating system's native scheduler at its default cadence. Run the proof turn, verify enrollment and the schedule, then heartbeat and scan. Do not claim a task yet, and do not reveal credentials or local configuration.
AgentThe agent verifies it is an interactive, signed-in session in the right repository, creates a fresh worker session, runs one proof turn, installs the schedule, and checks enrollment.
ResultThe worker is enrolled as <harness>@<session-id>, its schedule is installed, and the first heartbeat succeeded. No task was claimed.

The full details, including Claude's one-time token and Windows specifics, are in Connect another computer to a board.

4. Check the worker from computer A

YouOn the kanban board, list the enrolled agents and tell me whether the new worker's heartbeat is recent.
AgentThe agent loads the board and queries kanban_agent.
ResultThe worker appears with a recent heartbeat. If it is stale, check the worker's local log on computer B before publishing work.

> Hosted: The same worker is on the Kanban page.

5. Publish a task from computer A

YouOn the kanban board, publish one ownerless task titled "Count Adelie penguins". The brief: count rows whose species is Adelie in the local palmerpenguins data, verify the count independently, report the method, and make no repository changes. Require a capability repo:palmerpenguins confirming the worker's home repository is the palmerpenguins checkout. Allow one run. Give me the task ID.
AgentIt publishes one KanbanTask with an idempotency key and returns its task_id.
ResultThe task is open with one run slot and no owner.

> Note: required_capabilities must be an object, for example {"repo:palmerpenguins": "the worker's home repository is the palmerpenguins checkout"}. A list is rejected with dictionary update sequence element #0 has length 19; 2 is required.

6. Watch computer B claim and finish it

Within a few minutes the worker's next wake finds the task, checks the capability honestly, claims it, records progress, and submits a result. On computer A:

YouShow the status of that task and its run.
AgentIt queries kanban_task_status and kanban_run_status.
ResultThe task moves from open to in_progress (claimed) and then shows awaiting_review once a result is submitted. The states are open, in_progress, awaiting_review, closed, and cancelled. The Adelie count is 152. As the first claimant of an ownerless task, the worker is the owner and closes it after verifying its own submitted evidence.

Claims are atomic and a submitted run is never reopened. Follow-up work is a new task.

7. Clean up

To remove the worker from computer B, ask the agent to remove that exact worker, or see Connect another computer. Removal deletes its schedule, retires its identity, and removes its stored credential.

Takeaways