Team playbook: who owns the agent

Goal: assign clear owners so agent tools do not become everyone’s vague responsibility.

Best for: small teams starting to share agents, skills, or connectors.

Shared agents fail socially before they fail technically. Nobody knows who can revoke access, who approves sends, or who gets paged at 2 a.m. when a weekly brief posts to the wrong channel. Write owners before you share connectors.

Every shared agent needs: a business owner (why it exists and what “good” means), a technical owner (how it is set up and how to kill it), and an on-call path for “it did something weird.” Link this to Logging what matters and Blast radius—ownership without logs is theater.

Why beginners skip this

Shared agents with no named owner feel fine until an incident lands and nobody knows who can kill the run. Vague ownership is how tools become everyone’s problem and no one’s job.

Habit this week (Asia/Shanghai): write business owner, technical owner, and kill-switch person on one page—date it before any shared agent goes live.

Step 1 — Name the two owners

Write human names, not only team names. A backup person is optional but worth one line.

For agent/job [name], propose business owner vs technical owner responsibilities in a simple table.
Include: who can revoke access, who approves external send, who updates the one-pager.
Use placeholders like Alex / Sam if real names unknown.

Weekly research agent that drafts a Monday brief from public sources.
PM = business owner; eng/ops = technical owner.
Table of duties including revoke + send approval + one-pager updates.

Step 2 — Incident mini-runbook

If a weird action happens: pause/kill → snapshot log → revoke if needed → tell stakeholders. Practice once on a dry run (fake wrong-send) so panic night is not the first rehearsal.

Write a 7-step incident mini-runbook when an agent may have sent/deleted wrongly.
Audience: non-engineers. Include who to ping and what not to delete.

Shared agent can open PRs.
Owner card: business · technical · kill-switch (who reverts OAuth).
Revoke for contractors not on card.

Step 3 — Monthly ownership review

Confirm owners still correct; rotate if someone left; re-read permissions. Fifteen minutes beats a surprise orphan agent.

Draft a monthly 15-minute ownership review agenda for shared agents.
Include: owner confirmation, permission skim, one incident lesson (or “none”).

Shared agent: "inbox triage helper" used by 4 people, no owner named.
Write three-line card: business owner · technical owner · kill-switch path (who revokes OAuth in <2 min).
Flag current risk of orphan access.

Names not teams

Owner = human name + backup. “Engineering” is how orphans happen.

Red flag

No named owner; everyone can approve writes; incident with no retrospective owner—fix before sharing the agent.

Save this card

Card: business owner · technical owner · kill-switch person · log place. No named trio → no shared agent.

1. What I shipped: ___ 2. What I refused: ___ 3. What I will never-do again: ___ (date: Asia/Shanghai)

• [ ] Tools/writes paused
• [ ] Refuse-line dated
• [ ] Artifact path saved
• [ ] Next link chosen (or stop)

Before you start

Write Done (checkboxes) and the human gate on paper before any run for “assign clear owners so agent tools do not.” Allow-list tools; leave send/delete off. Guide: agents-team-playbook. If you only have a blank practice box, stop and fetch the real job first.

• Goal in one line: ___
• Allowed tools: ___
• Forbidden: ___
• Human approve needed for: ___

How to use this week

For one shared agent/job, fill: business owner · technical owner · kill-switch path. Share the card in the team doc. Revoke access for people not on the card. on a live artifact—not a blank demo. Write one refuse-line and date the note (Asia/Shanghai). If you only skimmed agents-team-playbook, put 25 minutes on the calendar and redo once.

Close the week by quoting aloud the refuse line you actually used once. If you cannot, rerun Practice now and date the pass/fail (Asia/Shanghai).

Pitfalls

Temptation: skip the habit for agents-team-playbook to “save five minutes.”
Job still: assign clear owners so agent tools do not
Do the smallest correct pass: Done visible · one checkable artifact · Unknowns labeled [?].
Boundaries: draft only; no silent send; no invented metrics.
Return: the artifact + the refuse-line you said aloud.

Practice now

Live card: run one agent checklist item on a real job for “Team playbook: who owns the agent”—artifact path on Save (Asia/Shanghai).

Today: draft a one-page playbook: owner, approver, kill-switch person, log location. Get one teammate to confirm the owner line. Date it (Asia/Shanghai).

Today card (copy) — agents-team-playbook: 1. Artifact I will produce: ___ 2. Pass/fail check: ___ 3. Refuse-line if tempted to skip verify/send: ___ (date: Asia/Shanghai) 4. One never-do from this guide: ___

• [ ] Artifact path written
• [ ] Refuse example would say "yes"
• [ ] Dated Asia/Shanghai

One sentence takeaway

Name business owner, technical owner, and kill-switch before any shared agent goes live. This week: one dated one-pager with those three roles (Asia/Shanghai).

Next

Logging · Blast radius · Checkpoints · Subagents and handoffs · Define done and permissions

Pair with today: open the first Next link (agents-logging-what-matters) only after you dated a refuse-line for this guide (Asia/Shanghai).

团队手册：谁负责这个智能体

目标： 把责任写清楚，别让智能体工具变成「大家都管、等于没人管」。

适合： 刚开始共用智能体、skill 或连接器的小团队。

共享智能体往往先在「人情」上失败，再在技术上失败：谁能收回权限、谁批准外发、凌晨两点出怪事找谁，全都不清楚。先写负责人，再共享连接器。

每个共享智能体至少要有：业务负责人（为什么存在、怎样算好）、技术负责人（怎么搭的、怎么关掉）、以及「它干了怪事」时的联络路径。可配合记真正有用的日志与爆炸半径——没有日志的「有人负责」只是表演。

为什么新手跳过

共享 agent 却不写负责人，出事时没人知道谁能立刻关停。权责含糊，工具就会变成「人人有责、无人负责」。

本周习惯（Asia/Shanghai）：一页写清业务负责人、技术负责人、关停开关人——共享上线前先注明日期。

步骤 1——点名两位负责人

写人名，不要只写组名。备份人可选，但值得一行。

针对智能体/任务 [名称]，用简单表格列出业务负责人 vs 技术负责人职责。
包含：谁能收回权限、谁批准对外发送、谁更新一页说明。
不知真名可用 Alex / Sam 占位。

场景：真实工作（打开活材料）。
共享 agent：「收件箱分拣助手」，4 人在用，无人挂名负责。
写三行卡：业务负责人·技术负责人·关停路径（谁能在 2 分钟内撤 OAuth）。
标出孤儿访问风险。
约束：不编造事实；发送/删除前停下；未知处标「未知」。

步骤 2——事故迷你手册

若出现异常动作：暂停/关掉 → 留存日志快照 → 必要时收回权限 → 告知相关人。用演戏（假装发错）先走一遍，别把慌乱的那天当第一次彩排。

写 7 步事故迷你手册：智能体可能发错/删错时怎么办。
读者：非工程师。写明找谁、以及不要删什么。

场景：真实工作（打开活材料）。
共享「周报助手」写入团队 Drive。
填负责人卡+关停。撤不在卡上的人的权限建议。
约束：不编造事实；发送/删除前停下；未知处标「未知」。

步骤 3——每月所有权回顾

确认负责人仍正确；有人离职就轮换；再扫权限。十五分钟，好过突然冒出「没人管的孤儿智能体」。

起草每月 15 分钟的共享智能体所有权回顾议程。
包含：确认负责人、扫权限、一条事故教训（或写「无」）。

场景：真实工作（打开活材料）。
选一个共享（或快共享）agent。写三行负责人卡。确认谁能两分钟内关停。
约束：不编造事实；发送/删除前停下；未知处标「未知」。

人名不是组名

负责人 = 人名 + 备份。「工程」是孤儿的写法。

红旗

所有者空白；人人可批写操作。事故后无回顾负责人——补上。共用前必须写明关停人。先把检查项写到卡上，说不清就停，不带着糊弄往下跑。

保存这张卡

卡片：业务负责人 · 技术负责人 · 关停人 · 日志位置。三人角色写不清，就不上共享 agent。

开始前

打开你真正会用的账号/项目。准备好与「团队手册：谁负责这个智能体」相关的真实材料（不要空白练习框）。

默认姿态：在人确认发送/写入之前只出草稿。授予新工具前，先写一条带日期的拒做句（Asia/Shanghai）。

• 一句话目标：___
• 允许的工具：___
• 禁止：___
• 需要人批准：___

本周怎么用

本周一页玩法：所有者、批准人、关停人、日志位置。贴到共享处再共用智能体；所有者空白不共用。把过/不过写进笔记并注明日期（Asia/Shanghai）。

常见坑

任务：assign clear owners so agent tools
场景要点：Agent 运行前 Done/门闸写好；练习编号 4/4。
边界：仅草稿；未知 [?]；禁止悄悄发送；禁止编造指标。
返回：可检查产出 + 过/不过理由一行。

现在就练一次

实卡：用「团队手册：谁负责这个智能体」对真实任务跑一条智能体清单——产物路径进 Save（Asia/Shanghai）。

今天起草一页团队玩法并找一人确认所有者栏。过/不过与永不做注明日期（Asia/Shanghai）。只收藏标题算失败。

今日卡片（可复制）— agents-team-playbook： 1. 我要产出的成品：___ 2. 通过/失败标准：___ 3. 若想跳过核验/发送的拒做句：___（日期：Asia/Shanghai） 4. 本篇一条永不做：___

• [ ] 成品路径已写
• [ ] 拒做例句会说「可以」
• [ ] 已标注 Asia/Shanghai 日期

一句话带走

共享 agent 前写清业务、技术负责人与关停人。本周交出一页三人角色卡并注明日期。

下一步

记录 · 爆炸半径 · 检查点 · 子代理与交接 · 定义完成与权限

今日搭配：先为本篇写上拒做句日期（Asia/Shanghai），再打开下一步里的第一篇（agents-logging-what-matters）。