Our weekly project report is genuinely good at its job. It reads the active tasks, the Gmail thread with the customer, and the project's Slack channel, and it produces a summary that is usually closer to reality than what a busy account lead would have typed at 6pm on a Thursday.
It still cannot set your project status. That is not a limitation we plan to remove.
Draft is a different object to record
A summary is an opinion about state. A status is state. The moment generated text is allowed to write the second one, every downstream consumer — the reports page, the client update, the dashboard your leadership reads — inherits a claim that nobody checked.
So the report is created as a draft with a proposed status attached. Approving it is what writes the status. Rejecting it discards the draft and leaves the project untouched. There is no third path where text quietly becomes truth.
The model proposes a status. It never sets one.
The customer-facing case is stricter
Internal reports have a reviewer by construction — the person clicking approve. Client update emails do not. Nobody stands between that message and a customer's inbox, which means the safe design is not a better prompt. It is no prompt at all.
Client updates render from milestone and task state through a template you control. Two of three tasks done is two of three tasks done. There is no summarisation step, so there is nothing to hallucinate and nothing to review.
What this costs
It costs a click a week per project, and it costs us the demo moment where the software appears to run itself. We think that is a good trade. The teams using this are putting their delivery reputation on what the tool says, and a system that is right most of the time is not the same as a system you can rely on.
Jordan Ellis
Engineering at RESK
Builds the reporting and automation internals at RESK.