9. Coordinate several tans
Allocate ownership before parallel work
Every tan starts in the same working directory. Disjoint conversations do not make disjoint files.
A useful fictional ownership plan is:
| Worker | Write ownership | Read-only inputs | Must leave alone |
|---|---|---|---|
| Main | data/catalog.csv and integration decisions | Both documentation files | Documentation while its assigned tan is editing |
| Label-guide tan | docs/label-guide.md | data/catalog.csv | FAQ, catalog edits, unrelated repairs |
| FAQ tan | docs/visitor-faq.md | Catalog and label guide | Label-guide edits, catalog edits, unrelated repairs |
Agree on when shared inputs are stable. Even a read-only worker can produce stale conclusions if Main changes its inputs mid-audit.
Worked scenario: two independent documentation passes
Enter each launch separately from Main.
OMP slash command — Main only:
/tan For the fictional Lantern Library, improve only docs/label-guide.md for clarity. Read data/catalog.csv as an input, but do not edit it. Do not change docs/visitor-faq.md or repair unrelated files. Report the exact edits and any assumptions about the catalog.
OMP slash command — Main only:
/tan For the fictional Lantern Library, improve only docs/visitor-faq.md for visitors. Read the catalog and label guide as inputs, but do not edit them. Do not change any other file. Report the exact edits and any assumptions that need Main's review.
After each launch, record the discovered identity pair before adding more similar work:
- Full Tan ID.
- Initial job ID.
- Assignment and write scope.
- Current agent state.
- Current job state.
The label tan is not enough to distinguish them.
Worked scenario: Main changes an input
Suppose Main changes the label policy while the FAQ tan is still writing.
Plain-language message — Main only:
Main, discover the exact Tan ID currently responsible for docs/visitor-faq.md. Tell it that the label policy has changed and ask it to reread the current docs/label-guide.md before finalizing.
Do not message every tan. Report the exact recipient and whether it acknowledged the new input.
Do not rely on the tan learning the change from Main’s conversation. The file can be shared while the explanation of its change is not.
Worked scenario: two workers touched the same file
- Stop assigning additional overlapping work.
- Discover which exact agents and jobs are involved.
- Steer or stop the relevant worker according to urgency.
- Inspect the current file and diff, not just each agent’s report.
- Establish one writer for the conflicted file.
- Have that writer reread current contents before making a repair.
- Run the specific project checks that cover the reconciled change.
A failed build during Main’s refactor is not an invitation for a tan to repair unrelated work. Ask it to report the conflict or blocker.
Acceptance check: the final shared file contains the intended combined change, no unrelated edits, and passes the relevant checks selected from the actual project. There is no tan merge command to perform this review for you.
Use unique scratch paths too. Two workers writing local://notes.md can conflict even when their repository files are disjoint.
Tangent work and live control · Source chapter: tan/9-coordinate-several-tans. Original evidence remains scoped to its recorded snapshot.