The AI Coding Team Working Agreement

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.

# Our AI Coding Working Agreement (v1)

## 1. Shared decisions
- Decisions that affect others live in: ______ (a shared memory, a decisions doc).
- Before a decision affects someone else's work, we record who decided it, what changed, and why.

## 2. Declaring work
- Before starting, we record the intended outcome, owner, and active paths in: ______.
- "In progress" includes the current state, next action, and next check-in — not just a status.

## 3. Handoffs
- When work changes hands — session, machine, person, or tool — we carry four things:
  recent decisions, current state and next action, open questions, and active or unmerged paths.

## 4. Review & merge
- Git is the source of truth for committed code. Every change is reviewed by a human before it merges.
- Agents propose; people approve. A named person owns the change and its follow-up after merge.

## 5. Conflict & escalation
- If active work overlaps, the first current claim gets priority; the later starter coordinates.
- We release claims when work stops and review stale claims after: ______.
- Unresolved disagreements go to: ______ (a person, not a tool).

_Revised: ______. This is v1 — change it as we learn._

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 onboard and recall to retrieve current decisions, declare work and claim a path before editing, and ask or answer across sessions. Because the state is exposed over MCP, Claude Code, Cursor, and Codex can access the same team context when each is configured and connected to that team. The shared memory supports §1; claims and the task board make §2 and §5 operational.

Keep it honest

An agreement is a norm, not an enforcement mechanism, and it works because people choose to follow it. A claim is advisory — it helps well-behaved agents stay out of each other's way; it does not lock a file. Git, review, and CI remain your real safety nets. And responsibility stays with people: an agent can act, but a named person owns the decision and its outcome.

Start with the five clauses above, fill in the blanks with the tools you already use, and put the agreement where teammates and their agents can retrieve it. Try Vibsync free during beta if you want §1, §2, and §5 available to every authorized agent across sessions and tools.

Vibsync is built by LOOSEDAYS Co., Ltd.