What is a role specification for an AI worker?

A role specification is the written, signed description of one AI worker's job. It says what the worker does step by step, which systems it works in, who it reports to, which actions wait for a person's approval, what counts as a finished piece of work and the KPIs it will be measured on. It is agreed before anything is built, and it covers one job. Think of it as a job description that also says how the job will be judged.

Why does a role specification matter to an owner?

Somebody buys a tool, tries it on whatever is to hand, and three months later cannot say whether it helped. A role specification settles what the job is before anything is built.

It makes the worker's job something you can read and disagree with while changing it is still cheap. It is the standard a probation period is judged against, because the KPIs the worker must hit by day 90 are the ones written in it, and nowhere else. And it draws the line between what the worker does and what stays with your people, in writing, before the first email goes out.

What does a role specification contain?

• The job. One or two sentences an outsider would understand. "Enters orders that arrive by email into the order system and tells the customer what is out of stock."

• Where it works. The systems and mailboxes it reads from and writes to, and the route into each one that its maker allows on your licence.

• Who it reports to. A named person or job title, and exactly what is sent to them: the exceptions, the disputes, anything outside the rules.

• The steps, and what waits for a person. For each step, what the worker does on its own and what it prepares for someone to approve. Decisions a regulator would care about always have a named person against them.

• The KPIs and the volumes. A small number of measures in your own terms, with the amount of work a month that both sides expect, so that the KPIs are set for the job as it really is.

• What counts as a task. The jobs the worker carries through and the result each one ends in, defined for this role so that the work can be measured and reviewed. Our explainer on what counts as a task covers how that is done.

The role pages on this site show the shape. Order processing and renewals and expiry tracking each set out a job, its steps, what waits for a person and what it is measured on. Those are the specifications we start from. Yours is agreed with you before anything is built.

How is a role specification written?

It starts with you describing the job to us: what triggers the work, who does it today, in which systems, how often, and what goes wrong. From that comes a draft. Then come the rules, where the job really is, which say what wording may be used with a customer, how many reminders go and how far apart, what makes a case an exception, and who is told, and when.

You read the draft, correct it and sign it. Only then is the worker built.

How is it used once the worker is running?

Once the worker is running, the specification is the reference for everyone. The worker stays inside it and turns down a request outside the role instead of attempting it. The named person receives the things the specification says they receive and nothing else, so they are not copied in on everything. The monthly review looks at the KPIs it lists.

When the job changes, the specification changes with it. A new rule or a changed step inside the role is an amendment to the same document, and it is still the same worker. A different job gets its own role specification, which keeps the question of whether a request is in scope short.

How is it different from a job description, a prompt or an SLA?

• A job description. Close, but a job description rarely says what happens at each step, what must be approved, or how success is counted. A role specification says all three.

• A prompt. A prompt is an instruction typed to an AI model. A role specification is an agreement between two businesses about a job. The instructions the worker runs on are written from it, and they are our responsibility to get right.

• A software requirements document. That is finished with on the day the software is delivered. A role specification stays in force for as long as the worker runs, and the worker is reviewed against it every month.

• A service level agreement. An SLA sets how a supplier responds. A role specification sets what the worker itself does and achieves.

How do I define the job before buying AI?

You can do most of the thinking before you speak to anyone. Write down the job as you would explain it to a temp on their first morning. Collect five real examples, including one that went wrong. Count how many arrive in a normal month and a busy one. Decide who would check the work. An owner who has those four things has most of a role specification already, and a clearer view of the job whether or not an AI worker ever does it.

For an AI worker, the role specification is the document that makes that comparison real. For the wider model, see what AI staff are.

In your business the job would be written down and signed before anything is built, then measured against it, with a named person of yours against every decision a regulator would care about. If the job is clear in your head and written down nowhere, talk to our agent and start putting it on paper.