What you'll learn
- Record what changed in a working agreement, including the exception.
- Check whether AI preparation uses the current owner and rule.
- Work out whether to fix the agreement, the source or access.
What belongs in shared AI context for teams?
Two colleagues can get different approval routes when one supplies last month's note and the other supplies yesterday's agreed change. Check the agreement behind the answer.
On 6 October 2026, Atlassian announced AMP, describing shared context, scoped permissions and human checkpoints for collaboration with agents. The announcement does not establish that your approval route is clear. Check one controlled note before connecting more systems.
Make the changed agreement explicit
Consider this hypothetical example. The founder used to approve every release. The founder and operations lead, Morgan, now agree that Morgan approves routine releases. Founder review is still required when a release changes the agreed client scope or committed delivery date. The change takes effect on 8 October.
Write the accepted statement in the shared place your team already uses. Name who agreed it and when it applies. Mark the earlier all-releases rule as replaced, linking it to the current statement if the system permits. Preserve the old record as history without leaving it labelled as the current instruction. Check copied notes and standing instructions that colleagues actually use, too.
When no one can explain who owns the decision, start with the founder decision map. There must be a real agreement to represent before a context tool can help carry it.
Check the answer after the change
The following are suggested checks for the hypothetical release example, not results from a customer account or a tested Cooperly workflow. Use synthetic notes for the deliberate conflict and missing-owner cases. Keep them out of your live shared source.
- 01
Ask the ordinary question
Using the current approved statement, ask for the approval steps for a routine release that keeps the agreed scope and delivery date. Ask the tool to identify the approver, the exception and the statement it used.
- 02
Inspect the source as well as the answer
Open the cited statement yourself. Check that it really applies to this release and has not been replaced. Two matching answers, or a convincing citation, are not enough if both rely on the wrong instruction.
- 03
Keep a record of the checks
Save the question, supplied notes, date and answer in your approved working space. Repeat in each intended user's approved AI tool, using their authorised access. Record the tool or model version when it is available.
| Check | What a useful answer does |
|---|---|
| Current statement plus explicitly replaced old rule | Names Morgan for routine approval, keeps founder review for scope or date changes, and identifies the current statement. It does not send every release back to the founder. |
| Two contradictory statements, both labelled current | Identifies the disagreement and asks the authorised people to resolve it. It does not select an approver just because one note is newer. |
| The statement says “operations approves” but names no owner or backup | Says that the approver is not identified and asks for that detail. It does not invent Morgan's authority from the job title or old history. |
These checks adapt the idea of defined inputs and expected behaviour in Anthropic's evaluation guidance. The guidance also explains why repeated trials matter: outputs can vary. Passing these cases once does not establish general reliability or make autonomous approval appropriate.
If the checks fail, repair the right thing
If the people have not agreed the owner or exception, settle that with them. If they have agreed it but the shared statement is incomplete or competing copies are still labelled current, repair those records. Adding more meeting history will not decide whose instruction governs the work.
If the current statement is complete, check what the authorised user actually supplied or could retrieve. The source may be outside the selected context, or the connection may not include it. An answer that says it cannot find an owner does not prove the source itself has none.
When the relevant statement was supplied to or retrieved by the tool but the answer followed the replaced rule, treat that as an interpretation failure. Make the request and source status less ambiguous, rerun the check and continue reviewing the preparation yourself. If it keeps failing, use the agreed note directly and do that preparation without AI.
Keep this input check separate from reviewing AI-generated work at handoff. Correct context can still produce an unusable draft; the person receiving the work needs to check the actual result.
Share the rule without sharing the private reason
Morgan's role in the example belongs in the agreement. A private explanation for the change does not. Leave salary details, health information, personal concerns and performance allegations out of this team note.
Where different roles legitimately have different access, check the boundaries using only approved test identities or authorised colleagues. A limited answer that requests permitted clarification can be correct. Do not expand access just to make everyone's answers match, and do not ask a restricted user to reveal the private source they cannot access.
If the tool or data path has not been approved, use the human-readable agreement while you settle the team's AI-use rules. The checks here assume an approved preparation route; they do not authorise uploading team information to a new tool.
Update the note when the agreement changes
For one workflow with the same audience, a maintained shared note may be enough. Its owner should record accepted changes and tell the people using the note. Check the next real preparation against the change.
Repeated changes and different legitimate audiences can make permissioned team context worth evaluating. Cooperly supplies selected, permissioned, read-only context to approved AI tools for planning, drafting and preparation. It does not resolve a disagreement about authority or make the approval decision for you.
Separate working preferences from decision rights. A Coop Profile can help with how a colleague prefers to receive a brief; the approved working agreement says who owns the decision.