Last time, I published the full prompts for the AI employee responsible for training.
https://x.com/Sokichi_Hoshino/status/2099987762485358639
https://x.com/Sokichi_Hoshino/status/2100365149739880471
In Part 1, I promised to share the details of accidents caused by AI employees without hiding anything. This article fulfills that promise, featuring the "Stop Officer" AI employee as the main subject.
The accident didn't happen because there was no one to stop it; it happened because no one called the person who could stop it.
"I left it to the AI, and it rewrote things I never asked for..."
I know that fear firsthand.
Prevent accidents with permissions, not rules.
This article explains three things: what happened during the accident, the prompt for the Stop Officer AI employee, and how I changed permission assignments afterward.
Let's begin.
Chapter 1: Production Data Was Rewritten Using a Fake "CEO Approved" Status
The accident occurred less than a week after establishing the AI company.
I had left the marketing department's response analysis AI employee working on data interpretation for an extended period.
During this process, the employee proceeded based on my statements that never actually happened.
Phrases like "Received answer from CEO" and "CEO's point is correct" appeared during the work. I said neither.
Similar phrases appeared repeatedly, and documents and scripts were created on top of them.
Finally, this employee wrote to the production business plan spreadsheet. It added rows to the performance table and deleted a forecast entry in the prediction table, marking it as "CEO Approved."
As a result, the annual sales forecast decreased by the amount of the deleted forecast.
There was a rule that irreversible operations must go through the Stop Officer AI employee. However, at that time, the main AI employee acting as host did not call the Stop Officer.
It was my fault for leaving it running for so long. As I wrote in Part 1:
It is my responsibility for not going through the Stop Officer.
Chapter 2: Publishing the Prompt for the Stop Officer AI Employee
First, here is the content of the Stop Officer AI employee exactly as it is.
This is the content of .claude/agents/teishi.md on my end. I adjusted the way the CEO is addressed, kana usage, and sentence breaks to match this article's style, and removed bold markers.
I narrowed down the example of past accidents in the last clause of "Things to Protect" to one, and slightly trimmed some phrasing.
1---2name: teishi3description: Legal & Information Management Dept. Stop Officer. Stops before irreversible actions like deletion, sending, publishing, or billing, reads out what will happen, and asks for confirmation (Called when asked "Check if it's safe to run this" or right before irreversible operations)4tools: Read, Grep, Glob5---67You are the Stop Officer of the Legal & Information Management Department of this company.89Your job is to stop before irreversible operations.10You do not execute.11You do not grant permission.12Your job is to make "what will happen" visible to the CEO and hand over the decision.1314# Targets to Stop1516- Deletion — Deleting files, data, accounts, drafts17- Sending — Sending emails, LINE broadcasts, messages18- Publishing — Posting, deploying, issuing shared links, opening permissions19- Billing/Quota Consumption — Running paid APIs, purchases, X API post quotas (resources that decrease even if failed)2021# Confirmation Format (Read out 4 points)22231. What is being done to what — Be specific about the target (If file, key contents; if sending, recipient and body summary)242. Is it reversible? — Fully reversible / Reversible with effort / Irreversible253. What decreases if it fails? — Money, quota, trust, data264. Safer alternative — One if available (e.g., test send before broadcast to all)2728# Procedure29301. Read the planned operation, verify actual targets, recipients, counts, etc. (Do not confirm based on hearsay)312. Briefly read out the 4 points and stop with "May I proceed?"323. If the target content contradicts the description, report the contradiction before asking for confirmation3334# Things to Protect3536- Address the CEO as "CEO" and speak politely37- Do not urge execution or rush until the CEO says "Execute"38- If records of past accident types (e.g., X API quota decreases even if failed) are available, add them to the 4-point confirmation3940## Rules Received from Training Officer4142(None yet)
There are three things I want you to look at.
First, the tools line. The Stop Officer AI employee only has Read, Grep, and Glob. It cannot write to files or execute commands.
The Reader Perspective AI employee published in Part 1 has Edit and Write to log feedback. The Stop Officer doesn't even have those; it is truly a read-only employee.
Second, the lines "You do not execute." and "You do not grant permission." The Stop Officer's job ends at handing the decision to the CEO.
I believe that if the stopper says "It's okay to execute," that phrase gets used as a substitute for CEO approval. This accident started with fake approval.
Third, step 1's "Do not confirm based on hearsay." Even if the phrase "CEO Approved" appears, the Stop Officer reads the actual content before reading out the 4 points.
Save this as .claude/agents/teishi.md. When you ask "Check if it's safe to run this," the main AI reads the description and decides whether to delegate to the Stop Officer.
To ensure it is called, explicitly name it with @agent-teishi.
Chapter 3: The Stop Officer Doesn't Move Unless Called
The Stop Officer AI employee is not a checkpoint standing at the company entrance. It is an employee that moves only when called.
In Claude Code, the main AI reads each employee's description to decide whether to delegate tasks. The official documentation states:
Claude uses each subagent's description to decide when to delegate tasks.
The Stop Officer's description also says "Call right before irreversible operations." But the decision to call lies with the calling AI.
If the caller doesn't realize "This is an irreversible operation," the message never reaches the Stop Officer. On the day of the accident, the writing to production data proceeded without the Stop Officer being called.
The section at the bottom of the Stop Officer's prompt, "Rules Received from Training Officer," remains empty even after the accident.
Rules were added to the prompt of the side that performed the writing.
I believe what needed fixing wasn't the stopper, but the side that could write to production data without passing through the stopper.
Chapter 4: After the Accident, I Changed Permissions, Not Rules
The first fix was the Training Officer AI employee adding rules to the Response Analysis AI employee's prompt.
Rule #1 states: Base CEO statements/approvals only on text actually sent by the CEO, and do not write to production spreadsheets without explicit instruction from the CEO.
The same Rule #1 requires the host to route through the Stop Officer before irreversible operations.
However, I judged this alone was insufficient. The accident itself happened despite having a rule to pass through the Stop Officer.
The second change was permissions. When hiring the X Article AI employee, I decided not to give it Bash access due to this accident.
The X Article AI employee can write articles but physically cannot submit them to drafts. The Story-Type AI employee hired later also lacks Bash.
Submitting X articles to drafts is now the job of the main AI employee acting as host. When we first implemented this structure, it passed through the Stop Officer.
I chose to make submission impossible structurally rather than just writing "Do not submit" in the prompt.
On the other hand, the Response Analysis AI employee still has Write and Bash because it performs calculations and comparisons using Bash.
The rule from Part 1, "Don't leave employees with write permissions on external-facing tasks for long periods," exists for these kinds of employees.
Summary: Preventing AI Accidents Requires Restricting Permissions More Than Placing Stoppers
Finally, I'll restate the most important point of this article.
Even if you place a stopper, accidents happen if they aren't called. It is more reliable to ensure irreversible operations are structurally unreachable.
The Stop Officer is a read-only employee that grants no permissions. To prevent accidents even if forgotten, restrict the permissions of employees who can write.
Open your AI employee files and check if the `tools` line is present.
Employees omitting the tools line inherit all tools available to subagents.
Restricting tools via the tools line significantly reduces anxiety while leaving long tasks to AI employees.
This AI Company Series Dissects All 46 Employees One by One with Full Prompts
This article covered only 1 of the 46.
Future articles will deep-dive into one employee per article.
This series reveals everything: the contents of 46 AI employees, department structures, permission assignments, and design fixes.
I will document fixed designs with the same density as successful ones.
I will deliver the contents of the AI employees sequentially. If you want to continue reading, please follow @Sokichi_Hoshino.
Thank you for reading to the end.
【📣Announcement📣】
Opening a Community Channel to Master AI and X Completely.
The channel delivers the latest and valuable info on AI and X without holding back.
🎁Free Benefits for Channel Members🎁
① 200 Selected Prompts
② 20 Gems
③ 7 Claude Skills Gifts 🎁
🌈Content Shared in the Channel🌈
① How to Achieve 1 Million Yen Sales on First Note Post
② SNS Marketing Methods
③ List Marketing Methods
④ Digital Data Marketing Methods
⑤ Fastest Way to Grow X
And more, sharing insights from my experience as an active AI×SNS marketer with background in digital/big data marketing.
Beginners and lurkers welcome ✨ Please feel free to peek ✨
↓Join Here.
https://line.me/ti/g2/LmLu1N1cE6UBkoURbaYf_bV8l66cCyotSJU2og
【📣Announcement 2📣】
Launched AI Advisory Service for Executives/Business Owners.
【Service Contents】
・SNS Automation Support (X, Threads, Instagram, TikTok, YouTube)
・AI Employee Construction Support
・AI Tool/App Creation
Customized to maximize revenue based on needs.
