Machine-readable should not mean machine-governed.
A charter is one team’s editable account of its purpose, work, measures, authority, roles, and guidelines. Particulars gives an agent that current context, bounded to the team and role it serves.
The agent arrives knowing what the team is for, what job it holds, which rules apply, and who remains accountable. You gain useful help without handing software an invented mandate.
An AI that helps with everything is not a role. It is an unbounded wish.
You have probably run this experiment already. Give an AI access to Slack, the docs, and the ticket system. Tell it to be helpful, accurate, safe, and aligned with company values. Then ask people to discover what it can do.
The demo can look clever while the daily work stays vague. Who is the agent helping? Which recurring job belongs to it? Who checks the output? Where does a recommendation end and a decision begin? People answer those questions privately, and every person develops a different idea of when to trust the software.
Give the agent a role inside a team first. Write down the contribution, the local rules, the decisions it can support, and the person who stays accountable. Now the software has a place to stand and your team has a way to govern the work.
Give software a real job inside an accountable team.
There is a useful middle ground. Treat the agent as software that holds a real job: it sits on a team, its job has a written description, and a specific person stays accountable for what it does. This avoids pretending the agent is a person and avoids hiding recurring work behind the word “tool.”
Role
The job: a named contribution inside a team, written clearly enough for people to understand and review.
Agent
The software filling all or part of that role, with its identity and current scope shown on the charter.
Access
Software may be able to send a message or change a customer file before anyone has authorized that action. Access is a technical fact. Authority is an organizational decision.
Accountability
A named person or role designs the delegation, reviews the work, and changes or ends the arrangement when needed.
Give the agent enough context to help and clear limits to follow.
Start with the team and the job
A new colleague needs to know what the team is for, what job they hold, which work belongs to them, which rules matter, and who needs their output. An agent needs those answers too. A giant prompt quickly drifts away from the organization as people edit copies in different places.
Particulars gathers the current charter for one team and one role. When someone changes the purpose, authority, role, or guideline, the context changes at the source. Access stays read-only, limited to that team, and easy to revoke.
Each piece keeps its meaning. The purpose explains why the team exists. A decision right names authority. A guideline gives a local rule. The roster names the people and software involved. A person reviewing the agent can trace every part back to the same charter.
Keep access and authority separate
A tool connection tells you what software can technically do. A decision right tells you what the team has authorized the role to do. Keep those answers separate. A broad credential may be able to send a message, but the role may only prepare a draft for a person to review.
Today Particulars does one job for agents: it hands them current, bounded context about the team they serve — purpose, rules, people, and limits. Action-taking, approvals, and action logs come later. The charter can already say where the agent’s job ends, and the product stays honest about which limits it enforces today.
Start by asking whether the agent has enough current context to prepare useful work. Expand its capabilities only after the contribution, review point, and authority are clear.
Name the person who stays accountable
A person may hold the relationships, judgment, and final authority while an agent provides speed, memory, monitoring, or synthesis. “AI-assisted” leaves that split fuzzy. Write down who does what inside the role.
The split matters when sources disagree, confidence is low, or the next action is hard to reverse. The agent may stop and ask a named role for help. The charter gives everyone that route before the unusual case arrives.
The accountable person reviews whether the arrangement still helps, narrows access when the job changes, and owns the correction when the software creates an unexpected consequence. Their name represents continuing work, not a decorative approval at the bottom of a card.
A software contributor inside a bounded role
Create the agent from the team it will join. The role names its contribution. The charter supplies the purpose, measures, authority, roster, and guidelines in one bounded package.
The agent appears on the charter as software filling a role. Remove it and its access ends. People can see the placement, the scope, and the accountable relationship in the same place they read the rest of the team.
Know what every agent is doing, where it works, and who is responsible.
Once agents fill explicit roles, you can ask useful questions about the work. Does this agent still help the team? Does its context match the current charter? Who reviews the output? Did a temporary experiment quietly become permanent?
Useful delegation starts with a job the team understands and can govern. Technical controls, evaluation, isolation, and audit still matter. The charter adds the organizational context that tells those controls what the work is for and where the boundary belongs.
- Make the software’s team, role, and current scope inspectable.
- Revoke access when the role, agent, or organizational need ends.
- Give human and software contributors one shared account of the work while keeping their responsibilities distinct.
“The companies that gain real leverage from agents will give them better places to stand, clearer jobs to do, and visible people who remain accountable.”
— The Particulars thesis