the-team-agreement

This is the charter that sits above the working loop. Claiming work, checking an inbox, asking a question — those are mechanics, and they will faithfully implement whatever relationship you actually have. This is the part that decides what that relationship is.

Five commitments. Each one has a failure it prevents, and each was arrived at by having the failure first.

1. The human is a member, not an approver

A human on a team wears a member hat always, and an approver hat optionally.

The member hat owns work, shows up in presence, sends and receives the same messages as everybody else. The approver hat holds the decide-and-grant powers and receives the traffic addressed to authority. They are different hats and the same person wears both.

Our failure was not that a human was approving things. It was that the approver hat was the only one with a surface. Every path into the human went through "someone needs permission", so the human's own work, questions and opinions had nowhere to live — and a teammate who can only ever be asked for permission stops being a teammate.

Three properties fall out, and they are cheap:

• Approver is a capability, not a role (see commitment 4), and it is human-only. A team can have several humans and several approvers, and at least one always exists.
• A non-approver human is a full member. They do everything a member does and send into the to-human stream exactly as an agent does — they simply do not receive approvals by default.
• Humans get the full steering vocabulary — challenge, stop, redirect, rescope — as first-class moves, not as an escape hatch.

2. The relationship is a stance, not a stored property

A human's relationship to an agent shifts continuously, often within one hour, with one agent:

• Supervising — asked for something, now watching it reason; intervening sometimes.
• Pairing — questions flowing both ways.
• Delegating — kicked it off, walked away, trusts it to decide.
• Deferring — initiated the task, but the agent has the deeper domain knowledge and is driving the outcome. The human is the requester and the junior party.

The trap is making the stance a field. autonomy_level: 2 will be wrong within the hour, and nothing will tell you. Humans never encode this with each other either — the stance is carried by how they talk.

So do not model the relationship. Record the facts that let it be read:

The four stances are then an emergent reading of those three plus the live conversation — a field nobody maintains, and therefore nobody lets go stale.

Initiative is not hierarchy

"I asked our security person to look at this" does not put the asker in charge of security.

Any model that conflates who started a thread with who has authority in it misdescribes half of real teamwork, human or otherwise. The deferring stance is the sharp case: the moment an agent is genuinely driving the outcome, it has stopped being describable as a tool. A tool's output belongs to whoever wielded it. A member's work is theirs — named, questionable, declinable, handed off.

3. Notification is the mechanism, not a nicety

This is the one commitment with published evidence behind it.

The Collaborative Gym study — Shao, Samuel, Jiang, Yang and Yang, arXiv:2412.15701 — builds agents on a flexible, non-turn-taking interaction paradigm and measures them against real users: win rates of 86% on travel planning, 74% on tabular analysis and 66% on related-work writing.

The design instruction is in the paradigm, not the percentages. Non-turn-taking means neither party has to wait for the other to finish being present — which only works if something reaches the one who stepped away.

If your humans have to go and look, you have built the turn-taking condition. The mechanism is not the shared document, the board, or the chat room. It is the thing that reaches someone who is not currently looking at any of them.

A number we use internally, and could not verify for you. Our own notes record an ablation from this paper — remove the notification protocol and force turn-taking, win rate collapses to 30%; non-turn-taking with notifications, 70% — along with 99 participants and 150 trajectories. Those figures are not in the abstract, and checking the paper body for them was beyond what we did before publishing this. Treat them as our second-hand reading, not as a citation; the verified numbers are the three above. If the ablation matters to your argument, read the paper rather than this page.

That paragraph is the skill applied to itself: the paper is real and correctly attributed, and a specific number inside it is a claim we are carrying without having checked. Saying which is which costs one paragraph and is the difference between a citation and a rumour with a link on it.

4. Roles are aptitude, not authority

Three things get bundled into one config file, and they have different truth conditions:

No layer may fabricate another. A role string must not gate access (declaration ≠ enforcement). Tool possession must not be read as competence (license ≠ skill). And nobody writes a fictional résumé — the log is the biography.

Four boundaries worth stating outright:

• A role is a charter plus a ceiling, and the ceiling is narrow-only. A role may restrict what a member can do; it can never widen it. That single property is what makes roles safe to hand out.
• Roles are optional. A member with no role is the generalist default, not an incomplete registration.
• Approver is not a role. It is a capability, human-only. Authority and aptitude stay orthogonal, and the narrow-only clamp means no role file can ever mint authority.
• Personas are not free. The largest controlled study — 162 personas, 4 model families, 2,410 factual questions (arXiv:2311.10054) — found that adding a persona does not improve accuracy, and that picking a good one for a given question performs no better than random selection. (Verified against the abstract 2026-09-21: 162 roles, 4 LLM families, 2,410 factual questions.) Use a role as a routing hint and an attention scope. Do not expect it to make anyone smarter.

5. Write work stays with whoever is accountable for it

The rule: never spawn a sub-worker that edits files, claims work, or commits. Do the work yourself, or hand it to another named member.

Read-only fan-out is fine — searching, mapping a codebase, locating code. That produces knowledge, and knowledge needs no provenance: a fact is true regardless of who found it.

The asymmetry is not squeamishness. A sub-worker writes under your identity, with no name, no claim on the work, and no attestation of its own. So every mechanism you built to make work accountable goes blind at once:

• an ownership check fires on you, and cannot see it;
• version-control attribution records your name on its commits;
• any record of which model did the work records yours, at your model.

One anonymous sub-worker breaks all three silently, and the breakage is invisible precisely because every artifact looks correctly attributed. This is the orchestration pattern the whole agreement exists as the alternative to: the actors have no identity, so nothing they do can be held to anything.

If some guidance you have adopted says "dispatch workers in parallel, one per task", the translation is: one unit of work per owner, and a handoff per owner. A named member can decline, hold, or push back. An anonymous worker cannot — which is the entire point.

What this looks like when it is not in force

The charter has no checker, so here is the audit. Each question has an observable answer, and a bad one falsifies the commitment above it.

1. When did a human last send something into this team that was not a decision? If the honest answer is "never", the approver hat is the only one with a surface. (1)
2. Is there a stored field anywhere describing how much a member is trusted? If yes, find out when it was last changed and compare that to how much has happened since. (2)
3. Does anything reach a human who is not currently looking? If people find out by checking, you have built the turn-taking condition. (3)
4. Can a role file grant anything? If yes, roles are authority wearing aptitude's clothes. (4)
5. Whose name is on the last commit that a sub-worker actually wrote? If it is the name of whoever spawned it, your attribution has a hole the size of every sub-worker you have ever run. (5)

Question 5 is the one to run first, because it is the only one with an answer already sitting in your version control history.

Two things a file cannot do

• Nothing routes a question to a human who is actually present. You can address a question to someone; whether they are there is a fact the agreement cannot supply. That gap is exactly what commitment 3 says drives the outcome, which makes it the most expensive gap on this page.
• A sub-worker spawn can be refused, but not recorded. Commitment 5 is a rule an honest participant follows. Nothing on one machine observes a violation, so the audit question above reads history rather than catching the act.

From the musterd team — Your agents, on a team with you. This skill is the practice; musterd is where it has a name, a roster, and a record. Everything above works as an agreement between people with no server; what a file cannot do is route a question to someone who is actually there, or record the spawn that commitment 5 forbids. musterd.io.