How to define AI agent roles and responsibilities in a team

Four named roles cover almost every agent a team runs. The owner answers for the agent's results and bounds. Reviewers check its held work. Approvers release actions above a set depth. The builder designs, trains and certifies it. Write each role against a person's name, give each a distinct decision, and define the handovers in writing.

What are the roles, and who owns the arrangement?

The process owner owns the business process the agent works inside, such as supplier payments or complaint handling. They decide what good looks like and set the team's limits. The agent owner answers for one agent: its brief, its sources, its depth and its certificate. In a small team one person can hold both, but write them as two lines so the split is visible when the team grows.

Reviewers work the review queue. They read what the agent drafted or held, correct it, and send it or pass it up. Approvers release held actions the agent cannot take alone, typically anything that moves money or is hard to undo. The builder designs the agent, writes its brief, connects its sources and runs certification. The second line, compliance or risk, sits outside the team and checks that the arrangement works.

Our guide to AI agent skills by role sets out what each of these people needs to know. This playbook is about writing the roles down and making them stick.

What are the steps to define the roles?

1. Process owner: lists what the agent does. Every capability, one line each: reads the ledger, drafts the dunning letter, sends routine reminders, releases a payment.
2. Builder: marks the depth each capability needs. Depth 1 reads, 2 drafts for a person to send, 3 executes routine work within bounds, 4 moves money or takes hard-to-undo actions. The agent acts only at the depth its certificate supports; the role sets a ceiling, evidence sets the depth, and the lower wins.
3. Process owner: assigns a reviewer role to every depth 2 capability and an approver role to every action that can be held at depth 3 or 4. Name the role and the people who hold it today.
4. Agent owner: writes the handovers. For each capability: who receives the agent's output, who picks up a refusal, and who is told when the agent's certificate lapses and it drops to depth 1.
5. Second line: checks separation. The person who builds an agent should not approve its depth 4 actions, and the person who approves a payment should not also set the limit it was checked against.
6. Agent owner: publishes the role sheet and files it with the agent's record, so anyone can see who held which role on any date.

Which handovers matter most?

Five handovers cause most of the trouble. Agent to reviewer: the draft must arrive with its sources and the bound that held it, so the reviewer is not starting from scratch. Reviewer to approver: when a reviewer passes something up, they add a reason, not just a forward. Refusal to owner: a refused action means the request was outside the agent's bounds, and someone still has to answer the person who asked. Reviewer to builder: corrections that recur become changes to the brief or the sources, not habits in the reviewer's head. Owner to successor: when the agent owner moves on, the agent needs a named new owner before the last day.

Write each handover as a sentence with a sender, a receiver and a deadline. "The reviewer passes any refund above the team limit to the duty approver within one working hour, with a one-line reason" is a handover. "Escalate where appropriate" is not.

Which controls hold the roles in place, and what evidence do they leave?

Named people, not job titles. Every role on the sheet has names and a deputy. Evidence: the role sheet, versioned and filed with the agent record.

Approval rights tied to competence. A business can make the right to approve depend on a current certificate for that depth. When the certificate lapses, the right lapses with it. Evidence: the approver list checked against certificate expiry dates.

Separation of duties. Builder, approver and limit-setter are different people for depth 4 actions. Evidence: the verdict record shows who approved each held action, which can be compared with who built the agent.

Every verdict filed. Allowed, held, refused and withheld decisions all go to the append-only record with the name of whoever acted. Evidence: the record itself.

If your organisation is working toward an AI management system standard, the role sheet maps onto ISO/IEC 42001 roles and responsibilities for AI agents.

What should you measure?

• Held actions with no named approver available, by hour of the day. This shows gaps in cover.
• Time from hold to decision for each approver role.
• Refusals with no follow-up, where nobody picked up the request the agent could not serve.
• Roles held by someone whose certificate has lapsed. The target is none.
• Corrections that recur after being reported to the agent owner, a sign the handover to the builder is broken.

A competency matrix for the operations team turns these numbers into a view of who can cover which role next month.

Where does it usually go wrong?

One person holds every role. The most senior person builds, owns and approves. It feels efficient until they are on leave and the queue stops, or until an auditor asks who checked their work.

Reviewer and approver are blurred. Reviewers correct drafts; approvers accept the consequences of an action. If reviewers can approve depth 4 work because the button is there, the role sheet is decoration.

Roles are defined for launch day, not for the rhythm. The sheet covers the first week but not weekends, month end, or what happens when the agent drops to depth 1.

Hiring ignores the new roles. Teams recruit for the old job and hope people adapt. The playbook on hiring for AI operations roles covers what to test before you offer.

Where the Academy fits

Pryme Intelligence Academy follows the same roles. Foundations suits owners, executives and anyone who needs the decision chain explained. The Operator track is for reviewers, team leads and operations managers and ends in Certified Pryme Operator. The Builder track is for whoever designs and certifies agents, and the Architect track is for people leading regulated, multi-agent deployments.