How do you write a job description for an AI system?
Treat the system as a new hire and write a six-field employee file: a job title naming the function rather than the vendor's product, a reporting line to one named human who answers for its output, a scope of authority with explicit escalation thresholds, an onboarding checklist of known hard cases it must pass before go-live, a fixed 30/60/90-day review cadence with a scorecard, and written retirement criteria. Dr. Jonah Tebaa wrote one with a logistics client in an afternoon.
A logistics company called me in with what looked like a small integration problem. They had already licensed two AI systems — one for load-matching, one for exception handling on delayed shipments — and wanted help folding both into a nine-person operations team that was already stretched thin.
The Nine-Person Team and the Question Nobody Could Answer
I sat down with the founder to map reporting lines before we touched a single workflow. I asked who these two systems answered to. He didn't know. Not because he hadn't thought about it — because the question had never come up in those terms. The systems had owners in the sense that someone had bought them and someone else had turned them on. Neither counted as a reporting line.
So I asked a simpler question: what's this AI's job title?
Not what does it do. A job title. Something you could put on an org chart next to a name, a manager, and a set of duties someone else could be held to.
He didn't have an answer. Neither did his team. Nine people, two AI systems already running in production, and not one sentence describing what either of them was employed to do, who supervised the work, or who would explain a bad outcome to a customer.
That gap is the actual subject of this piece. Everything downstream — trust, adoption, blame, praise — traces back to whether that sentence exists.
Why "It's Just a Tool" Was the Wrong Frame
The founder's first instinct, like most founders', was to wave off the question: "It's just a tool. We don't write job descriptions for our routing software." That's a fair objection for software that produces a fixed output from a fixed input. It's the wrong frame for something making judgment calls that used to sit inside a person's role.
The load-matching system was deciding which carrier got which shipment, using criteria that shifted with each week's data. The exception-handling system was drafting customer-facing responses to delays, with a human skimming — not reviewing — before send. Both were doing work that, six months earlier, belonged explicitly to two named employees with job descriptions, managers, and annual reviews.
When you route that same work to an AI system without giving it the same structural apparatus, you haven't simplified anything. You've just deleted the parts of the job that made it accountable. The work still happens. The org chart just stops describing who's responsible for it.
The macro data points the same way. The ILO's Generative AI and Jobs: 2025 update finds that "most jobs will be transformed rather than made redundant" — and a transformed job still needs a written description, or the transformation happens with nobody recording what the role now is. That was the gap here: the work had changed hands and no document had changed with it.
That's the distinction I want to draw here. This isn't a question about how much to trust the AI's decisions. It's a placement question — where does this function sit in the structure, who owns its output, and what happens on a fixed date when someone checks. Get the placement right and the trust conversation becomes much smaller, because there's a specific person and a specific date attached to it.
Nine people can absorb a colleague's mistake because there's a name attached and a manager who owns the correction. Nine people cannot absorb a system's mistake if the system was never given a name, a manager, or a place in the review cycle. It just becomes noise everyone routes around.
The Employee File I Wrote for the AI
So we wrote one. Not a policy document. An employee file — the same six fields I'd expect to see for any new hire, adapted for a system instead of a person.
- Job title — the specific function it performs, not the vendor's product name. Not "the AI platform." "Carrier Assignment Analyst" and "Customer Delay Response Drafter." A vendor name tells you what you bought. A job title tells you what the role is accountable for.
- Reporting line — one named human who owns its output and answers for it in a room. Not "operations team." The operations manager, by name, who would be the person explaining a bad carrier assignment to a client — the same person who'd explain it if a human analyst had made the call.
- Scope of authority — what it decides alone versus what it must escalate, written as explicit thresholds, not vibes. The load-matching system could assign any shipment under a set dollar value and standard transit window without sign-off. Anything above that threshold, or anything routing through a carrier flagged for prior service issues, required human approval before it went out.
- Onboarding checklist — the data, access, and edge cases it had to be tested against before go-live. We ran both systems against a batch of historical exception cases the team already knew the "right" answer to, including the ugly ones — a shipment with three carrier changes in transit, a customer complaint that contradicted the tracking data. If it couldn't handle the known hard cases, it didn't go live.
- Review cadence — a fixed 30/60/90-day date on the calendar where the named manager evaluates its output against metrics set in advance. Not "check in periodically." A date, a person, a scorecard: on-time assignment accuracy, escalation rate, customer complaint rate tied to its drafted responses.
- Retirement criteria — the condition under which the role gets reassigned, retrained, or shut off. Written down before go-live, not improvised after a bad week. For the exception-handling system, we set a threshold: two consecutive review periods below the complaint-rate target, and the role reverts to human drafting while the system is retrained.
Writing this took an afternoon. Almost none of the content was new — the founder already had opinions about most of these fields, buried in his head. Writing them down as an employee file is what made them enforceable. If you want the field-by-field template on its own, I set it out separately in how to write a job description for an AI employee. This piece is what it looked like when a real team actually did it.
What Changed on the Org Chart After We Did This
The first visible change was smaller than I expected: the operations manager stopped saying "the AI did something weird" and started saying "the Carrier Assignment Analyst flagged three shipments outside its threshold this week." That's not a cosmetic difference. The second sentence has a subject, a scope, and an owner. The first one is a shrug.
The second change was in the escalation habits of the team. Before the employee file existed, anything the AI got wrong turned into a group conversation — three or four people speculating about what happened, because no single person owned the answer. After, a wrong carrier assignment above the threshold went straight to the named manager, because that manager had agreed, in writing, to own decisions in that band. The conversation got shorter and more useful.
The third change was the one the founder noticed first: he could finally take credit — and give credit — for the system's good weeks. Before the employee file, a good week from the AI was just "things went smoothly," attributable to nobody. After, it showed up on the 30-day review as a specific manager's win: a defined scope, executed well, on a defined schedule. That's the piece most founders miss when they treat an AI system as infrastructure instead of a role. Structure isn't just how you catch failure faster. It's how good performance becomes visible enough to matter.
None of this required trusting the AI more or less than before. It required deciding, on paper, where it sat.
An AI system without a job title has no manager, and an AI system with no manager becomes everyone's problem when it fails and no one's credit when it works.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
