# The AI Coding Team Working Agreement > Source: > Published: 2026-08-11 00:37:58+00:00 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. 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. 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. **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](https://vibsync.com/blog/why-ai-coding-can-slow-teams-down).) **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](https://vibsync.com/blog/ai-coding-agent-handoff) 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. 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](https://vibsync.com/) 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](https://vibsync.com/agent-coordination), 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](https://vibsync.com/shared-memory) supports §1; claims and the task board make §2 and §5 operational. 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](https://vibsync.com/getting-started) if you want §1, §2, and §5 available to every authorized agent across sessions and tools. *Vibsync is built by LOOSEDAYS Co., Ltd.* *Originally published at https://vibsync.com/blog/ai-coding-team-working-agreement.*