Why the format helps
Writing a job description forces decisions that a technical spec lets you defer: what this role decides alone, what it escalates, what good looks like, and who it reports to. Those are exactly the ambiguities that surface later as incidents.
Scope: one job, stated narrowly
“Handles customer questions” is not a scope. “Answers billing questions for existing customers on email, during and outside business hours, excluding refunds and cancellations” is. The exclusions are the useful half, and they map directly to the jobs worth giving it first.
Authority: what it may decide alone
State the decisions it can make without a human, the ones it must route, and the threshold between them. Escalation should key off the stakes of the request rather than the system’s confidence, for the same reason confidence scores make an unreliable trigger.
The most useful section of the job description is the list of things this role must never do.
Success criteria you can actually check
Define what a good month looks like in numbers you already collect: resolution confirmed downstream, human minutes returned, quality against your existing standard. Vague goals here produce the vanity metrics that make an AI employee look better than it is.
Reporting line
Name the person who reviews its work and owns its knowledge. A role with no manager is the org-design failure that leaves an AI employee unowned and slowly degrading.
Then use it as the spec
The document becomes the source for the system prompt, the escalation rules, and the evaluation set. When behaviour is disputed later, you argue against the job description rather than against each other’s recollection — which is the whole point of writing it down.