Three ways teams use kn0t.
Coordinate your own parallel sessions, catch dependent changes across repositories and apply team rules without collecting work content.
Run two agents without relaying messages between them.
Your Claude changes an interface in one worktree while your Codex builds against the old version in another. Both sessions are yours, but neither can see the other.
Without kn0t, the mismatch appears in a test, review or merge after both sessions have moved on.
kn0t sees both threads, follows the dependency and holds the later change locally. The agents agree an order, and the held change retries with that agreement in context. If one side goes idle, kn0t can notify you or let a supervised agent answer with its write and command tools removed.
You keep the time saved by parallel work without copying context between prompts or cleaning up the collision later.
Apply team rules without collecting developer activity.
You need work accounts in work repositories, checks for secrets and risky commands, and a clear view of whether each enrolled machine has the current policy.
A published policy does not prove that every machine is using it. Activity monitoring can answer by collecting far more than this question requires.
kn0t sends versioned guardrails and repository rules to enrolled machines. Each machine checks locally, keeps the last policy while offline and reports a fingerprint with a status reason.
Leads can see whether policy is current without receiving prompts, transcripts, file contents or a developer activity feed.
Local decisions. Narrow sharing. Human authority.
Each machine checks changes locally. Team sharing is limited to coordination facts. Agents and people author the agreement; kn0t routes it and records consent.