Agents need job descriptions

’Agent’ has become the word for any AI system that takes actions and does not only produce text: reading an inbox, updating a record, sending a draft for approval. The technology has improved quickly. The failures we see are mostly failures of management.

The most useful habit we have found is to write a job description for the agent before building it, exactly as you would for a new hire.

What goes in it

• Purpose. One sentence. ’Files incoming transport documents against the right shipment.’
• Inputs. What it is allowed to read, and from where.
• Actions. What it may do on its own, what it may only propose, and what it must never do.
• Escalation. When it hands over to a person, and to whom.
• Measures. How you will know it is doing the job: accuracy, volume, time, override rate.
• Manager. The named person who reviews its work and is accountable for it.

Why this works

It forces the conversations that otherwise happen after go-live. Can it send an email to a customer without review? Can it change a price? What happens at three in the morning when the ERP is down? Operations managers are good at these questions. They only need to be asked in language they recognise.

It also makes scope creep visible. An agent that ’handles customer emails’ will disappoint. An agent that ’drafts replies to delivery-date questions using the order system, for approval by the service desk’ can be built, tested and trusted, and then given a second duty when it has earned it.

Start narrow and promote on evidence

We usually launch agents in propose-only mode, where every action is approved by a person. After a few weeks the data shows which actions are approved without changes ninety-nine times in a hundred. Those can be delegated. The rest stay with people. It is the way you would treat a capable trainee, and it is the fastest route we know to an agent that people rely on.