Draft Client Status Updates With AI Without Inventing Progress

A task board says complete. A designer says ready for review. Last week's client update says the same item is still being built.

An AI summary can turn those three records into a confident sentence. The useful question is whether that sentence describes what actually changed.

Give the assistant a narrower assignment: prepare a draft client update in which every material progress claim can be checked against a dated record.

The example below concerns a fictional design studio. Its project, records and dates are synthetic. This is a proposed process, with no claimed deployment or measured results.

Define the reporting window

Start by writing the beginning and end of the period being reported, including the time zone. Keep the last approved update beside the new source material.

A source's retrieval time and the date of the event it describes answer different questions. A message found today may describe work completed last week. A task edited this morning may contain no new progress.

Ask the assistant to separate three things: newly evidenced changes during this period, older facts needed for context, and claims whose timing is unclear.

Atlassian's project status report guidance includes a reporting period, achievements, blockers and next steps. It also recommends adapting the report to its audience and defining status labels clearly. Those principles provide a useful starting point; the evidence-checking process here is an editorial proposal.

Choose the audience before collecting material. A client update does not need every internal conversation about the project.

Make a change ledger before writing prose

Start with the deliverables mentioned in the last approved update, then check the approved sources for newly added deliverables and material scope or dependency changes. For each relevant item, collect the evidence needed to establish its state within the reporting window.

Use a small internal ledger:

• Previous reported state: What the last approved update actually said.
• New evidence: The dated record and the exact deliverable or version it concerns.
• Supported change: What that record establishes.
• Remaining uncertainty: What cannot yet be concluded.
• Review owner: Who can resolve a material conflict.

Preserve the source reference for the reviewer. If a source is unavailable, record that limit rather than treating the absence of evidence as proof that nothing happened.

A move to a completed column may establish that someone changed a task's status. It does not necessarily establish client acceptance, successful delivery or readiness for the next dependency. Use the project's agreed definitions to decide what each record supports.

Do not calculate a completion percentage from task counts unless the project already has a suitable agreed method. Five finished tasks out of ten can be a poor description of progress when the remaining work is substantially larger.

Work through a synthetic reporting window

The fictional studio is reporting on Monday through Thursday, with a Thursday 4 p.m. cutoff in the project's agreed time zone.

The previous approved update said that the campaign illustrations were in production, the landing-page layout was awaiting review, and accessibility checks had not begun.

The new records show:

• A Wednesday upload contains illustration files, but no required internal review result.
• A Thursday message from the authorized client approver approves landing-page layout version three.
• A Thursday task comment says accessibility checks will start Friday.
• A message arriving after the cutoff requests a new delivery date.

The draft can say that illustration files were uploaded Wednesday; the checked records do not establish whether internal review is complete. It can say the client approved the specified layout version. It should retain accessibility checks as planned, rather than presenting the intention to start as work already completed.

The later message belongs in a clearly labeled subsequent update or a revised reporting window, if the project lead decides it materially affects the communication. It must not silently change the period covered by the report.

A requested delivery date remains a request until the authorized owner agrees to it.

Resolve the headline separately

A concise update often begins with a project-level assessment. That sentence deserves its own check.

If the records show one approved deliverable and one unresolved dependency, the assistant should not infer that the whole project is on track. It needs the applicable milestone, dependency and status rules.

Ask the project lead to confirm the headline assessment. When evidence is insufficient, the internal draft should identify the missing check. The eventual client-facing wording should explain the relevant uncertainty accurately, using language approved for that audience.

Avoid letting polished wording settle a disputed fact. Resolve the fact first, or preserve the uncertainty in the draft.

Keep the first version draft-only

For this job, a fixed sequence can be enough: identify changes, check supporting records, draft the update, obtain review.

Anthropic's guidance on effective agents recommends beginning with the simplest workable approach and distinguishes predefined workflows from model-directed processes. The article notes that its tooling landscape has changed since its original publication. The design principle is useful here without adopting its historical tooling recommendations.

Give the assistant only material authorized for processing in the chosen service. Keep internal evidence notes separate from the client-facing draft. A source link that a reviewer can open may expose internal information or be inaccessible to the client.

During the trial, keep sending, task editing and schedule changes outside the assistant's permissions. If the workflow cannot be technically restricted that way, resolve the implementation boundary before supplying live project material.

Use a short review worksheet

The following worksheet is a proposed editorial aid:

Period and audience: State the reporting window, time zone and intended recipients.

What changed: List supported changes since the last approved update, with internal evidence references.

What remains open: Identify unresolved dependencies, missing confirmation and decisions needed.

Next steps: Include only supported plans. Separate requested dates from agreed dates, and leave unknown owners or timing unresolved.

Headline check: Have the responsible person confirm the overall assessment against the project's rules.

Sharing check: Confirm that the exact wording and any links are suitable for these recipients.

Release check: Obtain the required approval for the exact draft before sending. Retain the approved version and sending record afterward.

A checked draft is ready for a sending decision. It is not evidence that the client has received or accepted it.

Test whether the update preserves reality

Before using live records, try synthetic cases with conflicting status labels, an old event discovered late, an unapproved deliverable and a message after the cutoff.

Have the project lead identify the expected claims and uncertainties in advance. Check whether the draft invents progress, misses a material change, confuses versions or creates a new promise.

Record checking and correction time as well as drafting time. If the reviewer must reconstruct every claim, improve the evidence ledger before increasing the number of projects.

Start with one reporting cycle. The result should be a brief update whose important statements survive a source check and whose open questions remain visible.