Every team I've worked with has unwritten rules — who to ask before touching auth, which decisions are settled, what "in progress" actually means.
They used to travel by osmosis.
Once everyone on the team is coding with an agent, osmosis stops working, because half the conversation now happens in someone's private session.
This is the one-page agreement we ended up writing down, and why each clause is in it.
When every developer on a team codes with an AI agent, one of the first things to break down can be the unwritten rules.
Small, shared assumptions that once traveled through everyday conversation ("ask before you touch auth," "we decided on v2 last week") may not reach a teammate's private session — let alone the agent working in it.
The established fix for that is a working agreement: a short, explicit set of norms a team writes for itself.
This one is designed for AI-assisted teams — a page you can copy, adapt, and keep somewhere every teammate can access and every agent is configured to read.
What a working agreement is — and isn't A working agreement is a team norm, written by the team, kept short, and revised as you learn.
It is not a tool, and not a policy handed down from above.
It doesn't enforce anything — it aligns behavior.
That's precisely why it survives across whatever mix of editors and agents your team actually uses: it lives at the human layer, above any one tool.
If you've run agile ceremonies, you've seen these before.
What's new is that agents now perform part of the work, so a few assumptions that people may have absorbed implicitly need to be written down.
Accountability still stays with people.
The template Copy this, cut what doesn't fit, and fill in the blanks.
Keep it to a page.
That block is the whole deliverable.
Everything below is just why each clause is there.
Why each clause earns its place
1.
Shared decisions.
Re-deciding can be a costly habit on an AI-assisted team.
One session concludes "money is integer cents"; another, a day later on another machine, quietly picks floats.
Recording decisions somewhere every authorized agent can retrieve turns "we decided" into evidence the next agent can use. (This is one part of the broader coordination cost of AI coding agents.)
2.
Declaring work. "Who's on the payments refactor?" should have an answer without a chat poll.
Declaring the outcome, owner, and active scope up front helps prevent two people — and two agents — from doing the same thing, or from each assuming the other had it.
A next check-in also keeps abandoned work from looking active forever.
3.
Handoffs.
Work changes hands constantly.
Committed code has a durable record; live context is easier to drop.
The four items in the clause are worth carrying every time — there is a fuller handoff playbook if you want the detail.
4.
Review & merge.
Agents make it cheap to generate a lot of plausible change.
That raises the value of the human gate rather than lowering it.
Naming Git as the source of truth for committed code and a person as the accountable owner helps keep speed from turning into unreviewed risk.
5.
Conflict & escalation.
Two things collide on a team: edits and opinions.
For edits, a simple rule — a current claim gets priority, a later starter coordinates, and stale claims expire — can reduce avoidable merge work.
For opinions, the important word is person: an agent can surface a disagreement, but a human resolves it.
Making it real The agreement is tool-agnostic — you can run v1 on a shared document and a chat channel today.
Three clauses especially benefit from being current and machine-readable: the decisions in §1, the who's-on-what in §2, and the claims in §5.
A document works only when each client knows to load it and people keep its high-churn state current.
That is the part a shared layer like Vibsync is for.
At the start of a session, an authorized agent can call and to retrieve current decisions, declare work and claim a path before editing, and ask or answer across sessi