AI-assisted agency progress reports: show accepted work and the next decision

AI-assisted development can produce a busy repository: more drafts, experiments, commits and proposed changes. A client still needs a clear answer to practical questions. What can the team use now? What has been checked? What is blocked? What decision would move the project forward?

A useful agency progress report connects work to those questions. This article recommends a reporting format for AI-assisted website and software projects. Its sample language is illustrative, not a Curiosive client report, and it does not claim measured productivity gains.

A recent reminder about measuring activity

In “Be Careful What You Measure,” published October 1, 2026, Ashton Wiersdorf argues that measurements can become targets and change incentives. A personal anecdote describes an organization celebrating increased code activity during AI experimentation; the author questions whether that activity establishes software quality. This is an essay and an anecdote, not a comparative study of AI development productivity.

The Hacker News discussion submitted on October 2 provides context for the debate, not evidence of client outcomes. Our recommendation is narrower: make accepted behavior, uncertainty and the next client decision the center of a delivery update. Keep activity records available where they explain effort or a technical issue.

Begin with the client task that changed

Write the first paragraph around a user action, using the agreed scope as the reference. For example: “The reviewer can now open a submitted request and see its original attachment.” Then identify the environment and status: a development preview, a release candidate or the production version.

Avoid collapsing those states into “done.” A generated implementation may be ready for an engineer’s review but not for client acceptance. A tested release may be deployed without the client yet completing its own acceptance task. Name the current state so the recipient knows what kind of action is available.

This follows from scoping one reviewable AI feature. The progress report uses the original task and acceptance examples to explain movement. It should not redefine success midway through the engagement simply because a different output was easier to generate.

Show acceptance evidence in proportion to the claim

Attach evidence that lets the recipient assess the behavior being reported. A preview link helps the client try a screen. A test summary explains verified conditions. A release identifier connects the review to a specific version. A deployment check establishes where that version is available.

These records answer different questions. Passing a build shows that the application can be assembled in the tested environment; it does not establish the usefulness of an AI answer. A screenshot can illustrate layout but cannot show every permission path. A model evaluation can cover representative examples while leaving other inputs untested.

For an AI feature, explain what was evaluated, what failed and what remains unknown. If the feature drafts answers from approved documents, report whether reviewed examples contained supported claims and whether missing information reached the intended fallback. Do not turn a small example set into a broad accuracy percentage without an appropriate measurement design.

Use plain language in the client-facing report, with detailed technical evidence linked for those who need it. The aim is a reviewable statement, not a wall of logs. Our own website content delivery walkthrough shows one bounded example of connecting a release to checks and live verification; it does not establish outcomes for client projects.

Keep acceptance, effort and outcome separate

A report can legitimately include recorded effort, remaining capacity and operational observations. Label each measure by what it describes. Time spent is an effort record. Acceptance of an agreed task is a delivery event. Reduced handling time in the client’s operation is an outcome that requires its own baseline and observation.

Do not infer one from another. A small code change can resolve a difficult issue; a large change can still await review. AI may help draft a solution while engineering effort goes into diagnosis, integration and verification. If that work affects the engagement, describe the work and its evidence without inventing a counterfactual such as how long it would have taken without AI.

Where an engagement has an agreed effort allowance, report the actual record against the contract and explain the proposed next scope. Refer to the agreed terms rather than creating a new promise inside a weekly update. Curiosive’s existing service information and terms remain the place to discuss engagement options.

Name blockers as decisions or dependencies

“Waiting on the client” is rarely enough. Name the missing input, who can provide it and which task it affects. A useful blocker statement might be: “The review environment uses approved sample documents. Testing the live connection requires access from the designated account owner.” That sentence distinguishes completed work from the dependency preventing the next check.

If a decision is required, offer the relevant alternatives and their practical consequences. An illustrative request could ask whether the first release should support manually approved uploads or wait for a live source connection. Do not assume approval because the report was delivered or a deadline passed.

Give unknowns the same treatment. State what would resolve them: a representative document, a permission check, a review with an operator or an investigation of an external dependency. Attach a proposed owner and next action. This makes uncertainty manageable without presenting speculation as a committed delivery date.

Use a compact report structure

The following is a recommended template, not an actual client project update:

• Accepted or ready to review: name the user task, environment and version. Distinguish agency verification from client acceptance.
• Evidence: link the preview, relevant test summary and known conditions. State what those checks establish.
• Open limits: describe failed examples, unavailable integrations or behavior outside the agreed scope.
• Effort and scope: report actual effort where required by the engagement, with any proposed scope change clearly labeled.
• Next decision: state the question, decision owner and work it unlocks. Include the next review point when agreed.

AI can help turn approved delivery notes into this structure. Give it the accepted task list, actual evidence, recorded effort and unresolved items. Require it to preserve status labels and flag missing facts rather than filling gaps with plausible achievements.

A responsible reviewer should compare the draft with those records before sending it. In particular, check that “implemented” did not become “accepted,” that a proposed date did not become a commitment and that a technical check did not become a business-result claim. The report itself is a deliverable that needs factual review.

Carry the same record into handover

At handover, the reporting history can help explain which behavior was accepted, which limitations remain and who owns the next maintenance action. Keep the final version and supporting evidence together, so the receiving team does not reconstruct the state from a long chat or repository activity chart.

Useful reporting gives clients something they can inspect or decide. It connects AI-assisted work to the agreed task without making code volume stand in for delivery quality.

Need a clearer delivery process for an AI feature or website project? Contact Curiosive with the current workflow and the decisions your team struggles to make. We can discuss a scoped next step through our AI integration services.