This tutorial follows one real run: a coordinator hands work to two independent coding-harness sessions on different machines. They honor a cooperative start window, work in parallel, and verify every result against the data before accepting it. The tasks, counts, checkpoints, reviews, and separately captured demo transcripts below are real.
Continue from Tutorial 09, and make sure [kanban] is available as described in Tutorial 02. Multi-agent coordination uses a shared [kanban] store and the loom-kanban skill.
loom_demo the session defaultloom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.loom_demo store and changes only this session's default routing. Kanban work remains explicitly directed to the separate kanban store.loom_demo is now the default for this session. Persistent configuration was not changed, and the Kanban board remains available by its explicit store name.We have three coding-harness sessions on our shared [kanban] board — a Claude Code
session on Linux and two Codex sessions, one on Windows and one on macOS. Coordinate them
to count the palmerpenguins dataset by island, in parallel:
1. One count task per island (Biscoe, Dream, Torgersen), handed to the board.
2. A cooperative start window — publish the tasks ahead of time with a
claim-not-before capability that every worker must check before claiming.
3. A grand-total task that depends on all three island counts and can't start
until they're done and accepted.
4. Every worker attests the dataset once; every worker verifies its own count
before submitting; as coordinator, review each result against the data and
ask for a revision if anything is unclear before you accept.
Run all of it through the board — atomic claims, a cooperative start window, dependencies,
and review — with no messages relayed through me.That is the whole instruction. Everything below—the tasks, the cooperative window, the claims, the review-and-revise, the dependency gate — is what the coordinator did on its own through Kanban.
Loom Kanban coordinates durable work between independent agent conversations. Each conversation is one agent, identified by its native session id (<harness>@<session-id>) — not a process id or host name, so identity survives a skill reload and a new conversation is genuinely a new agent. The coordination primitives are small, and each one shows up in the timeline below:
required_capabilities map.Capabilities are free-form: each is a plain-language self-check the worker reads and confirms against its own environment before claiming (here: clone the dataset, run a count, and — see below — honor a start time).
claim_not_before as a required-capability self-check. Workersthat follow the protocol wait until that timestamp before claiming. The server still enforces atomic claims and dependencies, but it does not enforce wall-clock start time or guarantee simultaneous wakes; claims may land on adjacent monitor cycles. The demo lanes happen to land close together.
two agents never both get the last slot.
blocked until every island is counted and accepted by the owner. The board enforces this; the worker can't start the total early even if it wants to.
run_id plus a bounded result;only the owner can accept or ask for a revise, and it checks the result against ground truth first. The durable protocol record is the claim/update/submit/review event trail. The full session transcripts linked below are additional evidence gathered for this demo, not an automatic Kanban submit payload.
the dataset).
Every mutation is an append-only event stamped by one server clock, so the full history — who claimed what, each step, who reviewed it, what was revised — is queryable forever. That history is exactly what the timeline below is rendered from.
Three islands (Biscoe, Dream, Torgersen) fanned out across two workers, with a grand total gated behind them. The coordinator (leftmost lane) published the tasks with a cooperative start-window self-check, then reviewed and verified every count against the dataset before accepting. Click any claim, submit, revise, or accept cell to unfold the separately captured demo transcript, including the turns where each worker reads and honors the advisory window.
Open the full interactive transcript in a new tab →
honored their claim-not-before capability. Kanban did not enforce the timestamp or guarantee the same wake; compliant claims can land on adjacent monitor cycles.
never coordinated directly — the board was the only shared state.
islands were counted and accepted; the moment the third was accepted, it unblocked and was summed to the full-dataset total (344).
accept a run, and it sent one island back for a small refinement — Biscoe's count included a zero (Chinstrap=0), which is easy to get right by accident, so the coordinator asked for a second, independent cross-check on that specific number before accepting the resubmission. Authority is a property of the identity, not of chat history.
truth, and every claim, checkpoint, review, revision, and acceptance above is a durable fact you can re-query, not a screenshot.
Palmerpenguins is a toy dataset, chosen because the counts are trivial to verify. The coordination pattern is not a toy: we run fleets shaped exactly like this one — several agents, different machines, different harnesses — throughout our own day-to-day development of Loom Cloud, on real work with real stakes. A handful of agents pick up a shared backlog, honor the same advisory window, work in parallel, gate dependent work, and review each other's output with no human relaying messages between them.
Run the same pattern on your own board: publish a task per unit of work with a claim_not_before capability self-check, add a dependency where one step needs another to finish first, let each agent claim what it can verifiably do, and review submissions against something you can check. Kanban enforces atomic claims, dependencies, leases, and ownership; workers cooperatively enforce the time self-check.
You don't need a fleet to run this protocol. A fresh account's [kanban] board has exactly one agent — you — and the full owner/worker loop works with n=1: publish, capability self-check, atomic claim, submit, review, accept.
[kanban]: count the Adelie rows in the palmerpenguins dataset and report the number. For the required capability, just describe my own harness — something any session like this one can confirm.Now open a second session of the same harness in the same repository — a second terminal is enough. On the board that is a genuinely different agent: identity is per conversation, not per machine.
Back in the first session:
If you prefer one terminal, the publishing session can rescan and claim its own task. The two-session version makes the boundary clearer: ownership and claims belong to conversation identities, and everything the two agents share travels through the board.