Briefs for unattended runs
In chat you correct as you go. In a scheduled run nobody is there. Seven details a brief needs so that it works without follow-up questions – and so that a failure shows instead of looking good.
Boaz Lichtenstein
A prompt in chat may be incomplete. If something is missing you see it in the answer and follow up. In a scheduled run that second pass disappears. The brief has to contain everything you would otherwise have supplied afterwards.
The seven details
1. Goal and recipient. What is the result for, and who reads it? “For the sales team’s Monday meeting” determines length, tone and selection better than any style rule.
2. Sources – exactly. Not “the order data” but which file, which connector, which view. A run cannot guess which of three similar tables was meant.
3. Period – spelled out. “Last week” is unambiguous on Monday at 7 am, but no longer so for a delayed run on Tuesday. Write “the calendar week before the run date, Monday to Sunday, local time”.
4. Form. Structure, length, table or prose. Ideally with an example of the result you want.
5. Destination. Where does the result go – and under what name? A report sitting somewhere in the history does not get read.
6. Failure case. What happens when a source is missing, empty or looks different from what was expected?
7. Limits. What the run must not do: send nothing, delete nothing, change no data in the sources.
A brief that manages without you
Produce the weekly report for the sales team's Monday meeting.
Source: spreadsheet “Orders 2026”, sheet “Export”.
Period: the calendar week before the run date, Monday to Sunday,
local time.
Content: revenue, number of orders, refunds – each with the change
against the previous week in per cent. Below that, at most three
sentences on anomalies. Calculate with the analysis tool and show
the formula.
Destination: as a draft in the folder “Weekly reports”, named
“Weekly report CW <number>”. If the name already exists, overwrite
the draft instead of creating a second one.
If the source cannot be reached, rows for the period are missing or
columns have different names: write that in the first line and
deliver no figures. Estimate nothing.
Send nothing. Change nothing in the source spreadsheet.The failure case is the most important sentence
A model wants to complete a task. If a source is missing, the obvious route is to carry on with what is there – last week’s figures, an average, a plausible estimate. The result looks complete and is wrong.
Only an explicit rule helps against that: gaps appear as gaps in the result, and at the top. The same goes for the case where there is nothing to report. “No new entries since the last run” is a full-value output – silence is not.
Build it repeatable
Runs get repeated: because one got stuck, because you are testing, because the provider restarts. A good brief can take that. In the example the fixed file name takes care of it – the second run overwrites the draft instead of creating another.
The test question: what happens if this brief runs twice in a row? Two identical reports are a nuisance. Two identical emails to customers are a problem – one more reason to keep sending out of the run.
The trial
Before you trust a brief, make it fail once on purpose: rename the source or withdraw access. If the failure is in the first line, the brief is ready. If a pretty report arrives, detail number six is missing.