Tetherlab vs git worktree per agent
Overview
A worktree per agent gives each one its own working directory over a shared git store. It stops agents from overwriting each other's files mid-task. It does not stop two agents from planning incompatible changes, and it stops at the edge of one machine. Tetherlab runs on top of git and adds the layer worktrees cannot.
This is the one comparison where the honest answer is use both. Worktrees isolate files. Tetherlab coordinates intent. Tetherlab keeps git, and worktrees, underneath.
What git worktrees actually solve
Each agent gets an isolated checkout: its own files, dependencies, and branch over one underlying .git object store. Concurrent writes stop racing, and silent runtime corruption turns into visible merge-time conflicts. For two agents on a clean codebase, that is enough.
What they cannot solve
- Concept-level conflicts. Two agents on different files still collide when one deprecates a contract another depends on. Files do not overlap, so git stays quiet until merge.
- Cross-machine coordination. Worktrees isolate one developer's agents inside one checkout. They have no view across separate developers' machines.
- Shared runtime. Worktrees share the same local database, Docker daemon, and caches, so concurrent state changes still race.
- Disk cost. A large repo can generate many gigabytes of worktrees in a single busy session.
Side by side
| Capability | Tetherlab | git worktree per agent |
|---|---|---|
| Prevents mid-task file clobbering | ||
| Detects concept-level conflicts before code | ||
| Cross-machine, cross-developer coordination | ||
| Shared semantic concept registry | ||
| Conflict detection timing | Plan stage | Merge time |
| Relationship to git | Sits on top | Is git |
When worktrees are the right tool
One developer running one or two agents on a codebase with clean separation. No need for cross-developer coordination, no shared domain hotspots. In that shape, a worktree per agent is simple and sufficient, and adding a coordination layer would be overhead.
When worktrees stop being enough
More than a few concurrent agents, multiple developers each running agents, or any feature touching shared hotspots like routes, configs, and domain registries. When anyone touching auth right now? is a regular Slack message, that is a coordination failure with a human band-aid, and the layer that fixes it sits above worktrees.
Migration is additive. tether init bootstraps the concept registry from the existing repo structure, and worktrees keep working underneath. See cross-machine coordination.
Frequently asked questions
- Does Tetherlab replace git worktrees?
No. It runs on top of git and works alongside worktrees. Worktrees isolate files; Tetherlab coordinates intent and detects concept-level conflicts. Keep both.
- At how many agents do worktrees stop being enough?
There is no hard number, but the pattern strains past a few concurrent agents and especially once multiple developers run agents in parallel or work touches shared hotspot files. The limit is coordination, not isolation.
- Can two agents on different machines conflict through Tetherlab?
Yes. One master owns coordination for a git remote, so it sees active intents from every developer's machine and flags overlap at the concept level before code is written. Worktrees cannot see across machines.
- Does Tetherlab require a specific branching strategy?
No. Git stays underneath handling file history and worktrees. Tetherlab adds an intent and conflict layer on top and does not dictate how you branch or merge.