#Setting team guidelines for AI-assisted work
AddedEvery developer on a team now has an AI assistant one keystroke away, and without guidance each of them makes up their own rules: one pastes a customer's log bundle into a public chatbot, another won't touch Copilot because they're not sure it's allowed, a third lets an agent open twenty-file pull requests nobody can review. Team guidelines turn those private guesses into one shared answer to four questions: which tools, with which data, for which work, and who is responsible for the result.
DORA's research gives this a name. The DORA AI Capabilities Model (Google Cloud blog, 23 September 2025, from the survey of nearly 5,000 people behind the 2025 report) lists seven capabilities that amplify AI's benefits, and the first is a "clear and communicated AI stance": "Your organization's position on AI-assisted tools must be clear and well-communicated." The same post notes that the capability doesn't measure what the policy says, only that people know it. The other six are healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus and quality internal platforms, and most of them show up later in this chapter.
The mental model is a traffic-light map keyed to data, not to tools. Green: approved tools on company seats, for code and internal docs, with normal review. Amber: allowed with extra care, such as changes to device commands or authentication, which need a second reviewer and a note on what was verified. Red: never, whatever the tool, such as customer logs with personal data, credentials, or anything a contract says can't leave the company. Tools change every month; data classes and responsibilities don't, so a guideline written around them survives the next product launch.
What a good set of guidelines covers:
| Question | Example answer for a device-platform team | Why it's there |
|---|---|---|
| Which tools? | Copilot Business seats; the team's device-lab MCP server; nothing else without review | data terms differ between plans and vendors |
| Which data? | public and internal: yes; confidential: approved tools only; restricted (customer logs, credentials): never | the most common real incident is pasting the wrong thing |
| Which work? | anything, but device commands, auth, migrations and release config get a second reviewer | risk depends on the code area, not on who typed it |
| Who owns the result? | the person who opens the pull request, including agent-written code | "the AI wrote it" is never an answer in review |
| How is it disclosed? | an "AI-assisted" label and a "what I verified" line in the PR description | tells the reviewer where to look harder |
| Where do shared prompts and instructions live? | in the repository, owned by the tech leads | so everyone gets the same context and changes are reviewed |
| How do we learn? | a monthly session to share what worked and what bit us | the tools change faster than any document |
Guidelines are easier to follow, and to check, when the rules are data. Here is a team's policy written as a small table plus a function that answers "may I use this tool for this?", run against some typical requests. The policy and the people are made up for illustration.
// A team's AI guidelines as data, and a checker that answers "may I use this tool for this?".
// The policy is ILLUSTRATIVE: the shape is the point, not these exact rules.
const policy = {
tools: { // approved tools, each with the highest data class it may see
"copilot-business": { maxData: "confidential", surfaces: ["completions", "chat", "agent-mode", "code-review", "cloud-agent"] },
"device-lab-mcp": { maxData: "confidential", surfaces: ["agent-mode"] },
"public-chatbot": { maxData: "public", surfaces: ["chat"] },
},
dataOrder: ["public", "internal", "confidential", "restricted"], // restricted: customer logs, credentials, keys
reviewRequired: ["device-commands", "auth", "migrations", "release-config"], // code areas that always get a second human reviewer
};
function decide({ tool, surface, data, area, personalAccount = false }) {
const t = policy.tools[tool];
if (!t) return ["deny", `${tool} is not an approved tool; ask in #ai-tools to get it reviewed`];
if (personalAccount) return ["deny", "use the company seat, not a personal plan (different data terms)"];
if (!t.surfaces.includes(surface)) return ["deny", `${tool} is approved for ${t.surfaces.join(", ")} only`];
const rank = (d) => policy.dataOrder.indexOf(d);
if (data === "restricted") return ["deny", "restricted data never goes to an AI tool; use the redaction script first"];
if (rank(data) > rank(t.maxData)) return ["deny", `${tool} may see ${t.maxData} data at most, this is ${data}`];
if (policy.reviewRequired.includes(area)) return ["allow + review", `${area} changes need a second human reviewer and the AI-assisted label`];
return ["allow", "normal review"];
}
const requests = [
{ who: "Priya (Bengaluru)", tool: "copilot-business", surface: "agent-mode", data: "internal", area: "web-ui" },
{ who: "Sam (Austin)", tool: "copilot-business", surface: "cloud-agent", data: "confidential", area: "device-commands" },
{ who: "Arjun (Bengaluru)", tool: "public-chatbot", surface: "chat", data: "internal", area: "web-ui" },
{ who: "Dana (Austin)", tool: "copilot-business", surface: "chat", data: "restricted", area: "support" },
{ who: "Ravi (Bengaluru)", tool: "copilot-business", surface: "chat", data: "internal", area: "web-ui", personalAccount: true },
{ who: "Lee (Austin)", tool: "random-mcp-server", surface: "agent-mode", data: "internal", area: "tooling" },
{ who: "Meera (Bengaluru)", tool: "device-lab-mcp", surface: "chat", data: "confidential", area: "support" },
];
for (const r of requests) {
const [verdict, why] = decide(r);
console.log(`${r.who.padEnd(18)} ${`${r.tool}/${r.surface}`.padEnd(30)} ${r.data.padEnd(12)} → ${verdict.padEnd(14)} ${why}`);
}Priya (Bengaluru) copilot-business/agent-mode internal → allow normal review
Sam (Austin) copilot-business/cloud-agent confidential → allow + review device-commands changes need a second human reviewer and the AI-assisted label
Arjun (Bengaluru) public-chatbot/chat internal → deny public-chatbot may see public data at most, this is internal
Dana (Austin) copilot-business/chat restricted → deny restricted data never goes to an AI tool; use the redaction script first
Ravi (Bengaluru) copilot-business/chat internal → deny use the company seat, not a personal plan (different data terms)
Lee (Austin) random-mcp-server/agent-mode internal → deny random-mcp-server is not an approved tool; ask in #ai-tools to get it reviewed
Meera (Bengaluru) device-lab-mcp/chat confidential → deny device-lab-mcp is approved for agent-mode onlypolicy.toolslists the approved tools, each with the highest data class it may see and the surfaces it's approved for.dataOrderranks the classes frompublictorestricted. Everything else in the function follows from those two facts.- Priya uses Copilot's agent mode on internal web UI code: approved tool, approved surface, data within its limit, low-risk area, so
allowwith normal review. Most requests should land here; guidelines that say "no" to ordinary work get ignored. - Sam has Copilot's cloud agent work on device-command code with confidential data. It's allowed, but
device-commandsis inreviewRequired, so the answer isallow + review: a second human reviewer and the AI-assisted label. The risk comes from the code area, so the same rule would apply if Sam had typed every line. - Arjun's public chatbot may see public data only; internal code is a level above, so
deny, with the reason. Dana wants to paste restricted data (a customer log); that's denied for every tool, and the answer points to the redaction script from Security, licensing and data concerns. - Ravi uses an approved product on a personal account: denied, because personal plans come with different data terms (chapter 02's What happens to your code and prompts quotes GitHub's). Lee's unknown MCP server is denied with a way forward ("ask in #ai-tools to get it reviewed"). Meera uses an approved MCP server on a surface it isn't approved for.
- What this demonstrates: a policy that can be evaluated is a policy people can ask. Every "no" carries a reason and a next step, which is what keeps people inside the rules instead of working around them.
The table above becomes a short document in the repository, where people find it and where changes are reviewed. This one is illustrative; a real one also links the company's security policy and names an owner.
# Using AI assistants on the device admin team
Owner: tech leads (Austin + Bengaluru). Reviewed every quarter; last review 2026-10-27.
## Tools
- Use Copilot through your company seat only. Personal plans have different data terms.
- MCP servers: only the ones in `.vscode/mcp.json` in this repository. Want another? Open an issue
with what it can read and do; a tech lead reviews it within two working days.
## Data
- Never paste customer logs, call recordings, credentials or keys into any AI tool.
Run `npm run redact -- <file>` first and check the output.
- Device lab data is fine with approved tools.
## Work
- You own every line you merge, including what an agent wrote. Be able to explain it.
- Device commands, auth, migrations and release config: second reviewer, AI-assisted label.
- Keep PRs under 400 changed lines. Agents make big diffs easy; reviewers' attention doesn't scale.
## Sharing
- Prompts and instructions that work go in `.github/prompts/` and `.github/copilot-instructions.md`,
through a pull request.
- Bring one thing that worked and one that didn't to the monthly AI session.- Owner and review date at the top: a guideline nobody owns goes stale within one product cycle, and these products change monthly.
- Tools names the rule and the reason ("different data terms"), and gives a path for new tools with a response time. A guideline with no path to "yes" pushes people to use tools quietly.
- Data is the red light, stated as a concrete action (
npm run redact), not a vague "be careful". - Work repeats the ownership rule from the Tech Lead site's review topic and turns the risky areas into a label and a second reviewer. The 400-line limit matches the team's normal PR guideline: AI doesn't get a bigger budget.
- Sharing makes improvement part of the process: good prompts become files in the repository, reviewed like code, which is the subject of the last topic in this chapter.
The seven capabilities from DORA's AI Capabilities Model (Google Cloud blog, 23 September 2025) read like a checklist for a lead. What each could mean on a device-platform team:
| Capability | On this team |
|---|---|
| Clear and communicated AI stance | the one-page guideline, owned and reviewed quarterly |
| Healthy data ecosystems | device telemetry and support data that's accurate and documented, so tools built on it are trustworthy |
| AI-accessible internal data | the device-lab and docs MCP servers, instruction files that point at real patterns |
| Strong version control practices | small commits, easy rollback, instruction and MCP config under review |
| Working in small batches | the 400-line limit applies to agents too |
| User-centric focus | features judged by what room users and admins experience, not by how much code was produced |
| Quality internal platforms | CI, test fakes for devices, a lab that anyone at either site can use |
DORA presents these as capabilities that amplify AI's benefits, found from survey data; they're correlations, not a guarantee. They're useful as a structure for a plan, and as a vocabulary interviewers may recognise.
- Start from what people already do. Ask the team, anonymously, which tools they use and for what. You'll find the real risks (and the real wins) faster than by writing rules first.
- Pilot, then widen. One team for a few weeks, with a channel for questions, then everyone. The pilot is also your measurement baseline (Measuring whether it helps).
- Make "yes" cheap. Company seats provisioned for everyone, approved MCP servers preconfigured in the repository, a redaction script that's one command. Rules are followed when the compliant path is the easy one.
- Enforce what you can in tools. Organisation policies in Copilot (chapter 02's Copilot for teams), CODEOWNERS on instruction files, CI checks on MCP config. Keep the document for what tools can't check: judgement, ownership, disclosure.
- Revisit on a schedule. Quarterly, and whenever a tool changes its data terms or a new capability (agents opening PRs, MCP servers) arrives.
Completions and chat suggest; agents act. Agent mode runs commands in your terminal, the cloud agent pushes branches and opens pull requests, and MCP servers give either of them new reach. Guidelines written for "autocomplete" don't cover that, so add a short section for agents:
| Topic | Example rule | Why |
|---|---|---|
| Where agents may run | agent mode in your own checkout; the cloud agent on repositories the org has enabled | an agent acts with the permissions of where it runs |
| Commands | approve each terminal command unless it's on the team's read-only list (npm test, git status) | "always allow" on a shell is "always allow" on everything the shell can do |
| Secrets in the workspace | no .env with production values on machines where agents run; lab tokens only | an agent can read every file the folder holds, ignored or not (Security, licensing and data concerns) |
| MCP servers | only those in the repository's .vscode/mcp.json; new ones by review | a server's descriptions and results go straight into the model's context |
| Writes to devices | only through the team's device MCP server, which confirms with a person | the guardrails live there (chapter 07) |
| Agent PRs | same size limits, same review rules, a named human owner | GitHub doesn't count the requester's approval on cloud agent PRs |
A new MCP server request gets the same five questions every time: what can it read, what can it do, whose credentials does it use, where does it run (local process or someone else's service), and who maintains it (pin a version, review upgrades). Chapter 06's Trusting third-party servers goes deeper.
Classify each under the illustrative policy above: (a) asking Copilot Chat on a company seat to explain an internal React component; (b) letting Copilot's cloud agent change the retry logic for device commands; (c) pasting a customer's device log, as received, into Copilot Chat to find the error; (d) using a free personal assistant account for internal code because your seat hasn't been provisioned yet.
Show answer
(a) allow; (b) allow + review; (c) deny until it's redacted; (d) deny, and get the seat fixed.
- (a) Approved tool, approved surface, internal data, ordinary code area: green, normal review.
- (b) Approved tool and surface, but
device-commandsis a review-required area: allowed with a second reviewer and the AI-assisted label. The rule is about the code's blast radius, not about the agent. - (c) A raw customer log is restricted data: names, phone numbers, meeting titles, network details. Denied for every tool. After redaction it may become confidential, which an approved tool may see.
- (d) The tool may be fine, but a personal account has different data terms and none of the organisation's policies. The right fix is the provisioning delay, which is the lead's problem to solve quickly.
- The pattern: each answer follows from data class, code area and account, not from the product name.