Hiring someone to build a daily AI summary report: what to put in the brief

The short answer

A scheduled AI report sounds like one job: “every morning, summarise what happened and send it to me”. It is really four: collect the data, calculate the numbers, write the summary, deliver it on time. Only the third step needs an AI model. The other three are ordinary automation, and that is where most of the problems are.

So the brief should spend most of its words on the boring parts: which data, over which period, what counts as new, where the report lands and when, and what happens on the morning it does not arrive. Get those right and the AI part is the easy bit. The workflow automation brief has the fields; this guide is what to write in them for a report.

What the four parts look like

Part	What it does	Who should do it
Collect	Pulls data from your sources: a sheet, a CRM, a mailbox, an analytics tool	The workflow tool or script, with read-only access
Calculate	Totals, changes since last time, “top 5” lists	Plain code or the workflow tool, never the AI
Write	Turns the figures into a few readable sentences	The AI model, given only the calculated figures
Deliver	Sends it to your inbox or chat at a fixed time	The scheduler, plus a check that it actually arrived

The split between Calculate and Write is the line that matters most. An AI model asked to read a raw export and “summarise the numbers” may round, mix up rows or fill a gap with a plausible figure. Asked to write two sentences around numbers that were already computed, it has much less room to invent. The guide on stopping an AI from making things up covers the same problem for chatbots; a report is a smaller version of it.

Six decisions to make before you brief

1. The sources, and read-only access. List every source by name. For each, the account should be yours and the access should be read-only wherever the tool allows it. One of my report jobs reads search statistics for my websites through a read-only connection; its notes say in one line that it only observes and never changes anything. A report has no reason to write to your systems.

2. The time window, including data delay. “Yesterday” is not always available yesterday. The search statistics my job reads arrive two to three days late, so its seven-day window ends three days before the day it runs. If your source lags, the report should say which dates it covers, every time.

3. What “new” means. Most of the value of a recurring report is the difference from the last one. My job lists search queries that appeared for the first time since its previous run, which is often the most useful line in it. Decide what your “new since last time” is: new leads, new complaints, a figure that moved more than a set amount.

4. A fixed format. My report job adds one row to a log file per site per run, always with the same columns, and then sends one short chat message for everything. The fixed row means I can compare runs weeks later without reading old messages. I also read an AI briefing every weekday, sent to Telegram twice a day, morning and early afternoon, that summarises new email and files. It is useful because it always arrives at the same times in the same shape. Ask for the same: a fixed set of figures in a fixed order, then the AI-written sentences.

5. Where and when it lands. Pick the channel (email, Slack, Teams, a chat app) and a time. Then ask where the job runs. A scheduled job on a laptop is at the mercy of the laptop. Mine ran 38 minutes late one evening and three hours late the next morning, and one run never happened, because the machine had slipped into a low-power standby in which its wake-up settings were ignored (the full incident). A report that should land at 8 should run on a server or a hosted platform, or on a machine that is kept awake. The basics page on cron and schedules explains the options.

6. What an empty or failed report says. Decide what you get on a day with no data. “No new orders yesterday” is a useful report; silence is not. My publishing job once logged “nothing to prepare” run after run, and that looked exactly like a quiet day until I checked. A report should never be skipped just because there was nothing to say.

The report is its own heartbeat

Most automations should stay quiet when things are fine. My own watchdog only messages me when a check fails, because a daily “all good” quickly stops being read. A report is the exception: it is supposed to arrive every time. That makes its absence the alarm, but only if something is watching for it. That is heartbeat monitoring, and a report job needs it more than most.

Three failures from my own jobs show why the report cannot be trusted to report on itself:

• The computer restarted for an update. One night, after three forced restarts past 1 a.m., the machine stayed on but nobody was logged in until 09. Jobs set to run only for a logged-in user were skipped, and my 08 check had the same setting, so it was skipped too. No message of any kind. The fix was making the jobs run whether or not anyone is logged in.
• A login stopped working. For two days a code-hosting token was refused. Five scheduled runs started on time, reported success and published nothing (the full incident). My publishing jobs now test their login on every run, even on days with nothing to do.
• A usage limit was reached. A nightly content job hit a monthly spending limit on the account it ran on at 01. It still produced its output, then ended with an error. A second job would have shared the same limit, so I kept that one switched off. If your report shares an AI account with anything else, they share the limit too.

The guide on what error alerts to ask for has the alert lines; for a report, the one you need most is “tell me if the report has not arrived by a set time”.

A brief you can copy

Paste this into the workflow automation brief and fill in the brackets:

Line 9 matters because a report runs every day for as long as you keep it. The basics page on AI tokens and usage costs explains how usage becomes a bill, and running costs after handover lists the other monthly lines.

How to test it before you pay

The acceptance checklist for unattended automations applies in full. For a report, add four tests:

1. Three reports from the real schedule. Not “run now”. Compare every figure in one of them against the source by hand.
2. An empty day. Point it at a period with no data, or ask the freelancer to simulate one. The report should arrive and say there was nothing.
3. A missing report. Disable one run. The separate alert should reach you by the time in line 8.
4. A re-run. Ask how to re-send yesterday’s report after a failure, then try it yourself from the run-book. It should not send the same report twice by accident.

Who to hire

This is mostly a workflow automation job with one AI step, so start on the workflow automation page. A single report from one or two sources fits a seller who does well-defined connections; Asaf Cadmon’s basic tier is one API and one trigger, which is the size of a simple report. If your data already lives in Microsoft 365, Parth Choksi works with Power Automate and Power BI reporting. If the report needs to look things up or answer follow-up questions, it is closer to an agent, and the AI agents and chatbots page is the better start.

Wrap-up

The AI part of a scheduled report is a few sentences. The value is in everything around it: the right data, the right dates, figures computed by plain code, a fixed format you can compare over time, and a separate check that notices when the report does not come. Put those in the brief, test the empty day and the missing day before you pay, and the report becomes something you can stop thinking about.