Cross-machine coordination

Three developers, each running two or three coding agents, is an ordinary Tuesday now. Every agent starts from a snapshot, works alone, and hands back a diff. The collisions surface at merge time, on someone else's screen.

Cross-machine coordination puts every agent, on every machine, behind one master. Before an agent writes code, its plan becomes an intent the master can see. Overlap surfaces while the plan is still forming, not after the pull request lands.

The common answer to parallel agents is git worktree per agent: give each one a clean checkout so they cannot overwrite each other mid-task. It works for two agents. It strains at five.

Isolation prevents file clobbering. It does nothing for meaning. Two agents on different files still break each other: one deprecates the session store contract while another builds on top of it. The files never overlap, so git stays quiet until the merge.

Worktrees also stop at the edge of one machine. They coordinate one developer's agents inside one checkout. They have no line of sight across Alice's laptop, Bob's laptop, and the CI box.

Each developer runs a shim, a small Rust binary on $PATH. It wraps the agent process and authenticates to the master with an SSH key, the same trust model as git push. Agent IDs are scoped under the developer with a UUID, so alice/<uuid> and bob/<uuid> stay distinct.

One master owns the coordination state for one git remote. Agents are stateless. The master is the source of truth. When a plan lands, the master matches it against the shared concept registry, derives the files and symbols it will likely touch, and checks it against every other active intent, wherever that agent is running.

The verdict is one of three actions: continue, stop, or revert. There is no soft pause. Agent completion times are non-deterministic, so a time-based lock would deadlock or starve.

1. 01Alice wraps Claude Code on her laptop and starts a JWT auth migration. Her plan reaches the master as an intent and matches auth.session-store-contract.
2. 02Bob wraps OpenCode on his laptop and starts route-handler work that depends on the same contract. The master already holds Alice's active intent.
3. 03The master detects the overlap at the concept level and returns a verdict. Bob's agent gets the context that Alice is mid-flight on the contract it depends on.
4. 04Carol joins from a third machine. Her agent reads the shared world slice for the concepts she touches, not the whole repo.

{
  "agent_id": "alice/4b2e…91af",
  "tool": "claude-code",
  "intent": {
    "summary": "Refactor auth layer to use JWT instead of session cookies",
    "steps": [
      "Replace cookie-based session middleware with JWT verification",
      "Deprecate the in-memory session store"
    ]
  },
  "trigger": "initial"
}

No merge, no rebase, no Slack message asking who is touching auth. The overlap was visible the moment the second plan formed.

Coordinating agents across different developers' machines is the design Tetherlab is built around. What runs today: the master, the shim for Claude Code and OpenCode, the concept registry, and hard-conflict detection where two intents modify the same concept.

Soft-conflict detection, which compares the in-flight code two agents are producing, is Phase 2. So is federation across multiple masters for monorepos where teams own different domains.

Start with the free tier: a local master and your first 100 intents, no card. Wrap one agent, watch the first intent land, then add a second machine.

Read intent-level conflict detection for how the matching loop decides, or the sentinel pattern for how the shim gets a plan out of any agent.