The supervised role brief
Write the job
before you delegate.
Use this guide to define what an agent may read, prepare and propose, and which decisions your team keeps. Begin with one task the process owner can inspect.
A useful agent brief defines the task, knowledge, authority, reviewer, exception route and evidence of what happened. If one is unclear, resolve it before widening the role.
1. Describe one observable result.
Choose a task with a clear start and finish. “Prepare an internal brief from one kind of enquiry” is a more useful first boundary than “run customer service”. Describe the result a reviewer should be able to inspect.
2. Name the approved knowledge.
List which documents, records or service details the role can use. Name the source owner and how changes are reviewed. Do not assume that an answer is approved because it sounds plausible.
3. Separate permissions.
Write down the difference between reading, preparing, recommending and committing a change. The person checking a draft should understand exactly what will happen after approval.
A possible assisted role
- Read an agreed source set
- Organise relevant details
- Prepare a labelled draft
- Flag gaps and uncertainty
The accountable person
- Approve a customer promise
- Resolve conflicting facts
- Authorise the agreed action
- Decide whether to expand or stop
4. Define the exception route.
Include missing inputs, inconsistent sources, unusual requests and an unavailable connected tool. Name the person who receives the issue and the state in which unfinished work waits. Explain how it resumes after review.
5. Test the limits.
Use fictional or redacted examples while information access is being assessed. Include a routine case, a case with a missing detail, a conflicting source and a request outside the role. Check whether it asks for help at the right point.
| Job | What output can the owner inspect? |
|---|---|
| Knowledge | Which sources are current and approved? |
| Authority | Which actions are allowed, and which require approval? |
| Reviewer | Who can judge the work and overturn it? |
| Exception | Where does uncertain work wait and who owns it? |
| Record | What evidence shows the proposed and approved actions? |
6. Keep an inspectable record.
The team should be able to distinguish a proposed action, a reviewed result and a completed change. Keep enough context to understand what information was used and what the reviewer approved, with appropriate access and retention boundaries.
7. Hand over the operating role.
Document how the owner finds unfinished work, pauses the process and checks changes to knowledge or connected tools. Review the role when its information, authority or purpose changes. A successful pilot does not automatically justify broader access.
A useful role starts with the work
Bring one job.
Name its owner.
Talk through a bounded first pilot with Flowtivity.