How to write a job description for an AI system: 7 headings

Posted on Oct 23 • Originally published at devaland.com

Quick answer: A job description for an AI system is one screen with seven headings: trigger, input, source of truth, output, destination, never, and exception owner. If every heading can be filled in, the job can be built. If one stays empty, it is still an idea, and the empty heading tells you what to decide first.

Most AI projects in small teams start with a question: "can AI do our invoices?", "can it answer our customers?". A question is something you ask once. A system needs a job: something that happens again and again, with a start, an input, a result and a place where the result goes.

When I scope a system, for a client or for my own company, I write the job under seven headings before anything is built. If the seven fit on one screen, the job can be built. If one of them stays empty, it is still an idea, and building it turns into weeks of discovering the missing heading the hard way.

"Summarise this contract" is a question.

"Every time a signed contract lands in the contracts folder, extract the parties, the start date, the renewal date and the notice period, add them as a row to the renewals sheet, and list any contract where one of those four fields could not be found" is a job.

The second version has a trigger, an input, an output, a destination, and one thing most people forget: what happens when the system cannot do the job. A job described like this can be handed over. A question cannot, because every time it comes up someone has to decide to ask it.

This example is invented for teaching: a small distribution business, and the job of keeping the returns spreadsheet up to date from the returns inbox.

It fits on one screen. Every heading is filled in. That is the test.

If I had to pick one heading that decides whether a system works in practice, it is the third one. Teams write "the system checks the customer's data" without saying where that data lives. Then the email says one address, the shop says another, and the system has to choose. Without a written rule it chooses differently every time, and nobody can say afterwards why it did what it did.

Write down where each fact comes from, and which source wins when two disagree. It takes one line and saves the most arguments later.

A never list like "do nothing risky" is a wish, not a rule. Each line should be concrete, and each one needs what the system does instead:

The strongest version of a never line is missing access: a system that has no access to payments cannot pay wrongly.

A useful system reports every item in one of three states: done, set aside (with the reason in one sentence), or could not check. The third matters because a failed search and a search that found nothing look the same. If they are not kept apart, an outage becomes a reassuring "all clear".

The safest way to start is to let the system do the whole job except the last step. It writes the reply but leaves it in drafts. It fills the row but marks it unconfirmed. A person reviews for a while, and each kind of item earns the right to be finished on its own only after the record shows it can be trusted, one category at a time.

Pick one repetitive task from your own week and write it under the seven headings. If a heading stays empty, that is the useful finding: it tells you what to decide before anyone builds anything.

The full method, with the scoring of candidate jobs, the never list and draft mode worked through step by step, is in my workbook Giving an AI a Job: The Workbook, which Leanpub featured on its home page on 22 October 2026. More about it: the workbook page.

Originally published on devaland.com: How to write a job description for an AI system: 7 headings