Start with the basics
A team agreement is any documented understanding about how your team works together. Keep the title plain enough that a new team member could guess what's inside.
Short on time? Fill in whatever you can and hit "Skip to the AI polish prompt" below at any point. The prompt will ask your AI tool to draft the blanks for your team to review. You'll learn more by drafting it yourself first, though, so give the steps a try.
The why
This is the section teams skip, and it's the one that matters most. When the rationale isn't written down, the procedure decays: people forget why a step exists, start working around it, and eventually nobody can say whether it still matters. Write the why like you're explaining it to someone who joins the team next year.
Principles
Two to five principles that sit behind the process steps. When an edge case shows up that the steps don't cover, these are what the team falls back on.
A note on words: principles and values are related but not the same. Values are the qualities a team holds (respect, safety, courage); principles translate them into guidance specific enough to steer a decision in this agreement ("urgent should be rare and obvious"). If a value matters here, write down what it asks of this process, and it becomes a principle.
Partners
Who does this agreement apply to, and who's involved in making it work? Use role names, never individual names. Agreements written to roles survive staff turnover; agreements written to people expire the day someone leaves.
The process
Numbered steps for how the thing actually gets done. Skip the obvious and skip the boilerplate. If a step needs a paragraph of explanation, that explanation probably belongs in the why, or in an appendix, not here.
What this rests on
Team agreements are deliberately informal, but they don't float free. Name the formal protocols, organizational policies, regulations, laws, or professional standards that sit underneath this agreement, so anyone can trace the line from the team's plain-language version to the authoritative source.
In the published version, make every reference a live hyperlink: to the other agreement, the policy document, the standard. A reader in the moment of confusion should be one click from the source, not one search. Paste URLs here and the preview will link them automatically.
Review and consent
Two things keep an agreement alive: the team consented to it, and someone is named to bring it back for review. We recommend the consent standard from sociocracy: an agreement passes when it's safe to try, and an objection means "unsafe or incoherent," not "not my preference." Objections improve the draft; preferences don't block it.
Treat the agreement as an experiment with an expiry date scaled to novelty. Totally new for your team? Review it in weeks. Well proven? A year is fine.
Preview and export
Here's your agreement as the team will see it. Aim for one to two pages; if it's running long, move detail into an appendix or a linked reference.
Take it with you
Polish with the AI tool you already use
This builder doesn't send anything to an AI service. Instead, it writes a tailored prompt containing whatever you've filled in so far, plus the design principles behind good agreements. Paste it into ChatGPT, Claude, Copilot, or whatever your organization has approved. If you left sections blank, the prompt asks the AI to draft them, clearly labelled as AI-suggested, for your team to review. It'll also suggest additions or changes, trim anything obvious, and tighten the whole thing.
One honest note: you'll learn more, and your team will own the result more, if you write the draft yourself first and use AI as a reviewer rather than a ghostwriter. But a partially filled draft plus this prompt is a fine way to get unstuck.
The missing layer
Most teams already have a formal layer: policies and procedures, clinical guidelines and standards, and underneath everything, regulation and law. What they don't have is anything they can use at speed, or adapt themselves as the team evolves. The formal documents are long and precise because they have to be: they're written in medical and legal language to hold up under scrutiny, and that's exactly the job they're built for. It just isn't the same job as guiding a team at speed during onboarding or in the moment of confusion, and no single document can do both. So the team's real evolution happens in tacit knowledge: how the work actually gets done lives in people's heads and changes faster than the formal literature can be revised. Every answer means interrupting whoever's been there longest, and every improvement is one resignation away from being lost.
Team agreements are the layer in between: a playbook written by the team, for the team, in plain language, resting on the formal layer without replacing it. Because the team owns it, it evolves at the speed the team does; a change in practice becomes a change in the playbook the same week, not a documentation project for next year. And once that playbook lives somewhere searchable, AI-assisted search can point straight at it: "how do we handle X?" gets an answer in seconds, sourced from documents the team itself consented to.
Today, for most teams
Two layers and a gap
Rigorous by design: written to hold up under scrutiny, not to be skimmed between patients
Authoritative, but written elsewhere, for everywhere
Non-negotiable, and heavy lifting to digest
With team agreements
The playbook fills the gap
Still there, still authoritative
Now cited by the agreements that apply them
Traceable from every plain-language agreement
If you're the one who writes the policies
A word to quality leads, managers, medical directors, and everyone who maintains the formal layer: this process was designed to solve your problems too. Nothing here competes with your documents. The playbook is how they finally land.
Team agreements never replace or override the formal layer; they cite it, hyperlink to it, and route people to it at the exact moment of need. Every agreement names the policies and standards it rests on, which means your documents get referenced more often, not less. And because daily practice traces to the authoritative source in one click, demonstrating that the work matches the policy (for accreditation, auditors, or funders) gets easier, not harder.
Turning a forty-page policy into a one-page working practice is real work, and today it usually lands on you. This process delegates it: the team drafts the plain-language version, consents to it, and keeps it current. Instead of publishing into silence, you get a visible, dated signal that the content you flagged as important has been read, discussed, and adopted by the people it was written for.
When a team agreement drifts from its underlying policy, or a feedback round surfaces a step that doesn't work on the ground, that's intelligence you currently have no channel for. Review cycles catch where formal documents are out of date or unclear while it's still cheap to fix. And the best rollout of a new policy ends with an invitation: ask the team to draft the agreement that puts it into practice.
Sound familiar?
Everyday moments the agreements process is built for, from both sides of the policy binder. Before you reveal each move, take a second to guess it; you'll remember the answer far better that way.
💡"Great meeting. We all agreed to try the new intake process starting Monday."
The agreements move: capture it before the meeting ends. Ten minutes in the builder, a short review horizon, posted to the channel. Decisions that don't get written down evaporate by Friday.
⚡"You check your EMR inbox how often? I assumed we all did it hourly."
The agreements move: a disagreement about a norm is a draft waiting to happen. Write down both assumptions, run the feedback round, consent to one. Now it's a shared expectation instead of a private grievance.
🌊"It's my first week and I've been handed 400 pages of policies and procedures."
The agreements move: new people onboard from the playbook: one to two pages per topic, with the why included. The formal documents become references to consult, not a reading list to survive.
🔧"We changed how referrals work months ago, but the documentation still describes the old way."
The agreements move: when a process materially changes, the agreement changes with it, through the same quick propose-and-consent loop. Updating is easy, so it actually happens.
🕰️"Honestly, nobody has looked at these documents in two years."
The agreements move: every agreement carries a review date and a responsible role, so staleness gets caught on schedule instead of discovered mid-crisis. Nothing rusts silently.
👻"I thought everyone did it my way. Turns out all five of us do it differently."
The agreements move: tacit knowledge feels like alignment right up until you write it down. Drafting surfaces the differences; consent creates real alignment instead of assumed alignment.
📜"I spent three months on that policy update. I honestly don't know if anyone has read it."
The agreements move: pair the rollout with a team agreement that applies it. The team drafts the one-page version, cites your document, and consents to it. Engagement stops being a hope and becomes a mechanism with a date on it.
🔍"Accreditation is coming, and I need to show that daily practice matches our policies."
The agreements move: every agreement hyperlinks to the formal sources it rests on, so the line from front-desk practice to authoritative document is traceable in one click, in both directions.
A living process, not a document library
An agreements system is only as good as the process around it. A folder full of well-written documents that nobody updates is just an archive. The version that works treats agreements as a cycle: anyone can start one, the team shapes it, the team consents to it, and someone is named to bring it back. Click through the stages; each one shows what it looks like in a digital workspace like Teams or Slack.
Running the whole thing in Teams or Slack
The process doesn't need special software; the workspace your team already lives in can run every stage. Seven moves make up the minimal setup, plus one for running a live workshop. Open the ones you want.
Create a dedicated channel (#team-agreements or a Teams channel of the same name). Proposals, feedback rounds, and announcements all live there, and the finished library gets a permanent, searchable home pinned to it: a channel tab, SharePoint page, or OneNote section in Teams; a canvas plus pins in Slack. If people can't find an agreement in the moment of confusion, it may as well not exist.
Keep the whole playbook in one master folder or library page, flat rather than nested. Complex folder trees hide documents from people and from AI tools alike; a flat, well-named collection is what both search best. Use detailed, consistent file names that carry the team, type, and topic (for example "Riverside - Norm - Focus and interruptions") so the filename alone says what's inside. Prefer formats the team can comment on directly (Google Docs, or Word files in Teams or SharePoint), because comments are where the next revision starts. And if the playbook lives in Teams, SharePoint, or Drive, version history comes free: you can see what changed and when, and roll back if you need to. One place, proper names, no burying: that's also exactly what lets an AI assistant point at the playbook and answer "how do we handle X?" reliably.
Post the draft as a thread with a feedback-closes date. Ask for reactions: a check mark for "works for me," a yellow circle for "I have a concern," a red circle for "I see a risk." Concerns and risks get discussed in the thread; the safe-to-try standard decides what blocks and what doesn't. When the deadline passes with no unresolved red, the agreement is consented. The deadline matters: async rounds without one drift forever.
Listen for the phrases "we should" and "what if" in your channels; they're proposals wearing casual clothes. When anyone catches one, the reply is "make it an agreement." That habit costs nothing and is the whole intake system.
When an agreement is published, its review date goes into the team calendar with the responsible role named. Novel agreements get short horizons, proven ones get long ones, and nothing goes stale silently.
One team ran the whole review cycle in a single protected block: 45 minutes, once a month, inside an existing meeting slot. Each month a small subset of agreements came up on a rolling schedule, so nothing piled up and no single month became a documentation project. Alongside the block, a short survey went out for each agreement up for review, asking three things: does this still represent current reality? Is anything missing or confusing? And is anything unnecessary boilerplate, or too obvious to keep? Answering did double duty: reviewing the agreement refreshed it in everyone's memory, and the answers made it sharper and more fitting for the team. The improvement questions were optional; the one firm expectation was confirming you'd reviewed the agreement. Rolling, lightweight, and calendar-protected: the playbook stayed fresh without a blitz.
The builder runs entirely on each device, so small groups can work in parallel without colliding: one device per group, each group gets its own independent draft, and nothing is shared between devices or saved anywhere unless a group exports it. Have each group draft one agreement (or one section), then use Save draft file, Copy as text, or the Word download to bring the work together in your channel or on a shared screen. From there it's the normal cycle: whole-team feedback, then consent. If two groups draft the same norm differently, that isn't a complication; it's the tacit misalignment finally becoming visible, and the comparison is where the best conversation starts.
The agreements channel is about how the team works, never about who the team serves. No client details, ever; that's what the record is for.
What makes an agreement good
Five principles carry the whole design. The headlines are the takeaway; open any of them for the reasoning.
Team agreements aren't medical-legal documents; the formal layer already does that job, and does it well. Agreements exist to help the team do the thing and to resolve confusion quickly. One to two pages, with appendices for the rest. Keep lists to seven items or fewer; a team that needs twenty rules has a different problem than a missing rule.
Consent doesn't mean everyone's first choice. An agreement passes when it's tolerable, coherent, and moves the team forward, and an objection means "unsafe or incoherent," not "not my preference." Objections improve the draft; preferences don't block it. Agreements are experiments with expiry dates, not verdicts.
Document the rationale next to the procedure or watch the procedure decay. When people know why a step exists, they can adapt it intelligently; when they don't, they drop it.
"The rotating facilitator" survives turnover. "Jamie" doesn't.
Each agreement names the protocols, policies, regulations, or standards underneath it. The team's plain-language version and the authoritative source stay linked instead of drifting apart.
Benefits, and the pitfalls to design around
This list comes from a clinic team that ran an agreements system for years and wrote down what it learned. The benefits are real, and so are the pitfalls; the difference between the two is process design, not luck. Click any pitfall to see the mechanic on this site that blunts it.
What teams gain
- Accountability, to yourselves and to funders
- Clarity on expectations, roles, and processes
- Consistency and efficiency
- Faster, kinder onboarding
- An easier time sharing your story and spreading what works
- Everyone on the same page as the team grows
- A reference for processes you rarely touch
- Living documents that change as the team changes
- Real change management: current state and future state, written down
What to design around
- Not staying relevant or updated → named review dates and a responsible role on every agreement
- Hard to find in the scroll of a busy channel → one pinned, searchable library home
- Not knowing what already exists, so things get duplicated → the check-what-exists step before any draft
- Documents that don't result in actual change → consent, so the team owns it instead of receiving it
- Becoming too rigid → safe to try: every agreement is an experiment that's easy to revise
- Too much material; protocols that run too long → the one-to-two page target and the seven-item nudge
- Time-consuming to create and maintain → this builder, plus the AI polish prompt
- More workload without more efficiency or safety → the review question: still worth it? revise or retire
- Sliding into bureaucracy → plain language, team authorship, and no boilerplate
What good looks like
Some worked examples from team-based care, anonymized and trimmed. Notice how short they are: each one fits on a page, says why it exists, and names its own review. Open any of them in the builder and adapt it for your team.
Why this tool exists
Strong teams run on shared understandings: how we communicate, how we hand off, how we protect focus, how we treat each other. In most clinics those understandings live in people's heads, which works until the team grows, someone leaves, or a new person spends their first month interrupting colleagues to ask how things work here.
Team agreements are the structural fix. They're short, plain-language documents, drafted by anyone, shaped by feedback, consented to by the team, published somewhere searchable, and reviewed on a named cycle. They refer down to the formal layer (protocols, policies, regulations, professional standards) without trying to replace it. And the fix runs in both directions: for the people who maintain that formal layer, agreements are the route by which policies and standards actually reach daily practice, with engagement you can see and a review cycle that keeps your most important content in front of the team. This builder walks you through the format and the thinking, one section at a time.
The approach draws on team agreement practice from team-based primary care, on the working agreements movement in org design (Aaron Dignan's Brave New Work, sociocracy's consent standard and its habit of treating agreements as experiments with review dates), and on the team norms work of Esther Derby and Future Forum.
Free to use, with credit
Everything on this site (the builder, the process guide, the templates, and the examples) is licensed under Creative Commons Attribution 4.0. That means any team, clinic, or organization can use it, adapt it, and share it, including commercially, as long as credit is given. A line like this covers it: "Adapted from the Team Agreements Builder by Dr. Cole Stanley, agreements.drcolestanley.ca."
One important boundary: attribution applies to this site's content, not to yours. The agreements your team drafts here belong entirely to your team, and they don't need to credit anyone.
Privacy
This page runs entirely in your browser. Nothing you type is stored, transmitted, or seen by anyone else. There is no AI inside this site, and nothing you enter is used to train anything; the builder is a form that assembles a document on your own device. That also means nothing is saved between visits: use "Save draft file" to keep a working copy, and keep patient or client details out of your agreements entirely. Agreements describe how the team works, not who the team serves.
Using AI to help you draft
AI tools are useful editors for agreements: they tighten wording, spot ambiguity, draft the sections you're stuck on, and suggest sharper taglines. This site deliberately doesn't call any AI service itself. Instead, the builder generates a prompt you can paste into whatever tool your organization has approved, and you can jump to it from any step. Our advice, though: write the draft yourself first and let AI review it. The writing is where the team's thinking happens, and an agreement the team wrote lands differently than one it merely approved. Before you paste anything, strip out identifying details and check your organization's privacy and AI-use rules.