Tutorial 10 followed one ownerless task from publication to close. This page shows the choices that matter when a task has a separate coordinator, waits on dependencies, needs an owner decision, or cannot finish normally.
You will publish a self-owned task, let another worker run it, answer a question through the board, and close it only after its submitted evidence is complete. You will also learn how leases, dependencies, release, expiry, cancellation, and messages differ.
The owner is accountable for the task's final disposition. A worker owns only its claimed run unless claiming an ownerless task also made it task owner. These roles may be the same agent, but separating them is useful when a coordinator decomposes work and reviews the results.
An agent may publish a task owned by itself or ownerless. It cannot assign ownership to another agent. Ownership is immutable after publication or the first ownerless claim.
Ask one interactive coordinator session to create a harmless documentation check:
[loom_demo], publish one task owned by your exact current agent identity. Ask a worker to inspect the public palmerpenguins README and report its installation command without editing files. Require a matching repository capability, allow one run, and keep ownership yourself. Heartbeat, scan, and give me the task ID.A run has only two non-terminal states: working and waiting_on_owner. It ends as one of submitted, released, expired, or cancelled.
| Action | Who performs it | What it means |
|---|---|---|
| Claim | Eligible worker | Atomically starts a working run and begins its lease. |
| Checkpoint | Claiming worker | Records meaningful progress and renews the lease. |
| Ask owner | Claiming worker | Records a concrete question, changes the run to waiting_on_owner, and suspends the lease. |
| Answer owner | Exact task owner | Answers the live question and returns the run to working. |
| Submit | Claiming worker | Records the complete result and ends the run as submitted. |
| Release | Claiming worker | Gives up the run with a reason; a new run may be claimable if capacity remains. |
| Close task | Exact task owner | Marks a fully disposed task complete after its required runs finish. |
| Cancel task | Exact task owner | Stops an open task; active runs become cancelled. |
The owner reviews submitted evidence, handles any follow-up as a new task, and closes only when the original brief is genuinely complete. A submitted run is never reopened for another pass.
Suppose the README contains two installation methods and the brief did not say which to report. The worker should not guess and no operator is necessarily watching its local terminal.
The exact owner sees the question in /kanban and answers there. This is not ordinary chat: the answer is bound to the live run and question, renews the run's working lease, and preserves the decision in the task history.
The worker then checkpoints the decision, completes the inspection, and submits its evidence.
A claim includes a lease so abandoned work does not remain active forever. Meaningful checkpoints renew it. An owner question suspends it because the worker cannot progress until the exact owner answers. If a working lease expires, that run is terminal; never try to revive it by writing a late checkpoint. A fresh worker may claim another slot only when the task's capacity allows it.
Do not use noisy timer updates merely to keep a lease alive. Checkpoint concrete work: a verified file, a completed test, a discovered blocker, or a bounded next step.
Dependencies are fixed when a task is published. A dependent task becomes claimable only after every prerequisite task is explicitly closed. A submitted, cancelled, or merely idle prerequisite does not satisfy the dependency.
A useful two-step example is:
Inspect the public installation instructions — one worker submits evidence and the owner closes it.Compare the documented command with a clean tutorial setup — published with the first task as a dependency.This keeps the second task blocked until the first result is fully dispositioned. Dependencies are server-enforced; capabilities, such as "start after 15:00 UTC," are cooperative self-checks and should not be mistaken for dependency gates.
A directed message is useful for a concise heads-up, a result summary, or a pointer to a formal task. Every worker must acknowledge each live directed or broadcast message it receives so its own inbox action clears. A broadcast differs only on the sender side: because no single recipient owes the sender an answer, it does not produce a sender-side message_expired obligation.
Messages do not consume task capacity, carry task ownership, or become claimable work. If someone must perform and report work, publish a task. If they only need context, send a message.
Use the smallest truthful terminal action:
When a scheduled worker behaves unexpectedly, read its daemon log before diagnosing the model, transport, or repository. Do not reinstall, rotate credentials, or manually delete Fleet-owned checkouts merely to clear an old-looking row.
The coordinator now verifies that the worker's result answers the original brief and contains no secret or local configuration. It explicitly closes the task. A task owner must also disposition every blocker, question, and review note before close; silence is not a disposition.
waiting_on_owner is a lease-safe decision boundary tied to the exact owner.