Team Working Agreement Template: The Rules a Team (and Its AI) Agrees To

A team working agreement is a one-page list of rules the team writes for itself and everyone, including new joiners, can read. It covers six things: working hours and how fast people reply, which meetings exist and why, where work is tracked, what done means, how decisions get made, and what AI assistants may and may not do. Each rule should be specific enough that you could tell whether someone broke it. Below is a template to copy, examples of norms that work and norms that do not, a way to review it, and where to keep the rules so that an AI assistant follows them too.

What a working agreement covers

Atlassian’s working agreements play↗ (opens in a new tab) defines them as “shared norms for how a team will work together, communicate, and collaborate, whether they’re in the same location or across multiple time zones.” The important word is shared: the team writes them, not the manager alone. For a small team, six areas are enough:

• Hours and response times: when each person is reachable, and how fast a reply is expected on each channel.
• Meetings: which recurring meetings exist, what each is for, and what happens asynchronously instead.
• How work is tracked: the one place tasks live, and what goes on a task.
• Definition of done: the checks every piece of work passes before anyone calls it finished.
• Decisions: who decides what, and where the result is written down.
• AI assistant use: what assistants may do on their own, what needs a person, and where their rules live.

Leave out anything the team would never argue about. A working agreement earns its place by settling the questions that otherwise come up every few weeks.

A team working agreement template

Team working agreement: [team name]
Agreed: [Month day, year]   Next review: [Month day, year]
Owner of this page: [name]

1. HOURS AND RESPONSE TIMES
   Core hours when everyone is reachable: [e.g. 10 a.m.-3 p.m. ET]
   Direct message: reply within [4 working hours]
   Email: reply within [1 working day]
   Urgent (production down, customer blocked): [phone / channel]
   Out of office: [where to say so, how far ahead]

2. MEETINGS
   [Meeting]: [day, length], purpose: [one line]
   No-meeting time: [e.g. Wednesday afternoons]
   Every meeting has an agenda by [time] or it is canceled.

3. HOW WORK IS TRACKED
   All work lives on: [board]
   A task says: the problem, who asked, and done-when
   Priority: [scale and what the top level means]

4. DEFINITION OF DONE
   - [e.g. reviewed by one other person]
   - [e.g. tested, and how it was tested is written down]
   - [e.g. the customer-facing note is updated]

5. DECISIONS
   Default: [e.g. the owner decides after asking]
   Recorded: [where], with who decided and why
   To reopen a decision: [new information, and who to raise it with]

6. AI ASSISTANTS
   May do alone: [e.g. draft, research, file tasks, write plans]
   Needs a person: [e.g. deploy, email customers, spend money]
   Never: [e.g. read customer payment data]
   Their standing rules live: [where every assistant reads them]

7. REVIEW
   Reviewed every [quarter] and when someone joins.
   Anyone can propose a change: [how].

Examples: team norms that work

The test for every line is whether two people could disagree about whether it was kept. “Be responsive” fails that test. “Reply to direct messages within four working hours” passes. Some rewrites below; for twenty more by area, see team norms examples.

• “Communicate openly” becomes “Blockers are posted in the team channel the day you hit them, not at the next standup.”
• “Respect people’s time” becomes “Meetings over 30 minutes need an agenda the day before.”
• “Keep the board up to date” becomes “A task moves to In Progress when you start it, and gets a comment when you stop for the day.”
• “Quality matters” becomes “Nothing is done until someone other than the author has checked it.”
• “Work-life balance” becomes “No messages expecting a reply outside core hours; schedule them instead.”
• “Use AI responsibly” becomes “Assistants may draft and file tasks; a person approves anything a customer will see.”

A filled example, for an invented six-person remote team across two US time zones:

Core hours: 11 a.m.-3 p.m. ET (8 a.m.-noon PT)
Chat: reply within 4 working hours. Email: within 1 working day.
Urgent: call the on-call phone. Nothing in chat counts as urgent.

Meetings: Monday planning (30 min), Thursday demo (30 min).
Standup is written, in the team channel, by 11:30 a.m. ET.
Wednesday afternoons have no meetings.

Work: every task is on the team board. No task, no work.
Priority 1-2 means this week; there are never more than five.

Done: reviewed by one other person, tested, and how it was
tested written on the task. Customer-facing changes need a note.

Decisions: the task owner decides after asking the people
affected. Anything customers will notice goes to Lee.
Every decision is written down with who made it and why.

AI assistants: may research, draft, file and update tasks.
A person approves deploys, customer email and anything paid.
Assistants never read the billing system.

Review: first Monday of each quarter, and when someone joins.

Definition of done and decisions: link, do not rewrite

Two sections of the agreement tend to grow into documents of their own. The definition of done comes from Scrum, where the Scrum Guide↗ (opens in a new tab) calls it “a formal description of the state of the Increment when it meets the quality measures required for the product.” Keep three to six checks in the agreement and put the detail elsewhere; definition of done examples has lists to start from.

The decisions section needs only the default method and where results are recorded. Choosing the method, and what a good decision record says, is the subject of decision-making frameworks for small teams.

The AI assistant section

Once a team uses AI assistants, the working agreement is where the everyday rules for them belong: what they may do alone, what needs a person, and what they never touch. Keep this section to a few lines. A fuller policy, covering who may connect which assistant, which data it may reach, who owns each one and when access ends, is set out in AI agent governance for small teams.

The line that matters most is the one about approval. The MCP specification’s section on tools↗ (opens in a new tab) says “there SHOULD always be a human in the loop with the ability to deny tool invocations.” Your agreement says where that line sits for your team: which actions a person confirms, and who that person is.

Be clear, too, about what writing a rule down does. Anthropic’s Claude Code memory documentation↗ (opens in a new tab) says it treats instruction files “as context, not enforced configuration.” The same is true of any assistant reading a rule: it will usually follow it, but a rule that must never be broken also needs a setting behind it, such as a permission the assistant does not have.

Writing it, and reviewing it

1. Draft before the meeting. One person fills in the template with how the team works today, not how it should.
2. Spend an hour on it together. Go section by section, and for each line ask: does anyone disagree, and could we tell if it were broken?
3. Cut. Anything nobody would ever argue about can go. A page people read beats three pages nobody does.
4. Agree a review date and an owner for the page.
5. Review quarterly, and whenever someone joins or the way you work changes. Atlassian’s play suggests revisiting when onboarding new team members, during reorganizations, and “when an agreement can no longer be upheld.”

At each review, look for the rules people quietly stopped keeping. Either the rule was wrong, and it should change, or it was right and nobody noticed it slipping. Both are worth knowing.

Keeping each rule where every assistant reads it

A working agreement in a shared document works for people, who read it once and remember it. An AI assistant starts each session knowing nothing, so it only follows the rules it is given every time. On fenbs, the rules half of the agreement goes on the Decisions and rules page. Each rule is a decision marked as a rule, which holds from now on, with who decided it, when and why. Rules are shown in full at the top of every connected AI assistant’s AI context, before anything else, so every assistant on the board reads them first, whichever tool it runs in.

• Rules: anything a person chose. “A person approves anything a customer will see” and “never deploy on a Friday” are rules. The decider is always a person; an assistant can write a rule down for the person it works for, but it never decides one.
• Context notes: facts that are simply true, such as where the staging site is or a trap in the billing code. These go in AI context, after the rules.
• Changes: to change a rule, record a new decision that replaces it. The old one is kept and marked Superseded, so the history of the agreement is on the page.
• Open questions: a rule the team has not settled yet can sit on the page as an open decision until someone decides it. When a rule needs formal agreement, named board members can be asked to sign it off.

The non-rule parts of the agreement, such as core hours and meeting times, can stay in your team’s document. fenbs does not track hours, response times or meetings, and it has no due dates or reminders; it holds the tasks and the rules, and records in History who changed what.