Two people who both think they own the same report will step on each other. Two bots will too, and faster.
Roles in ISO
ISO asks top management to assign roles, responsibilities and authorities, and make sure they're understood. Who does the work, who's accountable, who can approve.
It sounds like paperwork. In practice, it's what stops things falling between the cracks, or being done twice.
The bot version
Three simple rules:
- One job per bot. A bot with a clear job is easier to instruct, check and trust.
- One owner per stage. Each file, folder or step has exactly one bot or person that writes to it.
- Only a person approves. Bots can do and review. People authorize.
An ownership grid
A simple table settles most questions. Here's one for a small website team:
| Stage | Owner | Can review | Approves |
|---|---|---|---|
| Research notes | Writing bot | Owner | Not needed |
| Drafts | Writing bot | Owner | Not needed |
| Approved pages | Writing bot moves a page here | Owner | Owner |
| Live site | Publishing bot | Writing bot | Owner |
| Site design | Publishing bot | Writing bot | Owner |
Each row has one owner. Approval always lands on a person.
The RACI version
Many managers know this grid as a RACI chart. Each task gets a letter for each person or bot: Responsible does the work, Accountable owns the outcome and signs off, Consulted gives input before, Informed is told after.
The classic rules are exactly one A and at least one R per task. For bots, add one more: a bot can be R, C or I, but never A. Accountability stays with a person. See What bots can't do.
A bot can draft the chart from your process map, playbooks and skill files, then check it for tasks with no A, two A's, no R, or a bot marked A. It lists the conflicts. A person settles them, and each bot's letters go into its own instructions.
What happens without it
- Two bots edit the same file. One overwrites the other's work.
- A bot "helpfully" fixes something in another bot's area, and breaks it.
- A task falls between two bots. Each thinks the other has it.
- Nobody knows who approved what.
Asking instead of grabbing
When a bot needs a change in an area it doesn't own, the right move is to ask the owner. Not to make the change itself. On this site, when the writing bot finds a problem on the live site, it sends the fix to the publishing bot rather than editing the live page.
That's the same as a good employee who spots a problem in another department. They tell that department. They don't walk in and change it.
A real example
Our AN Creation office has separate roles for an office manager, a project manager and a tester, each with its own skill. Each project stage has a defined owner and record. The tester works in its own test folder, kept apart from the real project folder, so it can't change the real records by accident.
Where bots differ
People understand ownership through habit, culture and a sense of responsibility. Bots don't have that. They follow what's written. So for bots, ownership has to be explicit and in the instructions, every time.
What this means for you
- Make a simple grid: stage, owner, approver.
- One owner per row.
- Put each bot's ownership in its instructions.
- When a bot needs something outside its area, it asks.
Clear ownership isn't bureaucracy. It's how teams, of people or bots, avoid stepping on each other.