How to Brief an AI Developer: Four Facts, and Not One Technology Choice

What should a brief for an AI developer contain?

A brief that produces useful work contains four facts: the bottleneck, who owns it, what a wrong answer costs, and what the current workaround is. None of the four is a technology choice, and adding a technology choice to the other four does not improve them.

I have received briefs as a one-line email ("we need AI for our contract review") and as forty-slide decks with the vendor already chosen. Both fail the same way. The engineer cannot tell what the system is supposed to change, so the first month goes into discovering the problem instead of building against it. Discovery is legitimate work, but the person doing it has no access to your P&L, so you are paying for it to be done badly.

A brief for an AI developer works when it states the bottleneck, the owner, the cost of a wrong answer, and the current workaround, because those four facts define the problem and none of them is a technology choice.

A brief is the only artifact in the engagement that is cheap to get wrong. A wrong sentence in a one-page brief costs a conversation. The same wrong sentence discovered at week ten, after integrations exist, costs the build plus the goodwill of whoever championed it.

Why does every brief arrive pre-loaded with a technology decision?

Because decisions arrive before problems do. Someone attends a conference, a vendor sends a pilot offer, and the decision to "do AI" is taken in a room where nobody has described a process. The brief is then written backwards from the decision: find a workflow that fits the tool.

Three things break as a result. The engineer cannot price the work, because without volume and touch time there is no unit of work, and without a unit of work there is no per-unit cost and no ceiling. The engineer cannot say no, and "do not build this yet, the inputs are not stable enough" is the most valuable sentence a person you hire can say. And you lose the option of doing nothing, because a brief that names a tool has only two outcomes: buy it or do not.

How do you describe the bottleneck so it can be worked on?

Four attributes: the process name as your own team says it, the volume per month, the median human touch time per instance, and where the queue forms. Not the average touch time. Averages are dominated by the two horror cases everyone remembers and nobody can fix by buying software.

Take the numbers from records, not from interviews. Ask an operations lead how long something takes and you get the process as it is supposed to run. Pull twenty completed cases from last month and reconstruct the timestamps. Half an hour of work, and it is the difference between a brief and a wish.

The arithmetic is then trivial, and it is the only part your CFO needs. A worked example with the assumptions visible: 1,200 invoices a month, a median of seven minutes of human touch each, which is 140 hours a month. At a loaded rate of $45 an hour — salary plus employer costs plus the software seat that exists only for this task, divided by productive hours rather than by 2,080 — that is about $6,300 a month, roughly $75,000 a year. Those figures are illustrative. A good engineer re-derives them from your records in week one rather than accepting them.

Who owns it, and how do you know the answer is real?

Ownership is not a title. It is three permissions: the owner can change the decision rule the system would encode, can approve spending on the fix, and answers the exception questions that arrive on a bad day. Test it by asking who currently says no when a case does not fit the process. If that takes more than one sentence to answer, you have found a gap, not a process.

The common failure is an owner who is enthusiastic but cannot approve anything. The pilot works, the team likes it, and it stalls where someone has to sign that the system may write to a customer record. Six weeks of work, no decision, and the engineer is blamed for poor adoption.

Write one name in the brief. If two names are genuinely required, write which decisions belong to which. Ambiguity here is a delay you have scheduled for later.

What does a wrong answer cost, and why does it decide the architecture?

It decides most of what follows. Sort wrong answers into three tiers and give each a rough number.

A mistake caught inside the process — a mis-keyed field that a downstream check rejects — costs the minutes to correct it, usually under a few dollars. Systems in this tier can run without a person reading every output.

A mistake seen from outside — an invoice figure a customer queries, a mis-routed shipment, a credit note — costs rework, an apology, and whatever margin you concede to keep the account. Most enterprise workflows live in this tier, which is why the review step, not the model, is the expensive part.

A mistake that cannot be recovered — a regulatory filing, a payment that has left your account, a contractual commitment — is not a per-instance cost at all. It is a tail event, and nothing in this tier should execute without a named human committing it.

The asymmetry matters as much as the magnitude. If a missed case is cheap and a false alarm is expensive, the system should tolerate misses; the reverse inverts the design. That question, answered honestly, tells an engineer more about your risk appetite than any policy document, and it is the question most briefs leave blank.

Why is the current workaround the number that decides whether anything gets used?

Because the workaround is the real competitor. It is already approved, already understood, and free at the margin for whoever runs it. If the new system does not beat it on the owner's own metric — their Monday, their overtime, their queue — they will keep the workaround and run both.

So write it down: the spreadsheet, the copy-paste between systems, the retyping from PDF, the contractor brought in at month-end, the person who stays late on the twenty-eighth. Ask about the worst week rather than the typical one, because that is when the workaround fails and when the owner will remember being helped.

What should stay out of the brief?

Tool names, model names, and architecture. Vendor comparisons. Anything about headcount. "We want an AI assistant" is not a requirement; it is a shape you have decided the answer must take, and it removes the option of a smaller answer.

Headcount deserves its own line, because it poisons the engagement. If the brief says the goal is to remove three roles, the people who know how the process actually works will tell you less, and they are the ones holding the process knowledge you need. State the goal as a process cost, not as a roster.

What replaces all of it is one page you could hand to an outsider with no meeting. Four sections, one number each where a number exists, and a short list of what you do not know. A brief with no unknowns has usually had them removed by someone's optimism.

How do you tell whether the engineer heard you?

Listen to their first three questions. If they are about your model preferences, the brief did not land. If they are about volume, exceptions, who signs off, and what happens on the worst day, they are doing the work you paid for.

The second test is what arrives in week one: a written definition of the unit of work, the trust boundary, and the cost per instance, in language your operations lead can argue with — the kind of written brief that names the bottleneck before any code is written. Hold out for that rather than for a demo. A demo can be built at any time; the understanding cannot be retrofitted.

One caution about your own expectations. In a 2025 randomised trial, METR measured experienced open-source maintainers working on their own repositories and found them roughly 19 percent slower with early-2025 AI tools, while those developers believed they had been faster. The setting was narrow and does not transfer directly to invoice processing. The lesson does. The brief should state the metric you will judge by and the week you will check it, because without a pre-agreed metric the pilot's success is decided by whoever speaks last in the review meeting.

The brief is the decision, written down

If you can fill one page with the bottleneck, the owner, the cost of a wrong answer, and the current workaround, you are no longer asking anyone to discover your problem. You are buying either a build or an honest no, and both are useful. If you cannot fill the page, that is the finding, and it is worth more than a pilot, because it tells you where the money should go first. The four facts are cheap to assemble and expensive to skip, and the engineer you hire is not the person who can supply them.