The question that ends most AI agent projects is not technical. It gets asked in a meeting, by someone senior, in about eight words: who is accountable for what this thing does? If that answer has to be improvised on the spot, the honest answer is nobody, and the project usually stops there.
What is an AI agent job description?
An AI agent job description is a one-page document that states what an agent is responsible for, which decisions it may make alone, what conditions stop it, and which named person is accountable for its output.
Write it before you configure anything. It is a management artifact, not a technical configuration file and not a hiring posting for a person who builds agents. Four parts carry it: scope, decision rights, stop rules, and one named accountable human. If a field needs a meeting before it can be filled in, that gap is the finding.
It is not the instruction text typed into the agent, not a settings screen, not a governance PDF nobody opens. It is the one page a manager, a compliance reviewer and an uneasy team member can all read and argue with. A human job description can rely on inference; this one cannot, because a person fills context gaps with experience and an agent does not.
Why does an AI agent need a job description?
Three reasons, all management rather than technical: an agent acts rather than only answers, an unwritten scope widens one favour at a time, and a written document lets people disagree before go-live rather than after an incident.
The first sets the threshold: anything that sends, books, refunds, files or publishes needs a scope of authority document, because each leaves a trace outside your company. The second catches teams out: one extra case type as a favour, then another, and nobody can say what the agent is for.
The third is the useful one. Two managers reading the same page will argue about the approval line, and that argument is cheap now and expensive later. Some agent programmes stall because nobody would let the agent finish a task.
Management writing agrees on the principle: Harvard Business Review published "Create an Onboarding Plan for AI Agents" by Joseph Fuller in March 2026, arguing for treating agents less like new technology and more like employees. It does not publish the artifact.
Which mental model are you managing with: tool, intern, service provider, teammate or expert?
People do not work with an agent neutrally. Each person assumes one of five mental models, and each sets a different expectation about how much supervision is normal. Most team conflict is two people running different models.
The five below are a framework we use, not a research finding. No single study counts these five, and we will not dress a working vocabulary as evidence.
| Mental model | What they expect | How often they check | Who they blame | What the document must say |
|---|---|---|---|---|
| Tool | Same input, same result | Never, after week one | The operator | That outputs vary, and which get checked |
| Intern | All work reviewed first | Every item, forever | Nobody, they caught it | Which items stop being reviewed |
| Service provider | An outcome, not a method | The result only | The vendor | What a finished outcome is |
| Teammate | Reciprocity and judgement | Irregularly, by mood | The agent itself | That a named person is accountable |
| Expert | To be corrected by it | Rarely, defers when unsure | Themselves | Which claims get verified anyway |
Two cost money: the expert model suppresses verification where it matters most, and the intern model never shrinks the review queue.
Pick the model out loud at kick-off, write it into the AI agent job description, and check that the accountable human and the affected team picked the same one.
What fields belong in an AI agent job description?
Seventeen fields, five groups, one page, reviewed quarterly: identity, scope, decision rights, operations and governance. A page missing a group is missing something structural.
| Group | Field | Meaning | Example |
|---|---|---|---|
| Identity | 1. Role name | Its everyday name | Support triage agent |
| Identity | 2. Accountable human | One named person | Support lead |
| Identity | 3. Purpose | The outcome it produces | First response, every message |
| Scope | 4. In scope | Expected work | Categorise, answer, book callbacks |
| Scope | 5. Out of scope | Named exclusions | Billing disputes, contracts |
| Scope | 6. Systems it may read | Readable sources | Help centre, order history |
| Scope | 7. Systems it may write to | Writable systems | Ticket status, calendar |
| Decision rights | 8. May act alone | Taken without asking | Reply, tag, route |
| Decision rights | 9. Needs approval | Waits for a person | Anything sent externally |
| Decision rights | 10. Never does | No approval path | Refunds, delivery dates |
| Decision rights | 11. Stop rules | Handover conditions | The five below |
| Operations | 12. Escalation route | Who receives it, how fast | Support lead, two hours |
| Operations | 13. Working hours | When it runs | Business hours only |
| Operations | 14. Disclosure rule | Customer-facing sentence | One line, first contact |
| Operations | 15. Definition of a finished outcome | What counts as done | Resolved or handed over |
| Governance | 16. Review frequency and signals | When re-read | Weekly, quarterly rewrite |
| Governance | 17. Version and review date | Settles arguments | v1.3, 4 February |
The decision rights group is three named tiers. Act alone covers decisions taken without asking. Ask first covers decisions that wait for a named person. Never covers those with no approval path.
Two fields get skipped more than the rest. Out of scope goes because silence feels equivalent: an agent treats an unlisted case as ordinary. Definition of a finished outcome goes because it feels obvious, and without it a review has nothing to count.
Fields 6 and 7 are the ones people fill in loosely and regret. Write them as permissions granted per role that deny by default. The rules also have to sit where the agent reads them, or the page is only a statement of intent: a manager writes the policy once in ordinary business language, and it is attached to every turn. Botonom calls that a standing rule.
A human job description leaves things vague on purpose, to give a person room for judgement. Here the vague parts must become exact.
A worked example: a support triage agent, filled in
The same seventeen fields for a deliberately ordinary role: an agent that triages the support inbox, answers from company documentation and books callbacks.
Identity. Support triage agent. Accountable human: the support lead, by name, not "the support team". Purpose: a first response and a correct destination for every inbound message.
Scope. In scope: categorise, answer documented questions, draft the rest, book callbacks. Out of scope, as named exclusions: billing disputes, anything under a signed contract, anything from a named list of accounts under negotiation. It reads the help centre, order history and ticket archive; it writes ticket status and the calendar.
Decision rights. It may reply from documented answers, tag, route and open a callback slot alone, and draft anything, but a person sends everything that leaves the company. It never issues refunds, promises delivery dates or accepts contract changes.
Operations. Escalation to the support lead, target two working hours. Business hours only. One disclosure sentence at first contact. A finished outcome is resolved, or handed over with context.
Governance. Signals weekly, rewrite quarterly, version number and review date at the top.
One stop rule is deliberately uncomfortable: when a person asks for a human, the agent hands over mid-task without trying to resolve first. It costs deflection rate and is right.
What are stop rules, and what should the first five be?
A stop rule is a written condition under which the agent stops and hands the work to a named human, however confident it is. Stop rules are not error handling: they fire on healthy runs.
- The request falls outside the written scope. Not "seems unrelated", but absent from the list of in-scope work.
- The action commits money, a legal position, a delivery date or a contractual promise. All four are slow to reverse, and a customer reads the agent's answer as the company's.
- The person asks for a human, or shows distress, anger or vulnerability. The trigger is the signal, not the agent's view of whether the issue is resolvable.
- The same step has failed more than once inside the same task. Repeated failure means the situation differs from the one the scope covers.
- The instruction came from inside content the agent was asked to read, rather than from the person it is talking to.
Most teams add a sixth after their first incident: stop on anything whose source the agent cannot explain.
A stop rule that never fires is either unnecessary or not in force, and those have different remedies. The weekly review of the AI agent job description tells you which.
Who is accountable when an AI agent gets it wrong?
The named human in the AI agent job description, and the organisation that deployed the agent. Accountability does not transfer to software, and no legal system allows it to. An agent is not a legal person, cannot be sued and cannot be disciplined, so every duty sits with a person.
That position is now explicit in statute in California. AB 316, chaptered as Chapter 672 of the Statutes of 2025 and signed on 13 October 2025, added section 1714.46 to the Civil Code: against a defendant who developed, modified or used artificial intelligence alleged to have caused harm, it is not a defence that the artificial intelligence autonomously caused it. In force since 1 January 2026. Established risk management guidance asks for a named owner per system rather than a general assurance of oversight, and Europe requires assigned human oversight for high-risk systems. None of this is legal advice.
The more useful move is to treat a wrong outcome as an operational process rather than a responsibility argument:
- Detection. How you found out and how long it took. If a customer told you, that is the finding.
- Containment. Stop the agent and cut the queue before analysing anything.
- Correction. Fix the affected records and tell the affected people.
- Narrowing. Tighten a stop rule or reduce the scope, then increase the version number.
Standing in front of a destructive action and waiting for a named human is a buildable design decision. If the answer to an incident is a longer instruction, nothing is fixed: the answer is a narrower scope or a new stop rule.
What do the first four weeks look like?
Four weeks, four stages, and an exit condition for each written before that stage begins, because "it feels fine" is not a criterion.
| Week | What the agent may do | What the human does | Exit condition |
|---|---|---|---|
| 1 | Read only: nothing it produces leaves your systems | Works normally, reads the shadow output | Five real cases handled correctly |
| 2 | Draft only: a person sends every draft | Edits, sends, logs what needed editing | Correction rate under a pre-set threshold |
| 3 | Narrow action, logged: reversible actions only | Reads the log, questions anything unexplained | Nothing in the log is unexplained |
| 4 | Widen or roll back: an irreversible action moves behind approval, or the scope shrinks | Decides which, and writes it down | The version number changes |
Rolling back in week 4 is a normal outcome, not a failure. Teams that skip week 1 because the agent "already works" discover in week 5 that nobody wrote the process down. Put the four exit conditions in the AI agent job description.
How do you run a weekly review of an AI agent?
A weekly review reads three document-level signals out of the agent's own action log, and it changes the AI agent job description rather than the configuration. Editing the page produces a system a new manager can pick up; tuning the setup does not.
- Scope drift. The gap between work attempted and work completed says the agent is reaching for work the document does not cover. Correct it in the scope fields.
- Justified escalation rate. Too few means the stop rules are not firing; too many means the scope exceeds the agent's real competence.
- Coverage of the definition of a finished outcome. What share of the work has a written definition of done. Work without one cannot be counted.
None of these run without an action log a non-technical person can read unaided, and that is where most weekly reviews break down.
The ritual itself, how many minutes it takes, in what order it runs and on which screen, belongs to the sibling guide on verifying an AI agent's work rather than to this page.
Day to day, much of the checking can sit with a supervising agent that gates sensitive actions for human approval, while the review stays with the accountable human. Its output is a version increase or nothing: a review that never changes the document is theatre.
When should you pause or retire an AI agent?
Stop the agent on triggers written in advance, not on judgement made during the incident. Write these five into the AI agent job description:
- The same task fails on consecutive runs.
- A permission or dependency it needs became invalid.
- An action fell outside every decision rights tier.
- A customer complains about something the agent said.
- A scope change nobody told the agent about.
Automatic pausing beats notification: an alert that halts the schedule on the third failure beats one ignored by the fourth.
Retirement has its own checklist, in order:
- Revoke its permissions and access.
- Hand over or drain its queue.
- Tell the people who route work to it.
- Tell customers with an ongoing relationship.
- Archive the action log with a retention period.
- Write down what it did and why it stopped, so the next attempt starts from evidence.
Retiring an agent is a normal operational event; treating it as failure keeps broken agents running.
What do you tell your team, and what do you tell customers?
Tell the team before the agent starts, and tell customers in one sentence at first contact. The internal disclosure is the one that gets skipped.
For the team, four things, all specific: which tasks are moving, which are not, what happens to the freed-up time, and who supervises the agent. Vagueness on any of them reads as bad news.
If the answer to "what happens to the freed-up time" is that a role gets smaller, say so plainly; do not imply growth you have not planned. Where possible, make the person whose work is partly moving the accountable supervisor: it converts opposition into ownership. The anti-pattern: announcing an efficiency gain in an all-hands before telling the team.
For customers, the notice rule has three parts: disclose once at first contact, in one sentence with no apology and no euphemism, and always offer a route to a real person. In the European Union that is an obligation. Regulation (EU) 2024/1689, the AI Act, requires in Article 50(1) that people are "informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect", and Article 50 has applied since 2 August 2026. California's B.O.T. Act (Business and Professions Code sections 17940 to 17943, SB 1001, 2018) is narrower: it bars using a bot to mislead about artificial identity in order to incentivise a sale or influence a vote.
The practical detail is field 14: keep the disclosure sentence in the AI agent job description, so changing it is documented.
Where to start
Pick one process, open one page, fill in the seventeen fields. The ones that stall are the finding: usually the accountable human, the out-of-scope exclusions and the definition of a finished outcome. For a sense of which processes are ready first, a free assessment returning a readiness score, results by dimension and an estimate of recoverable hours is a reasonable start.
Frequently asked questions
Can an AI agent be an employee?
No. An agent is not a legal person, holds no employment rights or obligations, and cannot be disciplined. The hiring vocabulary is borrowed on purpose, because it forces the clarity a human role needs. The obligations stay with your organisation and the named person.
Who should write the AI agent job description?
The accountable human, sitting with whoever does the work today. Not IT, and not the vendor. The person who handles the process is the only one who knows the exceptions, and the exceptions are what the out-of-scope field captures. Technical review comes after the draft.
How long should an AI agent job description be?
One page. If it runs longer, the scope is too wide and should be split into two agents with two documents. Review it quarterly, and give it a version number and a last reviewed date, so arguments about what changed are settled by reading.
Does every agent need its own document, or can one cover several?
One document per agent. Two agents sharing a scope means neither has one, and the first incident becomes an argument about which was supposed to act. If several agents do identical work, they are one role with several instances under one document.
Where do AI agents sit in the org chart?
Under a named human, inside the function whose work they do. An agent is not a peer node and not a department. The useful test: who is messaged when it fails, and who can pause it within an hour. Two different people means no reporting line.
How many AI agents can one person supervise?
There is no credible published number, and any ratio in circulation is a guess. Measure instead. One agent costing twenty minutes of approvals and ten of escalations a day costs about two and a half hours a week before review time. Six free hours means two agents, not ten.
Does an agent that only drafts and never sends still need a document?
Yes, a shorter one. Drafting looks harmless until the draft is trusted enough to be sent unread, which happens quietly and without a decision. Write the scope, the out-of-scope exclusions and the accountable human while the answer is still easy.
