Why a coordination layer beats more guardrails
Overview
When two agents rewrite the same function in incompatible ways, the usual reaction is to add another rule: a stricter review prompt, a linter, a checklist. Guardrails tell an agent what not to do after a problem can already appear. A coordination layer tells each agent what every other agent is about to do before any of them starts.
The failure guardrails keep missing
Agents are blind to each other. Each one starts with a snapshot, works in isolation, and hands back a diff. Two of them can touch completely different files and still collide at the concept level: one deprecates the session store contract while another builds on top of it.
A guardrail fires on the output of one agent. It has no view of the other agent's in-flight work, and it runs after at least one of them has already written. You are managing a collision, not preventing one.
Instruction-following was never the bottleneck
Agents already follow instructions. They do not collide because they are reckless. They collide because each one starts from a snapshot with no knowledge of concurrent work. More rules sharpen a single agent's behavior; they do nothing about its ignorance of the others.
The PR queue makes this concrete. Add more review and the queue grows faster than the reviewers. The bottleneck moves from writing code to reconciling it. It does not disappear.
What a coordination layer does instead
The shim coaxes a plan out of each agent and submits it to the master as an intent before any code is written. The master matches the intent against the shared concept registry and checks it against every other active intent. A hard conflict, two intents modifying the same concept, surfaces at the plan stage.
The agent never learns about the system. The shim carries the coordination; the agent just plans and acts as usual. The check happens one layer above the agent, where the other agents are visible.
Same collision, two approaches
| Step | More guardrails | Coordination layer |
|---|---|---|
| Before code | Nothing to check yet | Plans compared; overlap flagged |
| During work | Agents blind to each other | Master holds every active intent |
| At the diff | Reviewer flags a written collision | No collision to flag |
| Resolution | Engineer unwinds work at PR time | Developer picks one; both proceed |
The notification is small: Two agents proposed competing changes on auth/session.ts. Pick one. One click, both agents continue. No merge, no rebase, no Slack hunt for who is touching auth.
Where guardrails still belong
Output safety, secret scanning, rate limits, and review for taste are real and orthogonal. Tetherlab does not replace them. It solves the coordination failure that lives one layer above them, the one more rules cannot reach.
Phase 1 catches hard conflicts: two intents modifying the same concept. Soft conflicts, where two in-flight implementations contradict without an obvious concept overlap, are Phase 2. If two agents genuinely touch non-overlapping concepts, the master passes both through. That is correct behavior, not a gap.
Next steps
Read how the master decides in intent-level conflict detection, or how this spans a team in cross-machine coordination.
Frequently asked questions
- Is a coordination layer a replacement for code review?
No. Review, output safety, and secret scanning are orthogonal and still belong. A coordination layer prevents the collisions that would otherwise reach review; it does not judge taste or correctness of a single change.
- Why not just write stricter agent prompts?
Agents already follow instructions. They collide because each starts from a snapshot with no knowledge of concurrent work. Stricter prompts sharpen one agent's behavior but cannot give it sight of the others. Coordination happens one layer above the agent.