More than a person's job description, and with nothing left implied. An AI agent's role description should state its purpose, a named owner, each capability with its depth, the sources it may rely on, the systems it may reach, its limits, when it must hand over and to whom, what it must never do, and the record each action leaves.
Why can't you reuse a job description written for people?
Because job descriptions rely on judgement and context the agent does not have. "Handles customer complaints and uses discretion to resolve issues" works for a person who has absorbed years of unwritten norms. An agent will read "uses discretion" as permission.
Human job descriptions also leave out what everybody knows: that you do not refund your own account, that you ask a manager before waiving a large fee, that a solicitor's letter goes to legal. For an agent, anything left out is either forbidden by default, if your controls are good, or allowed by accident, if they are not.
What fields should it contain?
| Field | What to write | Example |
|---|---|---|
| Purpose | One sentence on the job | Triage incoming complaints and draft acknowledgements |
| Owner | A named person accountable for the agent | Head of customer relations |
| Capabilities | Each action, as a verb and object | Read complaint; classify; draft acknowledgement; route to team |
| Depth each capability needs | 1 to 5 for each | Classify: 3. Draft acknowledgement: 2 |
| Sources | Each document or system it may ground on | Complaints policy v4; customer record; product terms |
| Systems and access | What its own identity may reach | Complaints queue (read/write); CRM (read) |
| In-scope cases | Which customers, products, channels | Retail customers; email and web form |
| Limits | Amounts, volumes, time windows | No compensation offers at any amount |
| Hand-over rules | Triggers and the named queue for each | Mentions of a regulator or legal action: senior handler |
| Never list | Actions refused whatever the case | Never send a final response |
| Evidence | What each action must leave | Classification, sources used, verdict, time |
| Certification | Status, date and review date | Certified at depth 3; review in 90 days |
| Version | Version number and change history | v1.3, change log reference |
The capability list and depth column are the core. Everything else qualifies them. A role description without the depth each capability needs cannot be enforced, because nothing says how far the agent may go with each action. The idea is unpacked in role scope: what it means for AI agents.
How is this different from an access role?
In role-based access control, a role grants access to systems and data. That is one row of the table above. An agent's role description also says what the agent may do with that access, how far, under what limits, and when it must stop and hand over.
The two should agree. If the access role grants write access the capability list does not need, the access is too wide. If the capability list includes an action the access role cannot support, the description is wrong.
What does a filled-in example look like?
Take a water company's complaints team. Its triage agent's description says the agent reads each incoming complaint, classifies it by type and severity at depth 3, drafts an acknowledgement at depth 2 for a handler to send, and routes the case to the right team at depth 3. Its sources are the complaints policy, the customer's account record and the published service standards. It may not offer compensation at any amount.
Hand-over rules are specific: any mention of a regulator, an ombudsman or legal action goes to a senior handler; any sign of vulnerability goes to the priority services team; anything the agent cannot classify goes to the team lead. Its never list says it must never close a complaint or send a final response. Each classification is filed with the sources used. The owner is the head of customer relations, with a review date set.
That description is short enough to read in two minutes and precise enough to test.
What controls follow from a good role description?
- Enforcement at the moment of action. Each capability and limit is checked when the agent acts, not only written down.
- Access matched to capabilities, reviewed when either changes.
- Testing against the description. Certification tests the agent on every capability in it, plus the hand-over and never rules.
- Change control. A new capability, source or limit is a new version, approved and recorded. Our guide on setting an AI agent's role scope covers the change route.
- Monitoring for drift beyond the role; see how to stop an AI agent going beyond its role.
The role description is where agent governance starts: every bound checked later traces back to a line in it.
Questions people ask
Who should write the role description?
The process owner, who knows the work, with risk reviewing the limits and never list and security reviewing access.
How long should it be?
One or two pages. If it needs more, the agent probably has more than one job and should be split.
Is there a standard format?
There is no single required format. Our agent role charter gives a layout you can adapt.