Machine-readable should not mean machine-governed.

01The bot with a login

The bot can see everything. What is it for?

Someone connected an assistant to the workspace. It can read every channel, draft in every doc and post in any thread. Sometimes it’s useful. Nobody can say which work it owns, who checks it, or what it’s allowed to decide.

Broad access with no job fails in two directions at once. The agent does too little that anyone relies on, and it can do too much that nobody approved. When it gets something wrong, there is no role to correct and no record to read.

A written role changes that. The agent fills a named role on a team, works from the team’s rights and inside its boundary, and its work leaves a trail people can check. People decide what it may do, and people can revoke it.

02The distinction

Access is what an agent can touch. A role is what it’s for.

The same agent can be harmless or dangerous depending on how it’s placed. Give it a role, a supervisor and limits, and it becomes a colleague you can reason about. Work can be readable by machines and still be governed by people.

03Three principles

Give agents jobs, limits and a supervisor.

1. 1

   Name the role before you pick the agent.

   Write the role as you would for a person: purpose, responsibilities, rights. Then decide what fills it: a person, an agent, or both. “Renewals drafting” is a role. “The AI” is not. A third-party agent and one you build yourself fill roles the same way.

2. 2

   Bound it by rights, not by hope.

   An agent should act only inside the decision rights its role holds, and read only the sources the team chose. When an action falls outside those rights, it should take the question to a person instead of acting. “Fully autonomous” is not a useful setting; a clear boundary is.

3. 3

   Keep a receipt for everything.

   Every action should leave a record: what the agent did, what it read, who approved it and when. When people correct the role, the agent reads the new version on its next run. If it stops earning its place, revoke it.

04In Particulars

Agents as named, bounded role-fillers.

In Particulars an agent appears where its role does: on the charter, in the role card and on the team’s network, with its own seeded mark. It reads its operating charter through its own token: the team’s purpose, rights, teammates and guidelines. Change the charter and the agent reads the new version next time. Revoke it and the token stops working on the next request.

Illustrative team. The charter is the agent’s instruction; revoking it stops the next read.

05What becomes possible

Put more intelligence to work without losing the plot.

With agents in roles, you can add capacity where the work is clear and keep people where judgment matters. You can see which roles are co-filled, which agent fills each one, and when each last read its charter. And when one stops earning its place, revoking it is one step.

• Give each agent a role, a supervisor and a boundary.
• See which roles each agent fills, and when it last read its charter.
• Revoke an agent in one step: its token stops working.

“Fully autonomous is not a useful setting. A clear role is.”

The Particulars thesis